\chapter{CbCMoarVMの評価}
前章までに、 MoarVMの一部処理をCbCでの書き換えを検討した。
本章では、 CbCMoarVMの評価を行う。

\section{命令処理のモジュール化}
MoarVMの命令コードディスパッチ部分は、 当初はcase文やラベルgotに変換されるため、 1ファイルの記述せざるを得なかった。
書き換えたCodeGearは、 関数の様にCbCから扱う事が可能である。
MoarVMの命j令コードディスパッチでは、 命令に対応する数値を利用して、 case文又は配列から実行するラベルなどを取り出していた。
CbCMoarVMでは、 CodeGearの集合である配列を用意している。
この配列の登録順のみ対応させれば、 CbCMoarVM内の命令に対応するCodeGearの書く場所は問わなくなる。
そのため、 命令処理部分を別ファイルに書き出すなどのモジュール化が可能となった。

モジュール化が可能となったことで、 ディスパッチ部分の処理と実際に実行する命令で関数を分離出来た。
これにより、 ソースコード上の可読性や、 適切なスコープ管理などがオリジナルのMoarVMと比較し可能となった。

\section{CbCMoarVMのデバッグ}j
主要なデバッガであるgdbやlldbでは、 関数には直接break pointを設定する事が可能である。
MoarVMのバイトコードディスパッチ部分はcase文やラベルgotoに変換され、 関数として扱う事が出来ない。
従って、 命令に対応する処理部分でbreak pointを設定を行う場合、 まず処理が書かれているMVM\_interp\_run関数にbreak pointを設置する必要がある。
プロセス起動後、 関数が書かれているinterp.cファイル中の行番号を指定してbreak pointを付けなければならない。
また、ディスパッチでは数値又はラベルを利用している。
この事から、 ソースコード\ref{origi_breakpoint}に示すように、 デバッガ上で直接どの命令を実行するか確認をする事が困難である。

\lstinputlisting[frame=lrbt, label=origi_breakpoint, caption=MoarVMのbreak pointトレース時の表示]{./codes/src/origin_breakpoint.txt}


CodeGearは関数として扱う事ができる為、 break pointとして直接設定する事が可能である。
また、 gdbなどのデバッガは、 実行するべき関数名を表示する事が可能であるため、 CodeGearの名前も表示可能である。
CodeGear名は命令と対応している為、 CodeGear名から命令名を推測する事が可能となった。
実際にデバッガ上の表示を、 ソースコード\ref{cbc_breakpoint}に示す。


\lstinputlisting[frame=lrbt, label=cbc_breakpoint, caption=CbCMoarVMのbreak pointトレース時の表示]{./codes/src/trace_cbc.txt}

\section{パフォーマンス}

なぜか高速化した

\section{Threaded Code}

\section{欠点}

CbCはC言語の下位言語であり、 一種のアセンブラの様な言語である。
通常のC言語では、 関数呼び出しで隠蔽されているデータを意識してCodeGearに接続しなければならない。
その為、 C言語で実装を行うより実装で利用する処理やCodeGearの数が増えてしまう。

今回の実装では、 MoarVMの情報をまとめた構造体のポインタを受け渡す実装で行った。
別の実装法として、構造体のポインタでなく、 構造体そのものを受け渡す実装に変更し、 挙動を確認した。
この構造体のメンバは、 一部メンバの内部で同じメンバを参照している。
ポインタの受け渡しでは同期が出来ているが、 構造体そのものを渡してしまうと同期が出来ない。
その為、 構造体のメンバを、 ソースコード\ref{cbc_sync}に示すように、 都度代入しなおす必要が生じた。
この様にCbCを適応した場合、 データの受け渡しを非常に意識する必要がある。

\lstinputlisting[frame=lrbt, label=cbc_sync, caption=CbCMoarVMのデータ同期]{./codes/sync.c}