--- a/paper/anatofuz-sigos.tex	Mon May 04 18:39:32 2020 +0900
+++ b/paper/anatofuz-sigos.tex	Mon May 04 18:41:35 2020 +0900
@@ -119,11 +119,22 @@
 
 CbCでは関数の代わりにCodeGearという単位でプログラミングを行う。
 CodeGearは通常のCの関数宣言の返り値の型の代わりに\texttt{\_\_code}で宣言を行う。
+各CodeGearはDataGearと呼ばれるデータの単位で入力を受け取り、 その結果を別のDataGearに書き込む。
+入力のDataGearをInputDataGearと呼び、 出力のDataGearをOutputDataGearと呼ぶ。
+CodeGearがアクセスできるDataGearは、 InputDataGearとOutputDataGearに限定される。
+これらの関係図を図\ref{fig:cgdg}に示す。
+
+\begin{figure}[tb]
+    \begin{center}
+        \includegraphics[width=70mm]{fig/cgdg.pdf}
+    \end{center}
+    \caption{CodeGearと入出力の関係図}
+    \label{fig:cgdg}
+\end{figure}
 
 CbCで階乗を求める例題をCode \ref{src:cbc_example}に示す。
 例題ではCodeGearとして\texttt{factorial}を宣言している。
 \texttt{factorial}はCodeGearの引数として\texttt{struct F}型の変数\texttt{arg}を受け取り、\texttt{arg}のメンバー変数によって\texttt{factorial}の再帰呼び出しを行う。
-\texttt{arg}の様なCodeGearの引数のことを\texttt{DataGear}と呼ぶ。
 CodeGearの呼び出しは\texttt{goto}文によって行われる。
 この例題を状態遷移図にしたものを図\ref{fig:factorial_cbc}に示す。
 図中の四角がDataGear、 円がCodeGearに対応する。
@@ -171,6 +182,7 @@
 GearsOSでは、 CodeGearとDataGearを元にプログラミングを行う。
 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。
 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。
+また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。
 MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、　現在はPerlスクリプトによってGearsOSのビルド時に生成される。
 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。
 
@@ -182,14 +194,23 @@
     \label{meta-cg-dg}
 \end{figure}
 
-ノーマルレベルのプログラミングでは、 図\ref{meta-cg-dg}の上段に示す様に入力のDataGearを受け取りCodeGearを実行、　結果をDataGearに書き込んだ上で別のCodeGearに継続する様に見える。
+通常のコード中では図\ref{meta-cg-dg}の上段に示す様に入力のDataGearを受け取りCodeGearを実行、 結果をDataGearに書き込んだ上で別のCodeGearに継続する様に見える。
 しかし実際はCodeGearの実行の前後に実行されるMetaCodeGearや入出力のDataGearを保存場所から取り出すMetaDataGearなどのメタ計算が加わる。
 
 遷移先のCodeGearとMetaCodeGearの紐付けや、 計算に必要なDataGearを保存や管理を行うMetaDataGearとしてcontextがある。
+cotnextと各データ構造の関わりを図\ref{fig:context_ref}に示す。
 contextは処理に必要なCodeGearの番号とMetaCodeGearの対応表や、 DataGearの格納場所を持つ。
+計算に必要なデータ構造と処理を持つデータ構造であることから、 contextは従来のOSのプロセスに相当するものと言える。
 コード上では別のCodeGearに直接遷移している様に見えるが、 実際はcontext内の遷移先のCodeGearに対応するスロットから、対応するMetaCodeGearに遷移する。
 MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、　実際の計算が行われる。
-contextは計算に必要なデータ構造と処理を持つデータ構造であることから、 従来のOSのプロセスに相当するものと言える。
+
+\begin{figure}[tb]
+    \begin{center}
+        \includegraphics[width=70mm]{fig/Context_ref.pdf}
+    \end{center}
+    \caption{Contextと各データの関係図}
+    \label{fig:context_ref}
+\end{figure}
 
 \section{xv6 kernel}
 
@@ -215,6 +236,37 @@
 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することで状態遷移系への変換を行った。
 
 
+\section{CbCを用いたxv6の書き換え方針}
+
+CbCではCodeGear、 DataGearからなる単位を基本とし、 それぞれにメタなGearが付随する。
+また実行に必要なCodeGearとDataGearをまとめたcontextというMetaDataGearが存在する。
+この機能を元にxv6の書き換えを検討した。
+
+xv6内でCbCの軽量継続に突入する際は、 元の処理関数に通常の方法では戻ってくることができず、部分的に書き換えていくのが困難である。
+今回は呼び出し関数に戻れるスタックフレームを操作したい為に、 ダミーの\texttt{void}関数を用意した。
+この関数内でCodeGearに\texttt{goto}文を用いて遷移することで、 CbCから帯域脱出した際に\texttt{void}関数の呼び出し元から処理を継続し、部分的にCbCに書き換えることが可能となった。
+Code\ref{src:dumy_function_cbc}では、 \texttt{userinit}関数へ戻るために、 \texttt{cbc\_init\_vmm\_dumy}を経由している。
+
+\begin{lstlisting}[frame=lrbt,label=src:dumy_function_cbc,caption={部分的にCbCを適応する例}]
+void cbc_init_vmm_dummy(struct Context* cbc_context, struct proc* p, pde_t* pgdir, char* init, uint sz)
+{
+    struct vm* vm = createvm_impl(cbc_context);
+    goto vm->init_vmm(vm, pgdir, init, sz , vm->void_ret);
+}
+
+void userinit(void)
+{
+// omission
+
+    if((p->pgdir = kpt_alloc()) == NULL) {
+        panic("userinit: out of memory?");
+    }
+
+    cbc_init_vmm_dummy(&p->cbc_context, p, p->pgdir, _binary_initcode_start, (int)_binary_initcode_size);
+
+    p->sz = PTE_SZ;
+    memset(p->tf, 0, sizeof(*p->tf));
+\end{lstlisting}
 
 \nocite{*}
 \bibliographystyle{ipsjunsrt}

Binary file paper/fig/Context_ref.pdf has changed

Binary file paper/fig/cgdg.pdf has changed