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

comparison Paper/anatofuz.tex @ 28:f200e3702c5a

update register info

author	Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp>
date	Fri, 09 Nov 2018 01:56:17 +0900
parents	df723be56106
children	765dc5c49ae1

comparison

equal deleted inserted replaced

-:df723be56106
+:f200e3702c5a
 Rakudoにおけるコンパイラとは厳密には2種類存在する．
 まず第1のものがPerl6,もしくはNQPをMoarVM,JVMのバイトコードに変換するNQPコンパイラである．
 次にそのNQPが出力したバイトコードをネイティブコードに変換するVMの2種類である．
 このVMは現在MoarVM,JavaVM,Javascriptを選択可能である．
 Rakudo及びNQP projectではこのNQPコンパイラの部分をフロントエンド，VMの部分をバックエンド\cite{rani1}と呼称している．
-NQPで主に書かれたPerl6のことをRakudoと呼ぶ．
+NQPで主に書かれ，MoarVMなどNQPが動作する環境で動くPerl6のことをRakudoと呼ぶ．
-Perl6はNQP以外にもPerl6独自の一種のシンタックスシュガーの様な物を持っており，これはNQPコンパイラ側で処理を行う．
+Perl6はNQP以外にものNQPを拡張したPerl6自身で書かれている箇所が存在し，これはNQPコンパイラ側でMoarVMが解釈可能な形へ変換を行う．
 \begin{figure}[ht]
 \begin{center}
 \includegraphics[width=70mm]{fig/perl6nqp.pdf}
 \end{center}
 そのため対象となるCodeSegmentをLABLESの並びと対応させ，配列CODESに設定すればCodeSegmentの名前は問わない．
 今回はCodeSegmentである事を示す為にsuffixとしてcbc\_をつける．
 命令の実行処理でMoarVMのレジスタであるreg\_baseや命令列cur\_opなどの情報を利用しているが，これらはMVM\_interp\_run内のローカル変数として利用している．
 ラベルを利用しているオリジナル版では同一関数内であるためアクセス可能であるが，CodeSegment間の移動で命令を表現するCbCではアクセスできない．
-その為インタプリタの情報を集約した構造体interを定義し，この構造体へのポインタであるINTERP型の変数iをCodeSegmentの入出力して与える．
+その為インタプリタの情報を集約した構造体interを定義し，この構造体へのポインタであるINTERP型の変数iをCodeSegmentの入出力として与える．
 CodeSegment内ではINTERPを経由することでインタプリタの各種情報にアクセスする．
+CodeSegment間の遷移ではレジスタの値の調整は行われない為，入力引数を使ってレジスタマッピングを管理できる．
+その為INTERPのメンバであるMoarVMのレジスタそのものをアーキテクチャのレジスタ上に乗せる事が可能である．
 命令実行中のCodeSegmentの遷移を図\ref{fig:perl6cbcinter}に示す．
 この中で実線で書かれている部分はCbCのgoto文で遷移し，波線の箇所は通常のCの関数呼び出しとなっている．
 現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している．
 \end{figure}
 現在CbCで記述されたOSであるGearsOSにはInterfaceが導入されている．
 これはJavaのinterface,Haskellの型クラスに該当する概念であり，次のCodeSegmentにInterface経由で継続する事が可能である．
 Interfaceは現在のMoarVMには実装されていない為，今後ThreadeCodeの実装を行うにあたり導入を検討している．
+\subsection{Threaded Code}
+現在のMoarVMは次の命令をバイトコードからディスパッチし決定後，ラベルジャンプを利用し実行している．
+この処理ではディスパッチの箇所にコストが掛かってしまう．
+CbCをMoarVMに導入することで，バイトコード列を直接サブルーチンコールの列に置き換えてしまう事が可能である．
+これはCbCが基本ブロックの単位と対応している為である．
+また段階的に現在8バイト列を1命令コードとして使用しているが，これを16バイトなどに拡張し2命令を同時に扱えるように実装する事なども可能である．
+%CbCはCodeSegmentで末尾最適化(Tail call optimization)を行う．
+%これはCodeSegmentは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である．
+%現在のCbCコンパイラの実装ではCodeSegmentからCの関数に戻る場合は末尾最適化を切り，CodeSegment間の遷移では末尾最適化が行われる．
+%末尾最適化を応用することでContinuation-passingスタイルのThreaded Codeの実装が可能となる．\cite{threadedcode}
+%またCodeSegment自体を直接次の遷移先として設定することも可能であるため，CbCならThrededCodeを実装するアプローチが複数検討出来る．
+%現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している．
+%これは元のMoarVMの命令ディスパッチで行われる現在のオペコードを示すcur\_opと命令列opの操作及び次のラベルに遷移するマクロに該当する．
+%CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし，その要素であるCodeSegmentに対して遷移する形を取っている．
+%この一連の処理がオーバーヘッドになる為，今後はcbc\_fixt\_nextというCodeSegmentを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である．
+\subsubsection{perlcc}
+Perl5においてはperlccというモジュールが開発されている．
+これはPerl5内部で利用しているPerlバイトコードを，PerlのC APIであるXS言語の様なCのソースファイルに埋め込み，それをCコンパイルでコンパイルするというものである．
+perlccを利用することでPerlインタプリタが無い状況でも可動するバイナリファイルを作成する事が可能である．
+しかしPerlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず，現在ではPerlのコアモジュールから外されている．
+PerlccはPerlのバイトコードをCへの変換のみ行う為,Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない．
+またPerlccで生成されたCのソースコードは難解であり，これをデバッグするのが困難でもある．
+MoarVMでthreaded codeを実現出来た場合，その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である．
+この場合,Perl6を通常動かした際とは異なりバイトコードインタプリタに到達する前の処理が無くなる為多少の高速化が望めると推測できる.
 \subsection{MoarVMのBytecodeのデバッグ}
 moarに対してmoarvm bytecodeをdumpオプションを付けて読み込ませるとmoarvmのbytecodeがアセンブラの様に出力される．
 しかしこれはmoarvmが実行したbytecodeのトレースではなくmoarvm bytecodeを変換したものに過ぎない．
 また，明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう．
 このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る．
 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている．
 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない．
 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている．
-また現在はclang上に実装したCbCコンパイラではtaill call除去のエラーが発生してしまう為コンパイルする事が出来ない．
+また現在はclang上に実装したCbCコンパイラではCodeSegment内部のtaill call除去のエラーが発生してしまう為コンパイルする事が出来ない．
 その為現在はgcc上に実装したcbcコンパイラを利用しgdbを利用しデバッグを行う．
-\subsection{Threaded Code}
-CbCはCodeSegmentで末尾最適化(Tail call optimization)を行う．
-これはCodeSegmentは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である．
-現在のCbCコンパイラの実装ではCodeSegmentからCの関数に戻る場合は末尾最適化を切り，CodeSegment間の遷移では末尾最適化が行われる．
-末尾最適化を応用することでContinuation-passingスタイルのThreaded Codeの実装が可能となる．\cite{threadedcode}
-またCodeSegment自体を直接次の遷移先として設定することも可能であるため，CbCならThrededCodeを実装するアプローチが複数検討出来る．
-%現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している．
-%これは元のMoarVMの命令ディスパッチで行われる現在のオペコードを示すcur\_opと命令列opの操作及び次のラベルに遷移するマクロに該当する．
-%CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし，その要素であるCodeSegmentに対して遷移する形を取っている．
-この一連の処理がオーバーヘッドになる為，今後はcbc\_fixt\_nextというCodeSegmentを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である．
-\subsubsection{perlcc}
-Perl5においてはperlccというモジュールが開発されている．
-これはPerl5内部で利用しているPerlバイトコードを，PerlのC APIであるXS言語の様なCのソースファイルに埋め込み，それをCコンパイルでコンパイルするというものである．
-perlccを利用することでPerlインタプリタが無い状況でも可動するバイナリファイルを作成する事が可能である．
-しかしPerlccはPerlスクリプトが複雑になるほど正確にCに移植を行う事が出来ず，現在ではPerlのコアモジュールから外されている．
-PerlccはPerlのバイトコードをCへの変換のみ行う為,Cで実装されているPerl経由で実行した場合と処理速度はほぼ変わらない．
-またPerlccで生成されたCのソースコードは難解であり，これをデバッグするのが困難でもある．
-MoarVMでthreaded codeを実現出来た場合，その箇所のみCbCプログラムとして切り出す事が可能である為perlccと似たツールを作成することも可能である．
-この場合,Perl6を通常動かした際とは異なりバイトコードインタプリタに到達する前の処理が無くなる為多少の高速化が望めると推測できる.
 \section{CbCを用いる事についての利点と欠点}
 MoarVMの様な巨大なスクリプト言語処理系にCbCを適応した所現在までに複数の利点と欠点が発見された．
 本章ではまず利点を述べ，次に現段階でのCbCを適応した場合の欠点について考察する．

Mercurial > hg > Papers > 2019 > anatofuz-prosym

comparison Paper/anatofuz.tex @ 28:f200e3702c5a