Mercurial > hg > Papers > 2019 > anatofuz-prosym
changeset 46:b2d28fb0b7a3
tweak anatofuz.tex
author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 09 Nov 2018 16:11:54 +0900 |
parents | e9d84f38fd2a |
children | 6fc015dd380b |
files | Paper/anatofuz.pdf Paper/anatofuz.tex Paper/src/cbc_example.cbc Paper/src/return.cbc |
diffstat | 4 files changed, 20 insertions(+), 20 deletions(-) [+] |
line wrap: on
line diff
--- a/Paper/anatofuz.tex Fri Nov 09 16:02:39 2018 +0900 +++ b/Paper/anatofuz.tex Fri Nov 09 16:11:54 2018 +0900 @@ -133,7 +133,7 @@ \subsection{言語処理系におけるCbCの応用} CbCを言語処理系,特にスクリプト言語に応用すると幾つかの箇所に置いて利点があると推測される. -CbCにおけるCSはコンパイラの基本ブロックに相当する. +CbCにおけるCodeGearはコンパイラの基本ブロックに相当する. その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeGearの遷移として記述する事が可能である. CbCは状態を単位として記述が可能であるため,命令コードなどにおける状態を利用するスクリプト言語の実装は応用例として適していると考えられる. @@ -142,7 +142,7 @@ \subsection{Perl6の構想と初期の処理系} Perl6は2002年にLarryWallがPerlを置き換える言語として設計を開始した. Perl5の言語的な問題点であるオブジェクト指向機能の強力なサポートなどを取り入れた言語として設計された. -Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった.Perl6は設計と実装が分離しており様々な処理系が開発されきた. +Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった.Perl6は設計と実装が分離しており様々な処理系が開発されてきた. まず2005年に唐鳳によってHaskellで実装されたPugs\cite{pugs}が登場した. Pugsは最初に登場したPerl6実装であり,この実装を基にしてPerl6の仕様も修正された. 現在Pugsは歴史的な実装となっており,更新はされていない. @@ -188,13 +188,13 @@ このMoarVM~yteCodeの状態をStage0と言い,ディレクトリ名として設定されている. Perl6の一部はNQPを拡張したもので書かれている為,Rakudoを動作させる為にはMoarVMなどのVM,VMに対応させる様にビルドしたNQPがそれぞれ必要となる. 現在のNQPではMoarVM,JVMに対応するStage0はそれぞれMoarVMBytecode,jarファイルが用意されており,Javascriptではバイトコードの代わりにランタイム独自のModuleLoaderなどが設計されている. -MoarVMのModuleLoaderはStage0あるMoarVMBytecodeで書かれた一連のファイルが該当する. +MoarVMのModuleLoaderはStage0にあるMoarVMBytecodeで書かれた一連のファイルが該当する. -Stage0にあるファイルをmoarvmに与えることでnqpのインタプリタが実行される様になっている. -これはStage0の一連のファイルはmoarvm bytecodeなどで記述されたNQPコンパイラのモジュールである為である. -NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている.これらMoarVMBytecodeの拡張子は.moarvmである. -MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.moarvmを実行させることでnqpの対話型環境が起動する. +Stage0にあるファイルをMoarVMに与えることでnqpのインタプリタが実行される様になっている. +これはStage0の一連のファイルはMoarVM bytecodeなどで記述されたNQPコンパイラのモジュールである為である. +NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている.これらMoarVMBytecodeの拡張子は.MoarVMである. +MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.MoarVMを実行させることでnqpの対話型環境が起動する. \begin{figure}[ht] \begin{center} @@ -225,7 +225,7 @@ \subsection{現在のPerl6} -Perl6の言語仕様\cite{perl6design}とその時点での実装状況を纏めた公式ドキュメント\cite{perl6doc}は分離している. +Perl6の言語仕様\cite{perl6design}とその時点での実装状況をまとめた公式ドキュメント\cite{perl6doc}は分離している. 従来は言語仕様は自然言語の仕様書であったが,現在はテストスイートである「Roast\cite{roast}」そのものと定義されている. 現在のPerl6の仕様を読む場合Roastを確認し,現在rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある. @@ -346,7 +346,7 @@ 現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextが行っていた. その為cbc\_nextから命令コードに対応するCodeGearに継続し,CodeGearからcbc\_nextに継続するサイクルが基本の流れである. CodeGear内からCの関数は問題なく呼ぶ事が可能であるため,Cの関数を利用する処理は変更せず記述する事ができる. -また変換対象はswitch文であるため,breakせず下に落ちた場合に対応するように別のCodeGearに継続し,その後cbc\_nextに継続するパターンも存在する. +また変換対象はswitch文であるため,breakせず次のcaseに移行した場合に対応するように別のCodeGearに継続し,その後cbc\_nextに継続するパターンも存在する. \lstinputlisting[label=cbc_codesegs_c, caption=CbCMoarVMのバイトコードに対応するCodeGear]{./src/cbc_codesegs.cbc} @@ -419,8 +419,8 @@ 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても考案する. \subsection{MoarVMのBytecodeのデバッグ} -moarに対してmoarvm bytecodeをdumpオプションを付けて読み込ませるとmoarvmのbytecodeがアセンブラの様に出力される. -しかしこれはmoarvmが実行したbytecodeのトレースではなくmoarvm bytecodeを変換したものに過ぎない. +moarに対してMoarVM bytecodeをdumpオプションを付けて読み込ませるとMoarVMのbytecodeがアセンブラの様に出力される. +しかしこれはMoarVMが実行したbytecodeのトレースではなくMoarVM bytecodeを変換したものに過ぎない. また,明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう. そのため今回のMoarVMBytecodeインタプリタの実装のデバッグにはこの方法は適さない. 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある. @@ -459,8 +459,8 @@ \subsection{CbCコンパイラによるバグ} 現在までのCbCは複数個の入出力をCodeGearに与えるユースケースで利用していた. CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した. -主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう. -その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである. +主にCodeGear間のgotoにおけるtail callフラグの除去や,DataGearとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDataGearのアドレスの周辺を利用してしまう. +その為DataGearの構造体の値が書き換わり,CからDataGearにreturnした際にDataGearの構造体が破壊されるバグである. このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る. 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている. 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない. @@ -547,7 +547,7 @@ MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラにする為に改良を行う. 現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストはおおよそパスする. -また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,moarvmでバイトコード化したものを入力した際も正常に動作している. +また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,MoarVMでバイトコード化したものを入力した際も正常に動作している. しかしNQPのセルフビルドは現在オブジェクトの生成に一部失敗している為成功していない. 今後はさらに複雑な例題やNQPのセルフビルド,Perl6の動作を行っていく.
--- a/Paper/src/cbc_example.cbc Fri Nov 09 16:02:39 2018 +0900 +++ b/Paper/src/cbc_example.cbc Fri Nov 09 16:11:54 2018 +0900 @@ -2,15 +2,15 @@ int main (){ int data = 0; - goto cs1(&data); + goto cg1(&data); } -__code cs1(int *datap){ +__code cg1(int *datap){ (*datap)++; - goto cs2(datap); + goto cg2(datap); } -__code cs2(int *datap){ +__code cg2(int *datap){ (*datap)++; printf("%d\n",*datap); }
--- a/Paper/src/return.cbc Fri Nov 09 16:02:39 2018 +0900 +++ b/Paper/src/return.cbc Fri Nov 09 16:11:54 2018 +0900 @@ -1,9 +1,9 @@ -__code cs(__code (*ret)(int,void *),void *env){ +__code cg(__code (*ret)(int,void *),void *env){ goto ret(1,env); } int c_func(){ - goto cs(_CbC_return,_CbC_environment); + goto cg(_CbC_return,_CbC_environment); return -1; }