--- a/paper/chapter/02-cbc.tex	Mon Feb 15 15:20:40 2021 +0900
+++ b/paper/chapter/02-cbc.tex	Tue Feb 16 14:23:37 2021 +0900
@@ -70,8 +70,10 @@
 CbCを利用したシステムコールのディスパッチ部分をソースコード\ref{src:cbc_syscall_example}に示す。
 この例題では特定のシステムコールの場合、 CbCで実装された処理に\texttt{goto}文をつかって継続する。
 例題ではCodeGearへのアドレスが配列\texttt{cbccodes}に格納されている。
-引数として渡している\texttt{cbc\_ret}は、 システムコールの返り値の数値をレジスタに代入するCodeGearである。
+引数として渡している\texttt{cbc\_ret}は、 システムコールの返り値の数値をレジスタに代入するCodeGearのアドレスである。
 実際に\texttt{cbc\_ret}に継続が行われるのは、 \texttt{read}などのシステムコールの一連の処理の継続が終わったタイミングである。
+この例題はGearsOSにあるStubCodeGearの仕組みを導入していない為、 直接CodeGearのアドレスを利用し継続している。
+GearsOSでは直接CodeGearのアドレスを利用するのはメタ計算のみであり、 ノーマルレベルではアドレスを扱うことはない。
 
 \lstinputlisting[label=src:cbc_syscall_example, caption=CbCを利用したシステムコールのディスパッチ]{src/xv6_syscall.cbc}
 

--- a/paper/chapter/03-gears.tex	Mon Feb 15 15:20:40 2021 +0900
+++ b/paper/chapter/03-gears.tex	Tue Feb 16 14:23:37 2021 +0900
@@ -392,6 +392,10 @@
 
 \lstinputlisting[label=src:cmake1, caption=CMakeList.txt内でのPerlの実行部分]{src/cmakefile.1.txt}
 
+従来のGearsOSではPerlスクリプトを利用した変換時には、厳格なエラーチェックを行っていなかった。
+例えばContextへの値の代入の式が正常に生成できなくても、 Perlスクリプトは正常に動作を終了したことにしてしまう。
+その為従来のGearsOSでのプログラミングの場合は、 変換された後のCbCソースコードをCbCコンパイラがコンパイルした際に初めてエラーが発覚する様に実装されていた。
+
 \section{generate\_stub.pl}
 generate\_stub.plは各CbCファイルごとに呼び出される。
 図\ref{fig:generate_stub_pl_1}にgenerate\_stub.plを使った処理の概要を示す。

--- a/paper/chapter/04-interface.tex	Mon Feb 15 15:20:40 2021 +0900
+++ b/paper/chapter/04-interface.tex	Tue Feb 16 14:23:37 2021 +0900
@@ -54,8 +54,12 @@
 Interfaceはgenerate\_stub.plで読み込まれ、 CodeGearと入出力のDataGearの数え上げが行われる。
 この処理はInterfaceのパースに相当するものである。
 パース対象のInterfaceの構文は、変更前の構文にしか対応していなかった。
-後方互換性を維持したまま、新しい構文に対応させるために、generate\_stub.plが利用するInterfaceの解析ルーチンを両方の構文に対応させた。
+新しい構文に対応させるために、generate\_stub.plが利用するInterfaceの解析ルーチンの書き直しを行っている。
 
+またInterfaceを使って定義されたデータ構造はすでに多数存在していた。
+これらの定義ファイルをすべてこの文法に対応させるのは煩雑である。
+その為、従来の定義ファイルの書式でも対応可能なように後方互換性を維持したまま解析処理を実装した。
+これによって従来のGearsOSの資源をそのまま利用することが可能となっている。
 
 \section{Implementの型定義ファイルの導入}\label{sec:implType}
 Interfaceを使う言語では、 Interfaceが決まるとこれを実装するクラスや型が生まれる。
@@ -127,8 +131,10 @@
 
 これはそもそも、Implの内部で持つ値はDataGearではなく、DataGearに含まれる値であるということを意識出来なかった為である。
 GearsOSはデータの単位はDataGearで行われる。
-Interfaceの呼び出し時に使われる引数はDataGearとして処理されるが、ImplはそもそもImpl全体が1つのDataGearであるため、Stub経由で値をとるのは間違っていたのであった。
+Interfaceの呼び出し時に使われる引数はDataGearとして処理されるが、ImplはそもそもImpl全体が1つのDataGearであるため、Stub経由で値をとるのは間違っていた。
 Implの値をCodeGearの内部で使う場合は、第一引数で与えられる自分自身のDataGearの参照から取り出す必要がある。
+この制約は現在はトランスパイラ・コンパイラ側での調査、エラー処理は行っておらず、GearsOSのプログラミング時のコーディングスタイルのルールのような扱いとなっている。
+
 \section{Interfaceのパーサーの構築}\label{sec:interfaceParser}
 従来のGearsOSのトランスパイラでは、 generate\_stub.plがInterfaceファイルを開き、情報を解析していた。
 この情報解析はgetDataGear関数で行われていた。

--- a/paper/chapter/06-evaluation.tex	Mon Feb 15 15:20:40 2021 +0900
+++ b/paper/chapter/06-evaluation.tex	Tue Feb 16 14:23:37 2021 +0900
@@ -27,6 +27,9 @@
 Interface機能が充実したことにより、これらのエラーがビルド時に明確に解るようになった。
 従来行っていたデバッグもコンパイルエラーが発生するため不必要になり、よりプログラミングすることがやりやすい言語になった。
 また、目的としていたメタレベルとノーマルレベルの分離を、コンパイルエラーという観点でもできるようになったと考える。
+従来の実装との後方互換性も高く保証している。
+GearsOSで現在実装されている例題は、 CMakeListの中に定義されているが、おおよその例題でビルドが通ることが確認された。
+これによって本研究で実装したInterface機能は、従来のInterface機能と干渉せずに、すでに実装された資産を活用することが可能となった。
 
 
 しかし導入したジェネリクス機能については議論の余地がある。

Binary file paper/final.pdf has changed

Binary file paper/master_paper.pdf has changed