--- a/Paper/anatofuz.tex	Mon Nov 19 12:37:45 2018 +0900
+++ b/Paper/anatofuz.tex	Mon Nov 19 13:28:46 2018 +0900
@@ -193,11 +193,11 @@
 このMoarVMByteCodeの状態をStage0と言い, ディレクトリ名として設定されている．
 Perl6の一部はNQPを拡張したもので書かれている為, Rakudoを動作させる為にはMoarVMなどのVM, VMに対応させる様にビルドしたNQPがそれぞれ必要となる．
 現在のNQPではMoarVM, JVMに対応するStage0はそれぞれMoarVMBytecode, jarファイルが用意されており, JavaScriptではバイトコードの代わりにランタイム独自のModuleLoaderなどが設計されている．
-MoarVMのModuleLoaderはStage0にあるMoarVMBytecodeで書かれた一連のファイルが該当する．
+MoarVMのModuleLoaderはStage0にあるMoarVMのバイトコードで書かれた一連のファイルが該当する．
 
 
 Stage0にあるファイルをMoarVMに与えることで, NQPのインタプリタが実行される様になっている．
-これはStage0の一連のファイルは, MoarVMBytecodeなどで記述されたNQPコンパイラのモジュールである為である．
+これはStage0の一連のファイルは, MoarVMのバイトコードなどで記述されたNQPコンパイラのモジュールである為である．
 NQPのインタプリタはセルフビルドが完了すると, nqpというシェルスクリプトとして提供される．
 このシェルスクリプトは, ライブラリパスなどを設定してのバイナリであるmoarを起動するものである．
 %NQPは6modelと呼ばれるオブジェクトモデルを採用としている．%が, これを構築する為に必要なNQPCORE,正規表現系のQRegex,MoarVMのModuleLoaderなどがMoarVMBytecodeで記述されている．これらMoarVMBytecodeの拡張子は.MoarVMである．
@@ -213,7 +213,7 @@
 
 NQPのビルドフローを図\ref{fig:nqpbuild}に示す．
 実際にPerl6の処理系であるperl6を動かすためにはself buildしたNQPコンパイラが必要となる．その為にStage0を利用してStage1をビルドしNQPコンパイラを作成する．
-Stage1は中間的な出力であり, 生成されたNQPファイルはStage2と同一であるが,MoarVMBytecodeが異なる．
+Stage1は中間的な出力であり, 生成されたNQPファイルはStage2と同一であるが,MoarVMのバイトコードが異なる．
 Perl6では完全なセルフコンパイルを実行したNQPが要求される為, Stage1を利用してもう一度ビルドを行いStage2を作成する．
 
 Perl6のテストスイートであるRoast\cite{roast}やドキュメントなどによって設計が定まっているPerl6とは異なりNQP自身の設計は今後も変更になる可能性が開発者から公表されている．
@@ -304,7 +304,7 @@
 従ってMoarVMにおける基本ブロックの箇所をCodeGearに書き換える事が可能である．
 MoarVMにおける基本ブロックはインタプリタが実行するバイトコードごとの処理に該当する．
 
-\subsection{MoarByteCodeのディスパッチ}
+\subsection{MoarVMのバイトコードのディスパッチ}
 MoarVMのバイトコードインタプリタはsrc/core/interp.cで定義されている．
 この中の関数MVM\_interp\_runで命令に応じた処理を実行する．
 関数内では命令列が保存されているcur\_op, 現在と次の命令を指し示すop,Threadの環境が保存されているThreadcontextなどの変数を利用する．
@@ -393,12 +393,12 @@
 
 MoarVM自体のデバッグはMoarVMのリポジトリにテストコードが付随していない為単体では実行不可能である．
 本研究ではMoarVMのデバッグにおけるCデバッガの使用方法とMoarVMのテスト方法についても示す．
-　
-\subsection{MoarVMのBytecodeのデバッグ}
-moarに対してMoarVM bytecodeをdumpオプションを付けて読み込ませるとMoarVMのbytecodeがアセンブラの様に出力される．
-しかしこれはMoarVMが実行したbytecodeのトレースではなくMoarVM bytecodeを変換したものに過ぎない．
-また, 明らかに異なる挙動を示す両者のmoarを利用しても同じ結果が返ってきてしまう．
-そのため今回のMoarVMBytecodeインタプリタの実装のデバッグにはこの方法は適さない．
+
+\subsection{MoarVMのバイトコードのデバッグ}
+MoarVMの実行バイナリであるコマンドmoarに対して, MoarVMのバイトコードをdumpオプションを付けて読み込ませると, MoarVMのバイトコードがアセンブラの様に出力される．
+しかしこれはMoarVMが実行したbytecodeのトレースではなくMoarVMのバイトコードを変換したものに過ぎない．
+また, 明らかに異なる挙動を示すオリジナルのMoarVMと, CbCで書き換えたCbCMoarVM両者のmoarを利用しても同じ結果が返ってきてしまう．
+そのため今回のMoarVMのバイトコードインタプリタの実装のデバッグにはこの方法は適さない．
 従って実際に実行した命令を確認するにはgdbなどのCデバッガを利用してMoarVMを直接トレースする必要がある．
 
 CbC側はCode\ref{cbc_b}に示す様にcbc\_nextにbreak pointを設定する．
@@ -434,8 +434,8 @@
 
 MoarVMは単体で実行する事が不可能である．
 またNQPのリポジトリに付随するテストはnqpで書かれている為, NQPをビルド出来ない場合MoarVMのテストを行う事が出来ない．
-その為, 正常に動作しているMoarVMとNQPを用意し, このNQP側からMoarVMByteCodeにNQPのテストを変換する．
-変換されたMoarVMByteCodeはMoarバイナリに渡す事で実行可能であり, テストを行う事が出来る．
+その為, 正常に動作しているMoarVMとNQPを用意し, このNQP側からMoarVMのバイトコードにNQPのテストを変換する．
+変換されたMoarVMのバイトコードはMoarバイナリに渡す事で実行可能であり, テストを行う事が出来る．
 
 \subsection{CbCコンパイラによるバグ}
 これまでのCbCに関する研究においては, 複数個の入出力をCodeGearに与えるユースケースで利用していた．
@@ -484,7 +484,7 @@
 CbCMoarVMの場合, CodeGear単位でバイトコードの処理単位を記述している為,通常の関数と同じく直接CodeGearにデバッグポイントをかける事が可能である．
 これはCプログラミングの関数に対してのデバッグで, 状態ごとにbreak pointをかける事が出来ることを意味する．
 通常のC言語で言語処理系を実装した場合と比較して扱いやすくなっていると言える．
-さらにラベルテーブルでの管理場合, 次のバイトコード箇所は数値でしか確認できず,実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった．
+さらにラベルテーブルでの管理の場合, 次のバイトコード箇所は数値でしか確認できず,実際にどこに飛ぶのかはラベルテーブル内と数値を作業者が手作業で確認する必要があった．
 スクリプトなどを組めば効率化は出来るがデバッガ上で完結しない為手間がかかる．
 CbC実装ではCODESテーブル内は次のCodeGearの名前が入っている為, 数値からCodeGearの名前をデバッガ上で確認する事が出来る
 ．