Papers/2019/anatofuz-prosym: Paper/anatofuz.tex comparison

comparison Paper/anatofuz.tex @ 68:96d62f0292d3

update

author	Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
date	Mon, 19 Nov 2018 17:08:39 +0900
parents	60a15dd5023c
children	5aa4743552b7

comparison

equal deleted inserted replaced

-:60a15dd5023c
+:96d62f0292d3
 Stage0にあるファイルをMoarVMに与えることで, NQPのインタプリタが実行される様になっている．
 これはStage0の一連のファイルは, MoarVMのバイトコードなどで記述されたNQPコンパイラのモジュールである為である．
 NQPのインタプリタはセルフビルドが完了すると, nqpというシェルスクリプトとして提供される．
-このシェルスクリプトは, ライブラリパスなどを設定してのバイナリであるmoarを起動するものである．
+このシェルスクリプトは, ライブラリパスなどを設定してMoarVMの実行バイナリであるmoarを起動するものである．
 %NQPは6modelと呼ばれるオブジェクトモデルを採用としている．%が, これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている．これらMoarVMBytecodeの拡張子は.MoarVMである．
 %MoarVMに対してStage0のディレクトリにライブラリパスを設定し, nqp.MoarVMを実行させることでnqpの対話型環境が起動する．
 \begin{figure}[ht]
 \begin{center}
 \subsection{現在のPerl6}
 Perl6の言語仕様\cite{perl6design}とその時点での実装状況をまとめた公式ドキュメント\cite{perl6doc}は分離している．
 従来は言語仕様は自然言語の仕様書であったが, 現在はテストスイートであるRoast\cite{roast}そのものと定義されている．
-現在のPerl6の仕様を読む場合Roastを確認し, 現在rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある．
+現在のPerl6の仕様を読む場合Roastを確認し, 現在Rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある．
 \subsection{処理速度}
 現在のPerl6が他のプログラミング言語と比較した場合どのような違いがでるのか計測した．
 macOSの/var/log/system.logファイルから正規表現でログ中のプログラムが書き込んだ回数を個別に数え上げるというものである．
 今回はファイルを231Kと3GBの二種類用意し, どの様な違いが出るのか測定した．
 %    * 21.48s
 \section{CbCによるMoarVM}
 この章では改良を行ったPerl6処理系であるMoarVMについて述べる．
-今回改良を行ったMoarVMは2018.04.01であり, 利用したnqpは2018.04-3-g45ab6e3バージョンである．
+今回改良を行ったMoarVMは2018.04.01であり, 利用したNQPは2018.04-3-g45ab6e3バージョンである．
 \subsection{方針}
 MoarVMそのものをCbCで書き換えることも考えられるがMoarVM自体既に巨大なプロジェクトである為すべてを書き換える事は困難である．
 その為まず比較的CbCで書き換えることが容易な箇所を修正する．
 前章までに述べた通りCbCのCodeGearはコンパイラの基本ブロックに該当する．
 従ってMoarVMにおける基本ブロックの箇所をCodeGearに書き換える事が可能である．
 関数内では命令列が保存されているcur\_op, 現在と次の命令を指し示すop, Threadの環境が保存されているThreadcontextなどの変数を利用する．
 命令実行は大きく二種類の動作があり, Cのgotoが利用できる場合はCode\ref{orig_macro}に示すMVM\_CGOTOフラグが立ちラベル遷移を利用する．
 それ以外の場合は巨大なcase文として命令を実行する．
 ラベル遷移を利用する場合はCode\ref{oplabelsh}に示すラベルテーブルLABELSにアクセスし, テーブルに登録されているアドレスを取得し, マクロNEXTで遷移する．
-Code\ref{cbc_dispatch_c}に示すno\_opは何もせず次の命令に移動する為, goto NEXT;のみ記述されている．
+Code\ref{dispatch_c}に示すno\_opは何もせず次の命令に移動する為, goto NEXT;のみ記述されている．
 このラベルテーブルの中身はラベルが変換されたアドレスであるため, 実際に呼ばれている命令コードの名前はデバッガレベルでは確認できない．
 Cレベルでのデバッグ時にはアドレスと実際に呼ばれる箇所を確認する事に手間がかかる．
 巨大なcase文として実行された場合, 実行時間が遅いだけでなく, ラベル遷移と共存させて記述を行っている為Cのソースコードにおける可読性も低下する．
 その為INTERPのメンバであるMoarVMのレジスタそのものをアーキテクチャのレジスタ上に乗せる事が可能である．
 命令実行中のCodeGearの遷移を図\ref{fig:perl6cbcinter}に示す．
 この中で実線で書かれている部分はCbCのgoto文で遷移し, 波線の箇所は通常のCの関数呼び出しとなっている．
-現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextが行っていた．
+現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextが行っている．
 その為cbc\_nextから命令コードに対応するCodeGearに継続し, CodeGearからcbc\_nextに継続するサイクルが基本の流れである．
 CodeGear内からCの関数は問題なく呼ぶ事が可能であるため, Cの関数を利用する処理は変更せず記述する事ができる．
 また変換対象はswitch文であるため, breakせず次のcaseに移行した場合に対応するように別のCodeGearに継続し，その後cbc\_nextに継続するパターンも存在する．
 \lstinputlisting[label=cbc_codesegs_c,  caption=CbCMoarVMのバイトコードに対応するCodeGear]{./src/cbc_codesegs.cbc}
 また, CbCを用いて言語処理系の改良時を行った際に言語処理系のデバッグを行う場合は, CbCを用いないオリジナルの処理系との並列デバッグが必要となる．
 MoarVM自体にはデバッグを支援するツールが存在しない為, MoarVM自体のデバッグ方法や, CbCを用いた処理系との並列デバッグについて独自の手法を利用する必要がある．
 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても示す．
 \subsection{MoarVMのバイトコードのデバッグ}
-MoarVMの実行バイナリであるコマンドmoarに対して, MoarVMのバイトコードをdumpオプションを付けて読み込ませると, バイトコードがMoarVMによるアセンブリコードとして出力される．
+MoarVMの実行バイナリであるmoarに対して, MoarVMのバイトコードをdumpオプションを付けて読み込ませると, バイトコードがMoarVMによるアセンブリコードとして出力される．
 しかしこれはMoarVMが実行したバイトコードのトレースではなく, MoarVMのバイトコードを変換したものに過ぎない．
 また, 明らかに異なる挙動を示すオリジナルのMoarVMと, CbCで書き換えたCbCMoarVM両者のmoarを利用しても同じ結果が返ってきてしまう．
 そのため今回のMoarVMのバイトコードインタプリタの実装のデバッグにはこの方法は適さない．
 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある．
 \lstinputlisting[label=orig_b,  caption=オリジナル版MoarVMに対してのbreak point設定]{./src/origin_b_set.txt}
 \subsection{MoarVMの並列デバッグ手法}
 しかしMoarVMが実行する命令は膨大な数がある．
-その為gdbでMoarVMをCbCとオリジナル版での並列デバッグを人間が同時に行うことは困難である．
+その為gdbなどのCデバッガで, オリジナルのMoarVMと, 一部をCbCで記述したCbCMoarVMの並列デバッグを手動で全て行うことは困難である．
 Perlなどのスクリプトを用いて自動的に解析したいため, ログを残す為にscriptコマンドを実行した状態でgdbを起動する．
 トレースでは実行した命令名のみ取得できれば良い為, 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}
 また主に次のCodeGearに遷移する際にCbCコンパイラのバグが生じている可能性もある為, アセンブラレベルの命令を確認しながらデバッグを進めることとなる．
 \subsection{MoarVMのテスト方法}
 MoarVMは単体で実行する事が不可能である．
-またNQPのリポジトリに付随するテストはnqpで書かれている為, NQPをビルド出来ない場合MoarVMのテストを行う事が出来ない．
+またNQPのリポジトリに付随するテストはNQPで書かれている為, NQPをビルド出来ない場合MoarVMのテストを行う事が出来ない．
 その為, 正常に動作しているMoarVMとNQPを用意し, このNQP側からMoarVMのバイトコードにNQPのテストを変換する．
 変換されたMoarVMのバイトコードはMoarバイナリに渡す事で実行可能であり, テストを行う事が出来る．
 \subsection{CbCコンパイラによるバグ}
 これまでのCbCに関する研究においては, 複数個の入出力をCodeGearに与えるユースケースで利用していた．
 これを繰り返す事でperlccなどと比較してより高速化したThrededCodeが実現できる．
 \section{まとめ}
 本論文ではCbCによってPerl6の処理系であるMoarVMインタプリタの一部改良とその手法を示した．
-CbCMoarVMではオリジナルのMoarVMと比較して以下の様な利点が見られた.
+CbCMoarVMではオリジナルのMoarVMと比較して以下の様な利点が見られた．
 \begin{itemize}
 \item CodeGear単位で命令処理を記述する事が可能となり, モジュール化が可能となった.
-\item ThreadedCodeを実装する際に効率的に実装ができる見込みが立った.
+\item ThreadedCodeを実装する際に効率的に実装ができる見込みが立った．
-\item CodeGearを導入した命令単位での最適化が可能となった.
+\item CodeGearを導入した命令単位での最適化が可能となった．
-\item break pointを命令の処理単位でかける事が可能となった.
+\item break pointを命令の処理単位でかける事が可能となった．
 \end{itemize}
 今後CbCでの開発をより深く行っていくにあたり, CbCコンパイラそのものの信頼性を向上させる必要がある．
 MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し, より安定するコンパイラにする為に改良を行う．
-現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストはJVM, JavaScriptのテストを除く中で80\%パスする．
+現在CbCMoarVMで直接バイトコードを入力した場合のNQPのテストはJVM, JavaScriptのテストを除く中で80\%パスする．
 また数値の計算と出力などの簡単なNQPの例題を作成し, オリジナルのNQP,MoarVMでバイトコード化したものを入力した際も正常に動作している．
 しかしNQPのセルフビルドは現在オブジェクトの生成に一部失敗している為成功していない．
 今後はさらに複雑な例題やNQPのセルフビルド, Perl6の動作を行っていく．
 MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し, 局所変数のポインタをスタックに登録する処理を行っている．

Mercurial > hg > Papers > 2019 > anatofuz-prosym

comparison Paper/anatofuz.tex @ 68:96d62f0292d3