--- a/paper/chapter/03-gears.tex	Thu Feb 04 19:16:52 2021 +0900
+++ b/paper/chapter/03-gears.tex	Thu Feb 04 20:31:27 2021 +0900
@@ -242,6 +242,11 @@
 takeは出力を1つ出すCodeGearである為、継続で渡された\texttt{odgCommitCUDAWorker4}はStubでこの出力を受け取る。
 \lstinputlisting[label=src:queueTake, caption=InterfaceのAPIの呼び出し]{src/queueTake.cbc}
 
+また、Interfaceを利用する場合はソースコード中に\texttt{\#interface "interfaceName.h"}と記述する必要がある。
+例えばQueueを利用する場合は\texttt{\#interface "Queue.h"}と記述しなければならない。
+\texttt{\#interface}構文は、一見するとC言語のマクロの様に見える。
+実際にはマクロではなく、 Perlスクリプトによってメタレベルの情報を含むCbCファイルに変換する際に、 Perlスクリプトに使っているInterfaceを教えるアノテーションの様な役割である。
+Perlスクリプトによって変換時に、 \texttt{\#interface}の宣言は削除される。
 
 \subsection{Interfaceのメタレベルの実装}
 Interface自身もDataGearであり、実際の定義はcontextのunion Data型に記述されている。
@@ -260,6 +265,7 @@
 Queue Interfaceに対応するSingleLinkedQueueの実装を\ref{src:SingleLinkedQueueOld}に示す。
 \lstinputlisting[label=src:SingleLinkedQueueOld, caption=SingleLinkedQueueの実装]{src/SingleLinkedQueueOld.cbc}
 
+Interfaceの実装の場合も、 Interface呼び出しのAPIである\texttt{\#interface "Queue.h"}を記述する必要がある。
 \texttt{createSingleLinkedQueue}はSingleLinkedQueueで実装したQueue Interfaceのコンストラクタである。
 これは関数呼び出しで実装されており、 返り値はInterfaceのポインタである。
 コンストラクタ内ではQueueおよびSingleLinkedQueueのアロケーションを行っている。
@@ -328,8 +334,13 @@
 
 \section{generate\_stub.pl}
 generate\_stub.plは各CbCファイルごとに呼び出される。
-入力としてCbCファイルを受け取りメタ計算を含んだ形に変換し、 純粋なCbCファイルとして書き出す。
-図\ref{fig:generate_stub_pl_1}に処理の概要を示す
+図\ref{fig:generate_stub_pl_1}にgenerate\_stub.plを使った処理の概要を示す。
+ユーザーが記述したGearsOSのCbCファイルは、 ノーマルレベルのコードである。
+generate\_stub.plは、 CbCファイルにメタレベルの情報を付け加え、GearsOSの拡張構文を取り除いた結果のCbCファイルを新たに生成する。
+返還前のGearsOSのファイルの拡張子は.cbcであるが、 generate\_stub.plによって変換されると、 同名で拡張子のみ.cに切り替わったファイルが生成される。
+拡張子は.cであるが、中身はCbCで記述されている。
+generate\_stub.plはあるプログラムのソースコードから別のプログラムのソースコードを生成するトランスコンパイラとして見ることができる。
+
 
 \begin{figure}[h]
   \begin{center}
@@ -339,6 +350,24 @@
   \label{fig:generate_stub_pl_1}
 \end{figure}
 
+generate\_stub.plはGearsOSのソースコードを2回読む。
+1度目の読み込みで、ソースコード中に登場するCodeGearと、CodeGearの入出力を検知する。
+この際に\texttt{\#interface}構文でInterfaceの利用が確認された場合、 Interfaceの定義ファイルを開き、実装されているCodeGearとDataGearの組を取得する。
+
+1度ファイルを完全に読み込み、 CodeGear、DataGearの情報を取得し終わると、以降はその情報をもとに変換したファイルを書き出す。
+ファイルを書き出す際は、 元のCbCファイルを再読み込みし、 変換する必要があるキーワードが出現するまでは、変換後のファイルに転記を行う。
+例えば各CodeGearの最後に実行される\texttt{goto}文は、 GearsOSの場合はMetaCodeGearに継続するように、 対象を切り替える必要がある。
+この為にgenerate\_stub.plは、goto文を検知するとcontext経由で引数のやりとりをするメタ処理を付け加える。
+また、すべてのCodeGearはcontextを入力として受け取る必要があるため、 引数を書き換えてContextを付け加えている。
+
+generate\_stub.plはPerlで書かれたトランスコンパイラであり、 C言語のコンパイラのように文字列を字句解析、構文解析をする訳ではない。
+いくつかあらかじめ定義した正規表現パターンに読み込んでいるCbCファイルの行がパターンマッチされたら、 特定の処理をする様に実装されている。
+
+CodeGearの入力をcontextから取り出すStubCodeGearの生成もgenerate\_stub.plで行う。
+なおすでにStubCodeGearが実装されていた場合は、 generate\_stub.plはStubCodeGearは生成しない。
+
+
+
 \section{generate\_context.pl}
 generate\_context.plは、Contextの初期化関連のファイルを生成するPerlスクリプトである。
 Contextを初期化するためには、下記の処理をしなければならない。

--- a/paper/chapter/05-perl.tex	Thu Feb 04 19:16:52 2021 +0900
+++ b/paper/chapter/05-perl.tex	Thu Feb 04 20:31:27 2021 +0900
@@ -92,7 +92,7 @@
 この手法では手書きでの構築のために自由度は高かったが、 GearsOSの例題によっては使わないDataGearも、 context.hから削除しない限りcontextに含んでしまう問題があった。
 さらにInterfaceファイルで定義した型をcontext.hに転記し、それをもとにImplの型を考えてCbCファイルを作製する必要があった。
 これらをすべてユーザーが行うと、ファイルごとに微妙な差異が発生したりとかなり煩雑な実装を要求されてしまう。
-DataGearの定義はInterfaceファイルを作製した段階で決まり、 使用しているDataGear、CodeGearはコンパイル時に確定するはずである。
+DataGearの定義はInterfaceファイルを作製した段階で決まり、 使用しているDataGear、CodeGearはコンパイル時に確定する。
 使用している各Gearがコンパイル時に確定するならば、 コンパイルの直前に実行されるPerlトランスコンパイラでもGearの確定ができるはずである。
 ここからcontext.hをコンパイルタイミングでPerlスクリプト経由で生成する手法を考案した。
 
@@ -124,6 +124,8 @@
 ノーマルレベル以外のCodeGearで実行する場合は、 通常のコード生成だとStubCodeGearの中で行うことになる。
 StubCodeGearは自動生成されてしまうため、 値の取り出し以外のことを行う場合は自分で実装する必要がある。
 しかしモデル検査に関する処理は様々なCodeGearの後に行う必要があるため、 すべてのCodeGearのStubを静的に実装するのは煩雑である。
+これを避けるには、 Stub以外のMeta Code Gearをユーザーが自由に定義できる必要がある。
+
 
 ノーマルレベルのCodeGearの処理の後に、StubCodeGear以外のMeta Code Gearを実行したい。
 Stub Code Gearに直ちに遷移してしまう\texttt{\_\_code meta}以外のMeta CodeGearに、 特定のCodeGearの計算が終わったら遷移したい。

Binary file paper/master_paper.pdf has changed