--- a/paper/chapter/04-interface.tex	Mon Feb 01 17:16:24 2021 +0900
+++ b/paper/chapter/04-interface.tex	Mon Feb 01 17:58:24 2021 +0900
@@ -38,6 +38,36 @@
 privateCodeGearにgotoする場合、 goto元のCodeGearからは\texttt{goto meta}経由で遷移する。
 goto metaが発行されるとStub Code Gearに遷移するが、現在のシステムではInterfaceから値をとってくることになってしまう。
 
+\section{context.hの自動生成}
+GearsOSのContextの定義はcontext.hにある。
+ContextはGearsOSの計算で使用されるすべてのCodeGear、 DataGearの情報を持っている。
+context.hではDataGearに対応する\texttt{union Data}型の定義も行っている。
+Data型はCの共用体であり、 Dataを構成する要素として各DataGearがある。
+各DataGearは構造体の形で表現されている。
+各DataGear自体の定義もcontext.hのunion Dataの定義の中で行われている。
+
+DataGearの定義はInterfaceファイルで行っていた。
+InterfaceファイルはGearsOS用に拡張されたシンタックスのヘッダファイルを使っており、 直接CbCからロードすることができない。
+その為従来はプログラマが静的にInterfaceファイルをCbCの文脈に変換し、 context.hに構造体に変換したものを書いていた。
+この手法では手書きでの構築のために自由度は高かったが、 GearsOSの例題によっては使わないDataGearも、 context.hから削除しない限りcontextに含んでしまう問題があった。
+さらにInterfaceファイルで定義した型をcontext.hに転記し、それをもとにImplの型を考えてCbCファイルを作製する必要があった。
+これらをすべてユーザーが行うと、ファイルごとに微妙な差異が発生したりとかなり煩雑な実装を要求されてしまう。
+DataGearの定義はInterfaceファイルを作製した段階で決まり、 使用しているDataGear、CodeGearはコンパイル時に確定するはずである。
+使用している各Gearがコンパイル時に確定するならば、 コンパイルの直前に実行されるPerlトランスコンパイラでもGearの確定ができるはずである。
+ここからcontext.hをコンパイルタイミングでPerlスクリプト経由で生成する手法を考案した。
+
+\subsection{context.hの作製フロー}
+GearsCbCからメタ計算を含むCbCファイルに変換するgenerate\_stub.plは各CbCファイルを1つ1つ呼び出していた。
+context.hを生成しようとする場合、 プロジェクトで利用する全CbCファイルを扱う必要がある。
+
+Contextの初期化ルーチンを作製するgenerate\_context.plは、その特性上すべてのCbCファイルをロードしていた。
+したがってcontext.hを作製する場合はこのスクリプトで行うのが良い。
+
+Perlのモジュールとして\texttt{Gears::Template::Context}を作製した。
+xv6プロジェクトの場合は一部ヘッダファイルに含める情報が異なる。
+
+派生モジュールとして\texttt{Gears::Template::Context::XV6}も実装している。
+これらのテンプレートモジュールはgenerate\_context.plの実行時のオプションで選択可能とした
 
 \section{メタ計算部分の入れ替え}
 GearsOSでは次のCodeGearに移行する前のMetaCodeGearとして、 デフォルトでは\texttt{\_\_code meta}が使われている。
@@ -156,9 +186,13 @@
   \end{itemize}
 \end{itemize}
 
+
 \texttt{generate\_stub.pl}内では変換対象のCbCのソースコードを2度読み込む。
 最初の読み込み時に継続の状況を確認し、 2度目の読み込み時に状況を踏まえてコードを生成すれば良い。
 初回の読み込み時にInterface経由の\texttt{goto}文があった場合に、別Interfaceからの出力があるかなどの情報を確認したい。
+
+\subsection{初回CbCファイル読み込み時の処理}
+
 Interface経由でのgoto文は\texttt{goto interface->method()}の形式で呼び出される。
 ソースコード\ref{src:parsedOutputStub.pl}はこの形式で来ていた行を読み込んだタイミングで実行される処理である。
 \lstinputlisting[label=src:parsedOutputStub.pl, caption=goto時に使用するinterfaceの解析]{src/parsedOutputStub.pl}
@@ -186,9 +220,11 @@
 現在のCodeGearの名前を保存しているのは、この後のコード生成部分でenumの番号を切り替える必要があるためである。
 ソースコード\ref{src:insertTest1}の例では\texttt{pop2Test}が使うenumを書き換える必要がある為、 ここの\texttt{\$currentCodeGear}はpop2Testとなる。
 ここで作製した\texttt{\$outputStubElem}は、返還後のCbCコードを生成しているフェーズで呼びされる。
+
+\subsection{enumの差し替え処理}
+
 ソースコード\ref{src:generatePickNext.pl}の箇所は遷移先のenumをPerlスクリプトで生成し、 GearsOSが実行中にenumをcontextに書き込むコードを生成するフェーズである。
 \lstinputlisting[label=src:generatePickNext.pl, caption=Gearefのコード生成部分]{src/generatePickNext.pl}
 if文で条件判定をしているが、前者は出力があるケースかどうかのチェックである。
 続く条件式はGearsOSのビルドルールとして静的に書いたstubの場合は変更を加えない為に、 静的に書いているかどうかの確認をしている。
-
 変数\texttt{\$pick\_next}で継続先のCodeGearの名前を作製している。

Binary file paper/master_paper.pdf has changed