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

comparison Paper/anatofuz.tex @ 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

comparison

equal deleted inserted replaced

-:e9d84f38fd2a
+:b2d28fb0b7a3
 通常c\_funcの返り値は-1であるが,csから環境付き継続でmainに帰る為にcsから渡される1がtestの値となる．
 \subsection{言語処理系におけるCbCの応用}
 CbCを言語処理系,特にスクリプト言語に応用すると幾つかの箇所に置いて利点があると推測される．
-CbCにおけるCSはコンパイラの基本ブロックに相当する．
+CbCにおけるCodeGearはコンパイラの基本ブロックに相当する．
 その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeGearの遷移として記述する事が可能である．
 CbCは状態を単位として記述が可能であるため,命令コードなどにおける状態を利用するスクリプト言語の実装は応用例として適していると考えられる．
 \section{Perl6の概要}
 この章では現在までのPerl6の遍歴及びPerl6の言語的な特徴について記載する．
 \subsection{Perl6の構想と初期の処理系}
 Perl6は2002年にLarryWallがPerlを置き換える言語として設計を開始した．
 Perl5の言語的な問題点であるオブジェクト指向機能の強力なサポートなどを取り入れた言語として設計された．
-Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった．Perl6は設計と実装が分離しており様々な処理系が開発されきた．
+Perl5は設計と実装が同一であり,Larryらによって書かれたC実装のみだった．Perl6は設計と実装が分離しており様々な処理系が開発されてきた．
 まず2005年に唐鳳によってHaskellで実装されたPugs\cite{pugs}が登場した．
 Pugsは最初に登場したPerl6実装であり,この実装を基にしてPerl6の仕様も修正された．
 現在Pugsは歴史的な実装となっており,更新はされていない．
 \subsection{Parrot}
 NQPはPerl6のサブセットであるため主な文法などはPerl6に準拠しているが幾つか異なる点が存在する．
 NQPは最終的にはNQP自身でブートストラップする言語であるが,ビルドの最初にはすでに書かれたMoarvMByteCodeを必要とする．
 この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に与えることでnqpのインタプリタが実行される様になっている．
-これはStage0の一連のファイルはmoarvm bytecodeなどで記述されたNQPコンパイラのモジュールである為である．
+これはStage0の一連のファイルはMoarVM bytecodeなどで記述されたNQPコンパイラのモジュールである為である．
-NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている．これらMoarVMBytecodeの拡張子は.moarvmである．
+NQPは6modelと呼ばれるオブジェクトモデルを採用としているが,これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている．これらMoarVMBytecodeの拡張子は.MoarVMである．
-MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.moarvmを実行させることでnqpの対話型環境が起動する．
+MoarVMに対してStage0のディレクトリにライブラリパスを設定し,nqp.MoarVMを実行させることでnqpの対話型環境が起動する．
 \begin{figure}[ht]
 \begin{center}
 \includegraphics[width=70mm]{fig/stagenqp.pdf}
 \end{center}
 またPerl6は漸進的型付け言語である.
 従来のPerlの様に変数に代入する対象の型や文脈に応じて型を変更する動的型言語としての側面を持ちつつ独自に定義した型を始めとする様々な型に静的に変数の型を設定する事が可能である．
 \subsection{現在のPerl6}
-Perl6の言語仕様\cite{perl6design}とその時点での実装状況を纏めた公式ドキュメント\cite{perl6doc}は分離している．
+Perl6の言語仕様\cite{perl6design}とその時点での実装状況をまとめた公式ドキュメント\cite{perl6doc}は分離している．
 従来は言語仕様は自然言語の仕様書であったが,現在はテストスイートである「Roast\cite{roast}」そのものと定義されている．
 現在のPerl6の仕様を読む場合Roastを確認し,現在rakudo上に実装されている機能を見る場合は公式ドキュメントを確認する必要がある．
 \subsection{処理速度}
 現在のPerl6が他のプログラミング言語と比較した場合どのような違いがでるのか計測した．
 この中で実線で書かれている部分はCbCのgoto文で遷移し,波線の箇所は通常のCの関数呼び出しとなっている．
 現在の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}
 \begin{figure}[ht]
 \begin{center}
 MoarVM自体のデバッグはMoarVMのリポジトリにテストコードが付随していない為単体では実行不可能である．
 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても考案する．
 \subsection{MoarVMのBytecodeのデバッグ}
-moarに対してmoarvm bytecodeをdumpオプションを付けて読み込ませるとmoarvmのbytecodeがアセンブラの様に出力される．
+moarに対してMoarVM bytecodeをdumpオプションを付けて読み込ませるとMoarVMのbytecodeがアセンブラの様に出力される．
-しかしこれはmoarvmが実行したbytecodeのトレースではなくmoarvm bytecodeを変換したものに過ぎない．
+しかしこれはMoarVMが実行したbytecodeのトレースではなくMoarVM bytecodeを変換したものに過ぎない．
 また,明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう．
 そのため今回のMoarVMBytecodeインタプリタの実装のデバッグにはこの方法は適さない．
 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある．
 CbC側はCode\ref{cbc_b}に示す様にcbc\_nextにbreak pointを設定する．
 \subsection{CbCコンパイラによるバグ}
 現在までのCbCは複数個の入出力をCodeGearに与えるユースケースで利用していた．
 CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した．
-主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう．
+主にCodeGear間のgotoにおけるtail callフラグの除去や,DataGearとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDataGearのアドレスの周辺を利用してしまう．
-その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである．
+その為DataGearの構造体の値が書き換わり,CからDataGearにreturnした際にDataGearの構造体が破壊されるバグである．
 このバグは先程の並列デバッグを行いながらプログラムカウンタや変数の動きをトレースする事などで発見することが出来る．
 現状ではCbCコンパイラがプログラマの意図と反する挙動を取るためCbCコンパイラのバグを回避するプログラミングが要求されている．
 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない．
 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている．
 今後CbCでの開発をより深く行っていくにあたり,CbCコンパイラそのものの信頼性を向上させる必要がある．
 MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラにする為に改良を行う．
 現在CbCMoarVMで直接バイトコードを入力した場合のnqpのテストはおおよそパスする．
-また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,moarvmでバイトコード化したものを入力した際も正常に動作している．
+また数値の計算と出力などの簡単なNQPの例題を作成し,オリジナルのNQP,MoarVMでバイトコード化したものを入力した際も正常に動作している．
 しかしNQPのセルフビルドは現在オブジェクトの生成に一部失敗している為成功していない．
 今後はさらに複雑な例題やNQPのセルフビルド，Perl6の動作を行っていく．
 MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し,局所変数のポインタをスタックに登録する処理を行っている．
 GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeGearの優位性が損なわれてしまう．

Mercurial > hg > Papers > 2019 > anatofuz-prosym

comparison Paper/anatofuz.tex @ 46:b2d28fb0b7a3