# HG changeset patch # User Takahiro SHIMIZU # Date 1541745210 -32400 # Node ID 571f6ffcccf81764b86573d435fc87eba34b2453 # Parent f4d4cbf62aeab672932dcf51da0b04343b7d1cae mv CodeSegment to CodeGear and Datasegment to Datagear diff -r f4d4cbf62aea -r 571f6ffcccf8 Paper/anatofuz.pdf Binary file Paper/anatofuz.pdf has changed diff -r f4d4cbf62aea -r 571f6ffcccf8 Paper/anatofuz.tex --- a/Paper/anatofuz.tex Fri Nov 09 15:23:15 2018 +0900 +++ b/Paper/anatofuz.tex Fri Nov 09 15:33:30 2018 +0900 @@ -84,24 +84,24 @@ Cレベルでのプログラミングを行う場合,本来プログラマが行いたい処理の他にmallocなどを利用したメモリのアロケートやエラーハンドリングなどを記述する必要がある． これらの処理をmeta computationと呼ぶ．これらmeta computationと通常の処理を分離することでバグの原因がmeta computation側にあるか処理側にあるかの分離などが可能となる． しかしC言語などを用いたプログラミングでmeta computationの分離を行おうとすると,それぞれ事細かに関数やクラスを分割せねばならず容易ではない． -CbCでは関数よりmeta computationを細かく記述する為にCodeSegmentという単位を導入した． -またCodeSegmentの実行に必要なデータをDataSegmentという単位で受け渡す． -CbCではCodeSegment,DetaSegmentを基本単位として記述するプログラミングスタイルを取る． +CbCでは関数よりmeta computationを細かく記述する為にCodeGearという単位を導入した． +またCodeGearの実行に必要なデータをDataGearという単位で受け渡す． +CbCではCodeGear,DetaSegmentを基本単位として記述するプログラミングスタイルを取る． -\subsection{CodeSegmentとDataSegment} -CbCではCの関数の代わりにCodeSegmentを導入する． -CodeSegmentはCの関数宣言の型名の代わりに\_\_codeと書くことで 宣言できる． -\_\_codeはCbCコンパイラの扱いはvoidと同じ型であるが,CbCプログラミングではCodeSegmentである事を示す識別子としての意味で利用する． -CodeSegment間の移動はgoto文によって記述する． +\subsection{CodeGearとDataGear} +CbCではCの関数の代わりにCodeGearを導入する． +CodeGearはCの関数宣言の型名の代わりに\_\_codeと書くことで 宣言できる． +\_\_codeはCbCコンパイラの扱いはvoidと同じ型であるが,CbCプログラミングではCodeGearである事を示す識別子としての意味で利用する． +CodeGear間の移動はgoto文によって記述する． \lstinputlisting[label=cbcexample, caption=cbc\_example.cbc]{./src/cbc_example.cbc} Code\ref{cbcexample}に示すCbCのコードではmain関数からcs1,cs2に遷移し,最終的にdataの値が2となる． -CodeSegment間の入出力の受け渡しは引数を利用する．この引数は小さなDataSegmentであると言える． +CodeGear間の入出力の受け渡しは引数を利用する．この引数は小さなDataGearであると言える． \subsection{軽量継続} %TBD -CbCでは次のCodeSegmentに移行する際,Cのgoto文を利用する． +CbCでは次のCodeGearに移行する際,Cのgoto文を利用する． 通常のCの関数呼び出しの場合,スタックポインタを操作しローカル変数などをスタックに保存する． -CbCの場合スタックフレームを操作せず,レジスタの値を変更せずそのまま次のCodeSegmentに遷移する事が可能である． +CbCの場合スタックフレームを操作せず,レジスタの値を変更せずそのまま次のCodeGearに遷移する事が可能である． 通常Sechemeのcall/ccなどの継続は現在の位置までの情報を環境として所持した状態で遷移する． 対してCbCは環境を持たず遷移する為,通常の継続と比較して軽量であることから軽量継続であると言える． CbCは軽量継続を利用するためレジスタレベルでのきめ細やかな実装が可能となっている． @@ -113,18 +113,18 @@ \subsection{CbCコンパイラのバグ} % 局所変数のポインタを握ったままgotoするとtail callにならない CbCコンパイラは現在も開発中であり幾つかのバグが発見されている． -まずCodeSegment内で宣言した局所変数のポインタを別の変数などで確保した状態でgotoしてしまうとtail call最適化が切られる． +まずCodeGear内で宣言した局所変数のポインタを別の変数などで確保した状態でgotoしてしまうとtail call最適化が切られる． これはただの関数呼び出しになってしまう為,直接的な被害はないもののCbCとしての利点が損なわれてしまう． また本来は操作しないはずのスタック領域の操作が入ってしまうため,プログラマの意図と反したスタックポインタなのど操作が行われてしまいバグが発生する可能性が存在する． \subsection{CbCとCの互換性} CbCコンパイラは内部的に与えられているソースコードがCbCであるかどうかを判断する． -この際にCodeSegmentを利用していない場合は通常のCプログラムとして動作する． +この際にCodeGearを利用していない場合は通常のCプログラムとして動作する． その為今回検証するMoarVMのビルドにおいてもCbCで書き換えたソースコードがあるMoarVMと,手を加えていないオリジナルのMoarVMの2種類を同一のCbCコンパイラでビルドする事が可能である． またCからCbCへの遷移時に,再びCの関数に戻るように実装したい場合がある． その際は環境付きgotoと呼ばれる手法を取る．これは\_CbC\_return及び\_CbC\_environmentという変数を渡す． -この変数は\_CbC\_returnが元の環境に戻る際に利用するCodeSegmentを指し,\_CbC\_environmentは復帰時に戻す元の環境である． +この変数は\_CbC\_returnが元の環境に戻る際に利用するCodeGearを指し,\_CbC\_environmentは復帰時に戻す元の環境である． 復帰する場合,呼び出した位置には帰らず,呼び出した関数の終了する位置に帰る． \lstinputlisting[label=cbcreturn, caption=環境付き継続の例]{./src/return.cbc} Code\ref{cbcreturn}に示す例ではc\_funcから環境付き継続でがcsに継続している． @@ -134,7 +134,7 @@ \subsection{言語処理系におけるCbCの応用} CbCを言語処理系,特にスクリプト言語に応用すると幾つかの箇所に置いて利点があると推測される． CbCにおけるCSはコンパイラの基本ブロックに相当する． -その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeSegmentの遷移として記述する事が可能である． +その為従来のスクリプト言語では主にcase文で記述していた命令コードディスパッチの箇所をCodeGearの遷移として記述する事が可能である． CbCは状態を単位として記述が可能であるため,命令コードなどにおける状態を利用するスクリプト言語の実装は応用例として適していると考えられる． \section{Perl6の概要} @@ -293,8 +293,8 @@ \subsection{方針} MoarVMそのものをCbCで書き換えることも考えられるがMoarVM自体既に巨大なプロジェクトである為すべてを書き換える事は困難である． その為まず比較的CbCで書き換えることが容易な箇所を修正する． -前章までに述べた通りCbCのCodeSegmentはコンパイラの基本ブロックに該当する． -従ってMoarVMにおける基本ブロックの箇所をCodeSegmentに書き換える事が可能である． +前章までに述べた通りCbCのCodeGearはコンパイラの基本ブロックに該当する． +従ってMoarVMにおける基本ブロックの箇所をCodeGearに書き換える事が可能である． MoarVMにおける基本ブロックはインタプリタが実行するバイトコードごとの処理に該当する． \subsection{MoarByteCodeのディスパッチ} @@ -317,38 +317,38 @@ \lstinputlisting[label=dispatch_c, caption=オリジナル版MoarVMのバイトコードディスパッチ]{./src/dispatch.c} interp.cでは命令コードのディスパッチはマクロを利用したcur\_opの計算及びラベルの遷移，もしくはマクロDISPATCHが展開するswitch文で行われていた． -CbCMoarVMではこの問題を解決するために,それぞれの命令に対応するCodeSegmentを作成し,CodeSegment名前を要素として持つCbCのCodeSegmentのテーブルを作成した． -このCodeSegmentのテーブルを参照するCodeSegmentはcbc\_nextであり，この中のマクロNEXTはinterp.cのマクロNEXTをCbC用に書き直したものである． +CbCMoarVMではこの問題を解決するために,それぞれの命令に対応するCodeGearを作成し,CodeGear名前を要素として持つCbCのCodeGearのテーブルを作成した． +このCodeGearのテーブルを参照するCodeGearはcbc\_nextであり，この中のマクロNEXTはinterp.cのマクロNEXTをCbC用に書き直したものである． \lstinputlisting[label=cbc_dispatch_c, caption=CbCMoarVMのバイトコードディスパッチ]{./src/cbc-interp-next.cbc} -\subsection{命令実行箇所のCodeSegmentへの変換} -ラベルテーブルやcase文のswitch相当の命令実行箇所をCbCに変換し,CodeSegmentの遷移として利用する． +\subsection{命令実行箇所のCodeGearへの変換} +ラベルテーブルやcase文のswitch相当の命令実行箇所をCbCに変換し,CodeGearの遷移として利用する． interp.cはCode\ref{dispatch_c}に示すスタイルで記述されている． OP(.*)の.*に該当する箇所はバイトコードの名前である．通常このブロックにはLABELから遷移する為,バイトコードの名前はLABELSの配列の添字に変換されている． -そのため対象となるCodeSegmentをLABLESの並びと対応させ,CodeSegmentの配列CODESとして設定すればCodeSegmentの名前は問わない． -今回はCodeSegmentである事を示す為にsuffixとしてcbc\_をつける． +そのため対象となるCodeGearをLABLESの並びと対応させ,CodeGearの配列CODESとして設定すればCodeGearの名前は問わない． +今回はCodeGearである事を示す為にsuffixとしてcbc\_をつける． 命令の実行処理でMoarVMのレジスタであるreg\_baseや命令列cur\_opなどの情報を利用しているが,これらはMVM\_interp\_run内のローカル変数として利用している． -ラベルを利用しているオリジナル版では同一関数内であるためアクセス可能であるが,CodeSegment間の移動で命令を表現するCbCではアクセスできない． -その為インタプリタの情報を集約した構造体interを定義し,この構造体へのポインタであるINTERP型の変数iをCodeSegmentの入出力として与える． -CodeSegment内ではINTERPを経由することでインタプリタの各種情報にアクセスする． -CodeSegment間の遷移ではレジスタの値の調整は行われない為,入力引数を使ってレジスタマッピングを管理できる． +ラベルを利用しているオリジナル版では同一関数内であるためアクセス可能であるが,CodeGear間の移動で命令を表現するCbCではアクセスできない． +その為インタプリタの情報を集約した構造体interを定義し,この構造体へのポインタであるINTERP型の変数iをCodeGearの入出力として与える． +CodeGear内ではINTERPを経由することでインタプリタの各種情報にアクセスする． +CodeGear間の遷移ではレジスタの値の調整は行われない為,入力引数を使ってレジスタマッピングを管理できる． その為INTERPのメンバであるMoarVMのレジスタそのものをアーキテクチャのレジスタ上に乗せる事が可能である． -命令実行中のCodeSegmentの遷移を図\ref{fig:perl6cbcinter}に示す． +命令実行中のCodeGearの遷移を図\ref{fig:perl6cbcinter}に示す． この中で実線で書かれている部分はCbCのgoto文で遷移し,波線の箇所は通常のCの関数呼び出しとなっている． 現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextが行っていた． -その為cbc\_nextから命令コードに対応するCodeSegmentに継続し，CodeSegmentからcbc\_nextに継続するサイクルが基本の流れである． -CodeSegment内からCの関数は問題なく呼ぶ事が可能であるため，Cの関数を利用する処理は変更せず記述する事ができる． -また変換対象はswitch文であるため，breakせず下に落ちた場合に対応するように別のCodeSegmentに継続し，その後cbc\_nextに継続するパターンも存在する． +その為cbc\_nextから命令コードに対応するCodeGearに継続し，CodeGearからcbc\_nextに継続するサイクルが基本の流れである． +CodeGear内からCの関数は問題なく呼ぶ事が可能であるため，Cの関数を利用する処理は変更せず記述する事ができる． +また変換対象はswitch文であるため，breakせず下に落ちた場合に対応するように別のCodeGearに継続し，その後cbc\_nextに継続するパターンも存在する． -\lstinputlisting[label=cbc_codesegs_c, caption=CbCMoarVMのバイトコードに対応するCodeSegment]{./src/cbc_codesegs.cbc} +\lstinputlisting[label=cbc_codesegs_c, caption=CbCMoarVMのバイトコードに対応するCodeGear]{./src/cbc_codesegs.cbc} \begin{figure}[ht] \begin{center} @@ -359,15 +359,15 @@ \end{figure} バイトコードの数は膨大である為,すべてを手作業で変換する事は望ましくない． -本研究ではPerlScriptを用いてinterp.cからCbCのCodeSegmentを自動生成するスクリプトを作成した． +本研究ではPerlScriptを用いてinterp.cからCbCのCodeGearを自動生成するスクリプトを作成した． このスクリプトでは以下の修正手続きを実行する． \begin{itemize} - \item OP(.*)の.*部分をCodeSegmentの名前として,先頭にcbc\_をつけた上で設定する． + \item OP(.*)の.*部分をCodeGearの名前として,先頭にcbc\_をつけた上で設定する． \item cur\_opなど構造体INTERのメンバ変数はポインタiから参照するように修正する \item GC対策のためマクロMVMROOTを使い局所変数のポインタをスタックに積む箇所は,局所変数をstatic化する \item 末尾のgoto NEXTをgoto cbc\_next(i)に修正する - \item case文で下のcase文に落ちている箇所は,case文に対応するCodeSegmentに遷移する様にgoto文を付け加える + \item case文で下のcase文に落ちている箇所は,case文に対応するCodeGearに遷移する様にgoto文を付け加える \end{itemize} @@ -375,7 +375,7 @@ またcbc\_pushcompscではMVMROOTに局所変数scを渡している為，これをstaticで宣言し直している． 現在CbCで記述されたOSであるGearsOSにはInterfaceが導入されている． -これはJavaのinterface,Haskellの型クラスに該当する概念であり,次のCodeSegmentにInterface経由で継続する事が可能である． +これはJavaのinterface,Haskellの型クラスに該当する概念であり,次のCodeGearにInterface経由で継続する事が可能である． Interfaceは現在のMoarVMには実装されていない為,今後ThreadeCodeの実装を行うにあたり導入を検討している． \subsection{Threaded Code} @@ -383,21 +383,21 @@ この処理ではディスパッチの箇所にコストが掛かってしまう． CbCをMoarVMに導入することで,バイトコード列を直接サブルーチンコールの列に置き換えてしまう事が可能である． これはCbCが基本ブロックの単位と対応している為である． -CbCでは現在ディスパッチを行うCodeSegmentであるcbc\_nextを利用しているが,Threaded Codeを実装するにあたり, -cbc\_nextと次のCodeSegmentに直接遷移するcbc\_fixt\_nextの実装を予定している． +CbCでは現在ディスパッチを行うCodeGearであるcbc\_nextを利用しているが,Threaded Codeを実装するにあたり, +cbc\_nextと次のCodeGearに直接遷移するcbc\_fixt\_nextの実装を予定している． また段階的に現在8バイト列を1命令コードとして使用しているが,これを16バイトなどに拡張し2命令を同時に扱えるように実装する事なども検討している． -%CbCはCodeSegmentで末尾最適化(Tail call optimization)を行う． -%これはCodeSegmentは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である． -%現在のCbCコンパイラの実装ではCodeSegmentからCの関数に戻る場合は末尾最適化を切り,CodeSegment間の遷移では末尾最適化が行われる． +%CbCはCodeGearで末尾最適化(Tail call optimization)を行う． +%これはCodeGearは必ず関数呼び出しではなくgotoで次の状態に遷移する為にスタック領域の操作が必要とならない為である． +%現在のCbCコンパイラの実装ではCodeGearからCの関数に戻る場合は末尾最適化を切り,CodeSegment間の遷移では末尾最適化が行われる． %末尾最適化を応用することでContinuation-passingスタイルのThreaded Codeの実装が可能となる．\cite{threadedcode} -%またCodeSegment自体を直接次の遷移先として設定することも可能であるため,CbCならThrededCodeを実装するアプローチが複数検討出来る． +%またCodeGear自体を直接次の遷移先として設定することも可能であるため,CbCならThrededCodeを実装するアプローチが複数検討出来る． -%現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeSegmentで処理している． +%現在のCbCMoarVMは次の命令セットのディスパッチをcbc\_nextというCodeGearで処理している． %これは元のMoarVMの命令ディスパッチで行われる現在のオペコードを示すcur\_opと命令列opの操作及び次のラベルに遷移するマクロに該当する． -%CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeSegmentの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する形を取っている． -%この一連の処理がオーバーヘッドになる為,今後はcbc\_fixt\_nextというCodeSegmentを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である． +%CbCMoarVMではラベルに対しての遷移の代わりにMoarVMの命令のCodeGearの集合体である配列CODESにアクセスし,その要素であるCodeSegmentに対して遷移する形を取っている． +%この一連の処理がオーバーヘッドになる為,今後はcbc\_fixt\_nextというCodeGearを導入し直接次の命令に該当するCodeSegmentへgotoする様に実装する予定である． \subsubsection{perlcc} Perl5においてはperlccというモジュールが開発されている． @@ -410,8 +410,8 @@ この場合,Perl6を通常動かした際とは異なりバイトコードインタプリタに到達する前の処理が無くなる為多少の高速化が望めると推測できる. \subsection{Cのインライン展開} -CbCのCodeSegmentはgoto文で遷移するため,次のCodeSegmentが一意に決定している場合Cコンパイラ側でインライン展開する事が可能である． -CodeSegmentがインライン展開される限界については別途研究する必要があるが,CbCを利用した場合その箇所でもコストを低く設計する事が可能である． +CbCのCodeGearはgoto文で遷移するため,次のCodeGearが一意に決定している場合Cコンパイラ側でインライン展開する事が可能である． +CodeGearがインライン展開される限界については別途研究する必要があるが,CbCを利用した場合その箇所でもコストを低く設計する事が可能である． \section{MoarVMのデバッグ} @@ -427,7 +427,7 @@ CbC側はCode\ref{cbc_b}に示す様にcbc\_nextにbreak pointを設定する． オリジナル側は次のオペコードの設定のマクロにダミーの関数を呼び出すように修正し,そこにbreak pointを設定する． -CbC側ではCodeSegmentの名前をデバッガ上で直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかをデバッガの外で探す必要がある． +CbC側ではCodeGearの名前をデバッガ上で直接確認できるが,オリジナル版はLABLEの配列の添え字から自分でどのオペコードに対応しているかをデバッガの外で探す必要がある． 添字を確認するためにはCode\ref{orig_b}に示すようにオリジナルのMoarVMの場合cur\_opの値をMVMuint16のポインタでキャストし,これが指す値を出力する． break pointを掛けているダミー関数ではcur\_opにアクセスする事が出来ない為,スタックフレームを一つupする必要がある． @@ -450,14 +450,14 @@ これらはscriptコマンドが作成したログを元に異なる箇所を発見するスクリプトを用意し自動化する． \lstinputlisting[label=logs2, caption=バイトコードの差分検知の一部分]{./src/logs2.txt} -違いが生じている箇所が発見できた場合,その前後のCodeSegment及びディスパッチ部分にbreak pointをかけ,それぞれの変数の挙動を比較する． +違いが生じている箇所が発見できた場合,その前後のCodeGear及びディスパッチ部分にbreak pointをかけ,それぞれの変数の挙動を比較する． 主にcbc\_return系の命令が実行されている場合は,その直前で命令を切り替えるcbc\_invoke系統の命令が呼ばれているが,この周辺で何かしらの違いが発生している可能性が高い． -また主に次のCodeSegmentに遷移する際にCbCコンパイラのバグが生じている可能性もある為,アセンブラレベルの命令を確認しながらデバッグを進めることとなる． +また主に次のCodeGearに遷移する際にCbCコンパイラのバグが生じている可能性もある為,アセンブラレベルの命令を確認しながらデバッグを進めることとなる． \subsection{CbCコンパイラによるバグ} -現在までのCbCは複数個の入出力をCodeSegmentに与えるユースケースで利用していた． +現在までのCbCは複数個の入出力をCodeGearに与えるユースケースで利用していた． CbCコンパイラ自身はそれぞれ用意したテストスイートを通化するものの,MoarVMの様な巨大なプロジェクトのCSをコンパイルを実行する場合,予期せぬバグが発生した． 主にCS間のgotoにおけるtail callフラグの除去や,DSとして渡している構造体の変数のアドレスがスタックポインタの値より上位に来てしまい,通常のCの関数をcallした際にローカル変数の領域がDSのアドレスの周辺を利用してしまう． その為DSの構造体の値が書き換わり,CからDSにreturnした際にDSの構造体が破壊されるバグである． @@ -466,7 +466,7 @@ 本来コンパイラ側のバグを回避するプログラミングをプログラマに要求する事は好ましくない． 従ってCbCコンパイラ自身の信頼性を向上させる事も今後の課題となっている． -また現在はclang上に実装したCbCコンパイラではCodeSegment内部のtaill call除去のエラーが発生してしまう為コンパイルする事が出来ない． +また現在はclang上に実装したCbCコンパイラではCodeGear内部のtaill call除去のエラーが発生してしまう為コンパイルする事が出来ない． その為現在はgcc上に実装したcbcコンパイラを利用しgdbを利用しデバッグを行う． @@ -482,18 +482,18 @@ 関数単位での処理の比重が偏る事に加え, switch文中に書かれている処理は他の関数から呼ぶ事が出来ないため,余計な手間がかかる箇所が発生すると考えられる． -CbCMoarVMの場合,CodeSegmentとして基本ブロックを記述出来る為オリジナルのMoarVMの様にswtich文のブロック中に書く必要性が無くなる． +CbCMoarVMの場合,CodeGearとして基本ブロックを記述出来る為オリジナルのMoarVMの様にswtich文のブロック中に書く必要性が無くなる． その為類似する命令系をコード分割し,モジュール化する事が可能である． またCbCはgoto文で遷移する以外は通常のCの関数と同じ扱いをする事が可能である． -従ってCodeSegment内部の処理を別の箇所から使用する事も可能となる為再利用性も向上する． +従ってCodeGear内部の処理を別の箇所から使用する事も可能となる為再利用性も向上する． \subsection{ThreadeCode} ThrededCodeを実装する場合,通常命令ディスパッチの箇所と,実際に実行される命令処理を大幅に変更しなければならない． -CbCを用いた実装の場合,命令処理はただのCodeSegmentの集合である． -その為CodeSegmentをThrededCodeに対応した並びとして選択する事ができれば命令処理部分の修正をほぼせずにThrededCodeを実現する事が可能である． +CbCを用いた実装の場合,命令処理はただのCodeGearの集合である． +その為CodeGearをThrededCodeに対応した並びとして選択する事ができれば命令処理部分の修正をほぼせずにThrededCodeを実現する事が可能である． -またCodeSegmentはバイトコードレベルと同じ扱いができるため,ThrededCodeそのものを分離して最適化をかける事が可能である． -これもCodeSegmentが関数単位として分離できる事からの利点である． +またCodeGearはバイトコードレベルと同じ扱いができるため,ThrededCodeそのものを分離して最適化をかける事が可能である． +これもCodeGearが関数単位として分離できる事からの利点である． \subsubsection{MoarVMのデバッグ} @@ -501,12 +501,12 @@ その為,直接ラベルにbreak pointをかける事が出来ない． 作業者がデバッガが読み込んでいるCソースコードの位置を把握し,行番号を指定してdebug pointを設定する必要があった． -CbCMoarVMの場合,CodeSegment単位でバイトコードの処理単位を記述している為,通常の関数と同じく直接CodeSegmentにデバッグポイントをかける事が可能である． +CbCMoarVMの場合,CodeGear単位でバイトコードの処理単位を記述している為,通常の関数と同じく直接CodeGearにデバッグポイントをかける事が可能である． これはCプログラミングの関数に対してのデバッグで,状態ごとにbreak pointをかける事が出来ることを意味する． 通常のC言語で言語処理系を実装した場合と比較して扱いやすくなっていると言える． さらにラベルテーブルでの管理場合,次のバイトコード箇所は数値でしか確認できず,実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった． スクリプトなどを組めば効率化は出来るがデバッガ上で完結しない為手間がかかる． -CbC実装ではCODESテーブル内は次のCodeSegmentの名前が入っている為,数値からCodeSegmentの名前をデバッガ上で確認する事が出来る． +CbC実装ではCODESテーブル内は次のCodeGearの名前が入っている為,数値からCodeGearの名前をデバッガ上で確認する事が出来る． \subsection{JITコンパイルの応用} 現在MoarVMはLuaJit\cite{luajit}を搭載しJITコンパイルを行っている． @@ -532,16 +532,16 @@ CbCコンパイラはgccとllvm/clangに実装している為,これらのアップデートに追従する必要がある． しかしコンパイラのバージョンに応じてCbCで利用するコンパイラ内のAPIが異なる場合が多く,APIの変更に伴う修正作業などを行う必要がある． -CbCMoarVMではCからCodeSegmentへ,CodeSegmentからCへの遷移などが複数回繰り返されているが,この処理中のCodeSegmentでのtail callの強制が非常に難関である． +CbCMoarVMではCからCodeGearへ,CodeGearからCへの遷移などが複数回繰り返されているが,この処理中のCodeGearでのtail callの強制が非常に難関である． tail callの強制には関数定義の箇所や引数,スタック領域のサイズ修正などを行う必要がある． -現在のバグではCodeSegment内部での不要なスタック操作命令を完全に排除しきれていない． +現在のバグではCodeGear内部での不要なスタック操作命令を完全に排除しきれていない． -またCodeSegmentからCに帰る場合,環境付き継続を行う必要がある． -Cの関数の末尾でCodeSegmentを呼び出している場合など環境付き継続を使用しなくても良いケースは存在するが,頻繁にCとCbCを行き来する場合記述が冗長になる可能性はある． +またCodeGearからCに帰る場合,環境付き継続を行う必要がある． +Cの関数の末尾でCodeGearを呼び出している場合など環境付き継続を使用しなくても良いケースは存在するが,頻繁にCとCbCを行き来する場合記述が冗長になる可能性はある． \section{今後の課題} 本論文ではCbCによってPerl6の処理系であるMoarVMインタプリタの一部改良とその手法を示した． -CbCのCodeSegment部分を用いることできめ細やかな記述が出来,デバッグし辛い箇所もbreakpointの設定などが容易になった． +CbCのCodeGear部分を用いることできめ細やかな記述が出来,デバッグし辛い箇所もbreakpointの設定などが容易になった． 今後CbCでの開発をより深く行っていくにあたり,CbCコンパイラそのものの信頼性を向上させる必要がある． MoarVMの開発を行うにあたり新たに発見された複数のバグを修正し,より安定するコンパイラにする為に改良を行う． @@ -552,7 +552,7 @@ 今後はさらに複雑な例題やNQPのセルフビルド，Perl6の動作を行っていく． MoarVMではGCからオブジェクトを守る為にMVMROOTというマクロを利用し,局所変数のポインタをスタックに登録する処理を行っている． -GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeSegmentの優位性が損なわれてしまう． +GCの制御を効率的に行えば本来は必要ない処理であり,実行するとCodeGearの優位性が損なわれてしまう． 従ってMoarVMのGCの最適化を行う． また高速化という面では,Perlの特徴である正規表現に着目し,正規表現の表現のみ高速で動く最適化の導入なども検討している． @@ -560,7 +560,7 @@ 高速化することも可能であると推測できる． Perl6の開発は非常に活発に行われている為,CbCMoarVMの最新版の追従も課題となっている． -現在はinterp.cからPerlスクリプトを用いて自動でCbCのCodeSegmentを生成している． +現在はinterp.cからPerlスクリプトを用いて自動でCbCのCodeGearを生成している． 今後の開発領域の拡大と共により効率的にCbCコードへの自動変換も複数のCコードに対応する様に開発を行っていく． %å\subsection{MoarVMの処理流れ}