--- a/paper/chapter1.tex	Mon Feb 18 20:51:30 2019 +0900
+++ b/paper/chapter1.tex	Mon Feb 18 21:10:04 2019 +0900
@@ -9,12 +9,12 @@
 
 現在開発が進んでいるプログラミング言語にPerl6がある。
 Perl6は設計と実装が分離しており、 現在の主要な実装はRakudoと呼ばれている。
-RakudoはPerl6のサブセットである、NQPと呼ばれる言語を中心に、 記述されている。
+RakudoはPerl6のサブセットである、NQPと呼ばれる言語を中心に 記述されている。
 NQP自体はプロセス仮想機械と呼ばれる、 言語処理系の仮想機械で実行される。
 Rakudoの場合実行する仮想機械は、 Perl6専用の処理系であるMoarVM、 Java環境のJVMが選択可能である。
 
-Rakudoはインタプリタの起動時間及び、 全体的な処理時間が他のスクリプト言語と比較して、 非常に低速である。
-また、 実行環境であるMoarVMの実装事態も複雑であり、 巨大なcase文が利用されているなど、 見通しが悪くなっている。
+Rakudoはインタプリタの起動時間及び、 全体的な処理時間が他のスクリプト言語と比較して非常に低速である。
+また、 実行環境であるMoarVMの実装事態も複雑であり、 巨大なcase文が利用されているなど見通しが悪くなっている。
 
 当研究室で開発しているプログラミング言語に、 Continuation Based C (CbC) がある。
 CbCはCと互換性のある言語であり、 関数より細かな単位である、 CodeGearを用いて記述することが可能となる。

--- a/paper/chapter2.tex	Mon Feb 18 20:51:30 2019 +0900
+++ b/paper/chapter2.tex	Mon Feb 18 21:10:04 2019 +0900
@@ -19,7 +19,7 @@
 
 CbCではC言語の関数の代わりに CodeGear を導入する。
 CodeGearはC言語の関数宣言の型名の代わりに \_\_codeと書く事で宣言出来る。
-\_\_codeはCbCコンパイラでの扱いはvoidと同じ型として扱うが、 CbCプログラミングではCodeGearである事を示す、 識別子として利用する。
+\_\_codeはCbCコンパイラでの扱いはvoidと同じ型として扱うが、 CbCプログラミングではCodeGearである事を示す識別子として利用する。
 
 CodeGearは通常のC言語の関数とは異なり、 返り値を持たない。
 そのためreturn文や返り値の型などの情報が存在しない。
@@ -31,7 +31,7 @@
 CbCの場合、 スタックフレームを操作せずに次のCodeGearに遷移する。
 この際Cの関数呼び出しとは異なり、 プロラムカウンタを操作するのみのjmp命令として処理される。
 通常Schemeのcall/ccなどの継続と呼ばれる処理は、 現在のプログラムまでの位置や情報を、 環境として所持した状態で遷移する。
-CbCの場合これら環境を持たず遷移する為、 通常の継続と比較して軽量であるから、 軽量継続であると言える。
+CbCの場合これら環境を持たず遷移する為、 通常の継続と比較して軽量であるから軽量継続であると言える。
 軽量継続を利用する為、 ループ文を軽量継続の再帰呼び出しなどで実現する事が可能となる。
 
 CodeGear間の入出力の受け渡しは引数を利用して行う。
@@ -61,11 +61,11 @@
 CbCでは関数呼び出しの他に、 for文やwhile文などのループ制御を廃している。
 CbCでループ相当の物を記述する際は、 再帰呼び出しを利用する。
 C言語で、ループを再帰呼び出しで表現する場合、 再帰呼び出しの度にスタックに値が積まれていく為に、 スタック領域を埋め尽くしてしまいスタックオーバーフローが発生する。
-これを回避するには、 末尾再帰と呼ばれる形でのプログラミングが要求される。
-CbCの場合、 CodeGear同士の軽量継続は、 強制的に末尾再帰の形になる。
-また、 CodeGearからCodeGearへの遷移は、 スタックを利用しない。
+これを回避するには末尾再帰と呼ばれる形でのプログラミングが要求される。
+CbCの場合、 CodeGear同士の軽量継続は強制的に末尾再帰の形になる。
+また、 CodeGearからCodeGearへの遷移はスタックを利用しない。
 その為、 CodeGearの再帰呼び出しを利用しても、 スタックオーバーフローを発生させることがない。
-この処理を末尾呼び出し除去(tail call elimination)と呼び、 CbCコンパイラは、 各CodeGearの遷移を末尾再帰に変換する。
+この処理を末尾呼び出し除去(tail call elimination)と呼び、 CbCコンパイラは各CodeGearの遷移を末尾再帰に変換する。
 
 実際にある数の階乗を計算するプログラムをCbC書いた場合のコードをソースコード\ref{cbc_fact}に示す。
 
@@ -85,11 +85,11 @@
 この際は環境付きgotoと呼ばれる手法を取る。
 これは\_CbC\_return及び、 \_CbC\_environmentという変数を使用する。
 この変数は \_CbC\_return が元の環境に戻る際に利用する CodeGear を指し、 \_CbC\_environment は復帰時に戻す元の環境である。
-復帰する場合、 呼び出した位置には帰らず、 呼び出した関数の終了する位置に帰る。
+復帰する場合、 呼び出した位置には帰らず呼び出した関数の終了する位置に帰る。
 実際に環境付き継続を利用した場合のサンプルコードをソースコード\ref{cbc_return_src}に示す。
 
 \lstinputlisting[frame=lrbt, label=cbc_return_src, caption=環境付き継続の例]{./codes/src/return.cbc}
 
 この例では、 通常 c\_funcの返り値が-1である為、 変数testには-1が設定されるかの様に見える。
-しかし関数 c\_func内でCodeGearである cgに軽量継続しており、 cgでは環境付きgotoを利用して、 1を返り値としてCの関数に戻る。
-この場合、 呼び出し元 c\_funcの返り値である -1 の代わりに、 環境付きgotoで渡される1が優先され、 変数testには1が代入される。
+しかし関数 c\_func内でCodeGearである cgに軽量継続しており、 cgでは環境付きgotoを利用して1を返り値としてCの関数に戻る。
+この場合、 呼び出し元 c\_funcの返り値である -1 の代わりに、 環境付きgotoで渡される1が優先され変数testには1が代入される。

--- a/paper/chapter3.tex	Mon Feb 18 20:51:30 2019 +0900
+++ b/paper/chapter3.tex	Mon Feb 18 21:10:04 2019 +0900
@@ -28,7 +28,7 @@
 \section{Rakudo}
 
 RakudoとはNQPによって記述され、 MoarVM、 JVM上で動作するPerl6の実装である。
-NQPとはNotQuitPerlの略であり、 Perl6のサブセットである。
+NQPとはNotQuitPerlの略でありPerl6のサブセットである。
 
 RakudoがPerl6のコンパイラかつインタプリタとして機能する。
 Rakudoの構成を図\ref{fig:perl6nqp}に示す。
@@ -49,7 +49,7 @@
 MoarMVそのものはPerl6やNQPプログラムを直接は評価する事が出来ない。
 従って、 NQP及びPerl6で書かれているRakudoをソースコードからビルドする際は、 予めNQPインタプリタであるnqpをビルドする必要が存在する。
 Rakudoのビルド時にはこのnqpと、 nqpが動作するVMを設定として与える必要がある。
-この両者を指定しない場合、 ビルド時に動的にNQP、 MoarVMをソースコードをダウンロードし、 ビルドを行う。
+この両者を指定しない場合、 ビルド時に動的にNQP、 MoarVMをソースコードをダウンロードしビルドを行う。
 実際にNQPで記述されたRakudoの実装の一部をソースコード\ref{nqp_on_rakud}に示す。
 \lstinputlisting[frame=lrbt, label=nqp_on_rakud, caption=Rakudoの実装の一部]{./codes/src_main.nqp}
 
@@ -65,12 +65,12 @@
 
 MoarVM自体の改良は現在も行われているが、 開発者の多くは新機能の実装などを中心に行っている。
 速度上昇を目指したプロジェクトも存在はするが、 介入する余地があると考えられる。
-また、 内部ではLuaJitというJITコンパイル用のライブラリを利用しているが、 JITに対して開発者チームの力が注がれていない。
+また内部ではLuaJitというJITコンパイル用のライブラリを利用しているが、 JITに対して開発者チームの力が注がれていない。
 その為、 本研究ではJITや速度上昇を最終的な目標として考え、 速度上昇までに必要なモジュール化などの実装を行う。
 
 \section{NQP}
 NQPとはRakudoにおけるPerl6の実装に利用されているプログラミング言語である。
-NQP自体は、 Perl6のサブセットとして開発されている。
+NQP自体はPerl6のサブセットとして開発されている。
 歴史的にはPerl6の主力実装がParrotであった際に開発され、 現在のRakudoに引き継がれている。
 RakudoにおけるNQPは、 Parrot依存であった実装が取り払われている。
 
@@ -90,15 +90,16 @@
 
 
 MoarVMを利用する場合、 MoarVMの実行バイナリであるmoarに対して、 ライブラリパスなどを予め用意したNQPインタプリタのバイトコードに設定する。
-moarの起動時の設定は、 コマンドライン引数のオプションで与える事が可能である。
+moarの起動時の設定はコマンドライン引数のオプションで与える事が可能である。
 その為、 既に存在しているMoarVMバイトコードで記述されたNQPのインプリタファイルを、 適切にオプションで指定し、moarを実行することでNQPのインタプリタが起動する。
 
 
 NQPのビルドフローの一部を図\ref{fig:nqp_stage0_to_1}に示す。
 
-NQPのビルドには、 このNQPインタプリタをまず利用し、 NQP自体のソースコードを入力して与え、 ターゲットとなるVMのバイトコードを生成する。
+NQPのビルドには、 このNQPインタプリタをまず利用し、 NQP自体のソースコードを入力して与る。
+この際に出力として、ターゲットとなるVMのバイトコードを生成する。
 既に用意されている、 ターゲットのVMのバイトコード化しているNQPインタプリタの状態を Stage0 と呼ぶ。
-Stage0を利用し、NQPソースコードからビルドしたNQPインタプリタであるバイトコードを、 Stage1と呼ぶ。
+Stage0を利用しNQPソースコードからビルドしたNQPインタプリタであるバイトコードを、 Stage1と呼ぶ。
 
 \begin{figure}[ht]
 \caption{NQP Stage1のビルドフロー}

--- a/paper/chapter4.tex	Mon Feb 18 20:51:30 2019 +0900
+++ b/paper/chapter4.tex	Mon Feb 18 21:10:04 2019 +0900
@@ -79,12 +79,12 @@
 
 ソースコード\ref{origin_dispatch}中のOP(.*)と書かれている部分が、 それぞれのバイトコードが示す命令名となっている。
 例えばno\_opは、 何もしない命令であるため、 マクロNEXTを利用しプログラムカウンタ相当のcur\_opを進めるのみの処理を行う。
-また、 登場する DISPATCH や OP 、 NEXT などはそれぞれマクロとして定義されている。
+また登場する DISPATCH や OP 、 NEXT などはそれぞれマクロとして定義されている。
 これらMoarVM\_interp\_run中で、 利用されるマクロの定義を、 ソースコード\ref{origin_dispatch_macro}に示す。
 
 \lstinputlisting[frame=lrbt, label=origin_dispatch_macro, caption=オリジナルのMoarVM\_interp\_runで使用されるマクロ]{./codes/src/orig_macro.c}
 
-このマクロの中では、 利用しているCコンパイラがラベルに対してのgotoが利用できる、 コンパイラ拡張を実装している場合は MVM\_CGOTOが真となり、 6行目までが実行される。
+このマクロの中では、 利用しているCコンパイラがラベルに対してのgotoが利用できるコンパイラ拡張を実装している場合は MVM\_CGOTOが真となり、 6行目までが実行される。
 それ以外の場合は8行目以降のマクロ定義となる。
 ラベルgotoが利用できる場合、 マクロDISPATCHは空白として設定され、 マクロOPは、 それぞれの命令に対応したラベルとなる。
 この場合の処理の流れを図\ref{fig:origin_label_goto}に示す。
@@ -150,7 +150,7 @@
 \lstinputlisting[frame=lrbt, label=cbc_next, caption=cbc\_next及びCbCMoarVMでのマクロ例]{./codes/src/cbc-interp-next.cbc}
 
 CodeGear間の軽量継続を中心に設計している為、 switch case文を利用するマクロは削除した。
-また、 各マクロの引数に、 変数iを導入している。 
+また各マクロの引数に変数iを導入している。 
  変数i は、 バイトコードインタプリタ内で利用する、 MoarVMのレジスタ情報などが格納された、 構造体へのポインタである。
 iが示す構造体INTER、 呼び i の型である構造体INTERPは、 ソースコード\ref{cbc_inter}の示すように宣言している。
 これは、マクロ内部で現在の命令を示すopや、 命令列 cur\_op にアクセスする必要があるが、 従来のマクロの記述ではCbCを利用した場合に、変数にアクセス出来なくなる為に導入している。
@@ -167,7 +167,7 @@
 従来はソースコード\ref{origin_dispatch_macro}に示す、 変数opの値利用してをマクロNEXTで対象の命令のラベル、 およびswitch文に値を引き渡す処理をしていた。
 CodeGearでの実装の際も、 このインターフェイスに揃えて実装する。
 変数opの数値は、 ソースコード\ref{labels_list}に示すラベル配列の、 命令の登場順と対応している。
-その為、命令を変換したCodeGearを、 ラベル配列と順序を対応させ、 CodeGearの配列を作成する。
+その為命令を変換したCodeGearをラベル配列と順序を対応させ、 CodeGearの配列を作成する。
 順序さえ対応させれば、 CodeGearの名前などは問わない。
 実際に作成したCodeGearのリストをソースコード\ref{codegear_list}に示す。
 変換したCodeGearは、それぞれCodeGearであることを示す為、 接頭辞としてcbc\_を付けている。
@@ -186,8 +186,8 @@
 
 
 作成したCodeGearのリストCODESは、 ソースコード\ref{cbc_next}に示すとおり、 cbc\_nextというCodeGearのみが取り扱う。
-cbc\_nextは、 マクロNEXTを利用しているが、 マクロNEXTはCODESにアクセスし、 対象となるCodeGearの名前を取得する。
-CodeGearを取得後、 引数としてiを渡し、 goto文によって命令ごとのCodeGearに遷移する。
+cbc\_nextはマクロNEXTを利用しているが、 マクロNEXTはCODESにアクセスし、 対象となるCodeGearの名前を取得する。
+CodeGearを取得後、 引数としてiを渡しgoto文によって命令ごとのCodeGearに遷移する。
 
 命令ディスパッチに関するCodeGearの状態遷移図を図\ref{fig:dispatch_cbc}に示す。
 
@@ -260,7 +260,7 @@
 nqpなどのビルド時には、 入力として与えられたバイトコードを解析し、 命令部分をディスパッチするバイトコードインタプリタを使用せざるを得ない。
 今回はバイトコードディスパッチ部分を書き換えた為、 この部分にバグが生じていると、 そもそもnqpやperl6を生成する事が出来ない。
 その為、 利用したいnqpやperl6のテストコードを出力を通して確認する事が出来ない。
-従って、 今回はMoarVM自体にバイトコードを入力として与え、 期待する動作をするかどうかを独自に確認する必要がある。
+従って今回はMoarVM自体にバイトコードを入力として与え、 期待する動作をするかどうかを独自に確認する必要がある。
 
 
 \section{CbCMoarVMのデバッグ}
@@ -277,11 +277,11 @@
 左行がオリジナルのMoarVMの実行命令であり、 右行がCbCMoarVMの実行命令である。
 出力している命令番号は、 それぞれLABELやCODESなどの命令リストの配列の番号と対応している為、 対応するCodeGear名を同時に出力している。
 $\ast$が先頭に付随する行で差異が発生しており、 それぞれ実行している命令の番号が異なる事が確認出来る。
-この例では、 オリジナルのMoarVMは invoke\_o 命令を実行しているのに対し、 CbCMoarVMでは takeclosure 命令を実行している。
+この例ではオリジナルのMoarVMは invoke\_o 命令を実行しているのに対し、 CbCMoarVMでは takeclosure 命令を実行している。
 
 \section{CbCMoarVMの現在の実装}
 
-CbCMoarVMは現在、 Perl6のサブセットであるNQP、 NQPで書かれたPerl6のビルドに成功している。
+CbCMoarVMは現在Perl6のサブセットであるNQP、 NQPで書かれたPerl6のビルドに成功している。
 各言語のインタプリタであるnqp、 perl6共に、 CbCMoarVMの実行バイナリを利用して動作する。
 
 デバッグ時の利便性などから、 現在はオリジナルのバイトコードインタプリタ部分を実行するか、 CbCで記述されたバイトコードインタプリタを実行するかをオプションを通して選択可能となっている。

Binary file paper/main.pdf has changed