# HG changeset patch # User Takahiro SHIMIZU # Date 1542602690 -32400 # Node ID 7a8024855249efe243d4e97a8e23cc3c7faed1f4 # Parent 8e5e2521d1dba0e26a8b832318d0977071d3c554 tweak diff -r 8e5e2521d1db -r 7a8024855249 Paper/anatofuz.pdf Binary file Paper/anatofuz.pdf has changed diff -r 8e5e2521d1db -r 7a8024855249 Paper/anatofuz.tex --- a/Paper/anatofuz.tex Mon Nov 19 13:40:08 2018 +0900 +++ b/Paper/anatofuz.tex Mon Nov 19 13:44:50 2018 +0900 @@ -339,7 +339,7 @@ OP(.*)の.*に該当する箇所はバイトコードの名前である．通常このブロックにはLABELから遷移する為, バイトコードの名前はLABELSの配列の添字に変換されている． -そのため対象となるCodeGearをLABLESの並びと対応させ, Code\ref{cbcoplabelsh}に示すCodeGearの配列CODESとして設定すればCodeGearの名前は問わない． +そのため対象となるCodeGearをLABELSの並びと対応させ, Code\ref{cbcoplabelsh}に示すCodeGearの配列CODESとして設定すればCodeGearの名前は問わない． 今回はCodeGearである事を示す為に接頭辞としてcbc\_をつける． \lstinputlisting[label=cbcoplabelsh, caption=CodeGear配列の一部分]{./src/oplables-cbc-codes.h} @@ -415,7 +415,7 @@ しかしMoarVMが実行する命令は膨大な数がある． その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である． Perlなどのスクリプトを用いて自動的に解析したいため, ログを残す為にscriptコマンドを実行した状態でgdbを起動する． -トレースでは実行した命令名のみ取得できれば良い為, Code\ref{cbc_b}, \ref{orig_b}でdebug pointにcommandとして設定している様に，設定されたcur\_opの値を出力し続けるのみの動きを導入する． +トレースでは実行した命令名のみ取得できれば良い為, Code\ref{cbc_b}, \ref{orig_b}でbreak pointにcommandとして設定している様に，設定されたcur\_opの値を出力し続けるのみの動きを導入する． 実際に実行したログ・ファイルの一部をそれぞれCode\ref{debug_origmoar}, \ref{debug_cbcmoar}に示す． \lstinputlisting[label=debug_origmoar, caption=オリジナル版MoarVMのバイトコードのトレース]{./src/origin_breakpoint.txt} @@ -479,9 +479,9 @@ MoarVMのバイトコードインタプリタの箇所はオリジナルの実装ではラベルジャンプを用いて実装されている． その為, 直接ラベルにbreak pointをかける事が出来ない． -作業者がデバッガが読み込んでいるCソースコードの位置を把握し, 行番号を指定してdebug pointを設定する必要があった． +作業者がデバッガが読み込んでいるCソースコードの位置を把握し, 行番号を指定してbreak pointを設定する必要があった． -CbCMoarVMの場合, CodeGear単位でバイトコードの処理単位を記述している為, 通常の関数と同じく直接CodeGearにデバッグポイントをかける事が可能である． +CbCMoarVMの場合, CodeGear単位でバイトコードの処理単位を記述している為, 通常の関数と同じく直接CodeGearにbreak pointをかける事が可能である． これはCプログラミングの関数に対してのデバッグで, 状態ごとにbreak pointをかける事が出来ることを意味する． 通常のC言語で言語処理系を実装した場合と比較して扱いやすくなっていると言える． さらにラベルテーブルでの管理の場合, 次のバイトコード箇所は数値でしか確認できず, 実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった． @@ -541,19 +541,19 @@ Perl5においてはperlccというモジュールが開発されている． これはPerl5内部で利用しているPerlバイトコードを, PerlのC APIであるXS言語の様なCのソースファイルに埋め込み,それをCコンパイルでコンパイルするというものである． perlccを利用することでPerlインタプリタが無い状況でも可動するバイナリファイルを作成する事が可能である． -しかしPerlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず, 現在ではPerlのコアモジュールから外されている． -PerlccはPerlのバイトコードをCへの変換のみ行う為, Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない． -またPerlccで生成されたCのソースコードは難解であり, これをデバッグするのが困難でもある． +しかしperlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず, 現在ではPerlのコアモジュールから外されている． +perlccはPerlのバイトコードをCへの変換のみ行う為, Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない． +またperlccで生成されたCのソースコードは難解であり, これをデバッグするのが困難でもある． MoarVMでthreaded codeを実現出来た場合, その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である． -CレベルでもPerlccの様に内部構造をCの関数化すればThrededCodeの様な物を構築できるが, CbCと比較して処理の単位が明確ではない為高速化は見込めない． -CbCを用いたThrededCodeでPerlccの様なツールを作成した場合, CodeGearの単位が正常に機能すればCbCのCodeGearがThrededCodeをより効率化出来ると推測できる． +Cレベルでもperlccの様に内部構造をCの関数化すればThrededCodeの様な物を構築できるが, CbCと比較して処理の単位が明確ではない為高速化は見込めない． +CbCを用いたThrededCodeでperlccの様なツールを作成した場合, CodeGearの単位が正常に機能すればCbCのCodeGearがThrededCodeをより効率化出来ると推測できる． CbCのCodeGearはgoto文で遷移するため, 次のCodeGearが一意に決定している場合Cコンパイラ側でインライン展開する事が可能である． CodeGearがインライン展開される限界については別途研究する必要があるが, CbCを利用した場合CodeGear単位でインライン展開が可能である． その為, ThrededCodeを実装する場合に決定した次のCodeGearをインライン展開する事が可能である． 従ってThreadeCodeを実現するにあたり新たな処理系を開発する必要がなく, 既存の資源を利用してThreadeCodeが実現出来る． -これを繰り返す事でPerlccなどと比較してより高速化したThrededCodeが実現できる． +これを繰り返す事でperlccなどと比較してより高速化したThrededCodeが実現できる． \section{まとめ} @@ -564,7 +564,7 @@ \item CodeGear単位で命令処理を記述する事が可能となり, モジュール化が可能となった. \item ThreadeCodeを実装する際に効率的に実装ができる見込みが立った. \item CodeGearを導入した命令単位での最適化が可能となった. - \item break pointを命令の処理単位でかける事可能となった. + \item break pointを命令の処理単位でかける事が可能となった. \end{itemize} 今後CbCでの開発をより深く行っていくにあたり, CbCコンパイラそのものの信頼性を向上させる必要がある．