--- a/paper/anatofuz-sigos.md	Mon May 04 16:19:35 2020 +0900
+++ b/paper/anatofuz-sigos.md	Mon May 04 18:39:32 2020 +0900
@@ -43,11 +43,16 @@
 
 CbCでは関数の代わりにCodeGearという単位でプログラミングを行う。
 CodeGearは通常のCの関数宣言の返り値の型の代わりに`__code`で宣言を行う。
+各CodeGearはDataGearと呼ばれるデータの単位で入力を受け取り、 その結果を別のDataGearに書き込む。
+入力のDataGearをInputDataGearと呼び、 出力のDataGearをOutputDataGearと呼ぶ。
+CodeGearがアクセスできるDataGearは、 InputDataGearとOutputDataGearに限定される。
+これらの関係図を図\ref{fig:cgdg}に示す。
+
+![lab:fig:cgdg, cap:CodeGearと入出力の関係図](fig/cgdg.pdf)
 
 CbCで階乗を求める例題をCode \ref{src:cbc_example}に示す。
 例題ではCodeGearとして`factorial`を宣言している。
 `factorial`はCodeGearの引数として`struct F`型の変数`arg`を受け取り、`arg`のメンバー変数によって`factorial`の再帰呼び出しを行う。
-`arg`の様なCodeGearの引数のことを`DataGear`と呼ぶ。
 CodeGearの呼び出しは`goto`文によって行われる。
 この例題を状態遷移図にしたものを図\ref{fig:factorial_cbc}に示す。
 図中の四角がDataGear、 円がCodeGearに対応する。
@@ -89,19 +94,23 @@
 GearsOSでは、 CodeGearとDataGearを元にプログラミングを行う。
 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。
 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。
+また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。
 MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、　現在はPerlスクリプトによってGearsOSのビルド時に生成される。
 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。
 
 ![lab:meta-cg-dg, cap:CodeGearとMetaCodeGear](./fig/meta-cg-dg.pdf)
 
-ノーマルレベルのプログラミングでは、 図\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のプロセスに相当するものと言える。
+
+![lab:fig:context_ref, cap:Contextと各データの関係図](fig/Context_ref.pdf)
 
 # xv6 kernel
 
@@ -127,3 +136,34 @@
 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することで状態遷移系への変換を行った。
 
 
+# CbCを用いたxv6の書き換え方針
+
+CbCではCodeGear、 DataGearからなる単位を基本とし、 それぞれにメタなGearが付随する。
+また実行に必要なCodeGearとDataGearをまとめたcontextというMetaDataGearが存在する。
+この機能を元にxv6の書き換えを検討した。
+
+xv6内でCbCの軽量継続に突入する際は、 元の処理関数に通常の方法では戻ってくることができず、部分的に書き換えていくのが困難である。
+今回は呼び出し関数に戻れるスタックフレームを操作したい為に、 ダミーの`void`関数を用意した。
+この関数内でCodeGearに`goto`文を用いて遷移することで、 CbCから帯域脱出した際に`void`関数の呼び出し元から処理を継続し、部分的にCbCに書き換えることが可能となった。
+Code\ref{src:dumy_function_cbc}では、 `userinit`関数へ戻るために、 `cbc_init_vmm_dumy`を経由している。
+
+``` lab:src:dumy_function_cbc, cap:部分的に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));
+```
\ No newline at end of file

Binary file paper/anatofuz-sigos.pdf has changed