changeset 101:cb7fc7356561

update
author anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp>
date Sat, 06 Feb 2021 09:52:09 +0900
parents 39001ece437e
children 9f5c21b218af
files paper/chapter/03-gears.tex paper/chapter/05-perl.tex paper/chapter/conclusion.tex paper/master_paper.pdf paper/src/mcMeta.cbc paper/src/stackStackcbc.cbc
diffstat 6 files changed, 44 insertions(+), 5 deletions(-) [+]
line wrap: on
line diff
--- a/paper/chapter/03-gears.tex	Sat Feb 06 09:26:14 2021 +0900
+++ b/paper/chapter/03-gears.tex	Sat Feb 06 09:52:09 2021 +0900
@@ -292,7 +292,8 @@
 
 \subsection{Stack.Stack-{\textgreater}Stack.stack}
 Contextのデータ保管場所について確認する。
-ここではソースコード\ref{}を実行する際に、 Contextが持つ引数保管場所がどのような値になるかを見る。
+ここではソースコード\ref{src:StackStackCbC}を実行する際に、 Contextが持つ引数保管場所がどのような値になるかを見る。
+\lstinputlisting[label=src:StackStackCbC, caption=Contextの引数格納用の場所の確認の例題]{src/stackStackcbc.cbc}
 
 ソースコード\ref{src:StackStack1}の1行目で作製したStackTest Interfaceのアドレスは、 3行目の出力である\texttt{0x7fff2f806b50}である。
 Interfaceが持つ実装へのポインタは、 5行目の先頭のstackTestに代入されている値である\texttt{0x7fff2f806bb8}となっている。
@@ -314,7 +315,7 @@
 \lstinputlisting[label=src:StackStack4, caption=contextのdata配列からInterfaceを取り出す]{src/stackStack4.sh}
 この状況を纏めると、図\ref{fig:stackstackstackstack}のようになる。
 Contextの引数格納用の場所は、最初はその型のInterfaceへのポインタが、Interfaceが通常実装へのポインタを指すフィールドに書き込まれる。
-これはGearsOSではStack.stack-{\textgreater}Stack.stack記法と言われている。
+これはGearsOSではStack.stack-{\textgreater}Stack.stack問題と言われている。
 
 
 \begin{figure}[ht]
--- a/paper/chapter/05-perl.tex	Sat Feb 06 09:26:14 2021 +0900
+++ b/paper/chapter/05-perl.tex	Sat Feb 06 09:52:09 2021 +0900
@@ -146,6 +146,7 @@
 各モジュールに共通のAPIを記述しており、 テンプレートに限らず共通して呼び出すことが可能である。
 
 
+
 \section{meta.pmによるメタ計算部分の入れ替え}
 GearsOSでは次のCodeGearに移行する前のMetaCodeGearとして、 デフォルトでは\texttt{\_\_code meta}が使われている。
 \texttt{\_\_code meta}はcontextに含まれているCodeGearの関数ポインタを、 enumからディスパッチして次のStub CodeGearに継続するものである。
@@ -155,9 +156,23 @@
 ノーマルレベル以外のCodeGearで実行する場合は、 通常のコード生成だとStubCodeGearの中で行うことになる。
 StubCodeGearは自動生成されてしまうため、 値の取り出し以外のことを行う場合は自分で実装する必要がある。
 しかしモデル検査に関する処理は様々なCodeGearの後に行う必要があるため、 すべてのCodeGearのStubを静的に実装するのは煩雑である。
-これを避けるには、 Stub以外のMeta Code Gearをユーザーが自由に定義できる必要がある。
+これを避けるには、 Stub以外のMeta Code Gearをユーザーが自由に定義でき、任意にそのMetaCodeGearに継続できる必要がある。
+従来のGearsOSでは、継続先のMetaCodeGearは\texttt{\_\_code meta}に決め打ちとなっているために、 自在に変更するAPIが必要となる。
+
+\subsection{\_\_ncodeによる自由なMetaCodeGearの定義}
+
+ユーザーが自由にMetaCodeGearを定義できるAPIとして\texttt{\_\_ ncode}を定義した。
+これはCbCのマクロで\texttt{\_\_code}になるように制御されている。
+
+generate\_stub.pl、generate\_context.plの両方のPerlトランスパイラは、 \texttt{\_\_code}で定義されているCodeGerはノーマルレベルのCodeGearだと解釈する。
+ノーマルレベルのCodeGearはStubの生成や、メタレベルの情報を含んだものに変換される。
+対して\texttt{\_\_ncode}は、MetaCodeGearであると判断されるので、これらの変換が行われない。
+ユーザーはメタレベルの計算をすべて実装する必要はあるものの、\texttt{\_\_ncode}を使うと自由にMetaCodeGearを定義できる。
+ソースコード\ref{src:mcMeta}は\texttt{\_\_ncode}によって定義した、 モデル検査用のMetaCodeGearである。
+\lstinputlisting[label=src:mcMeta, caption=\_\_ncodeによって定義されたMetaCodeGear]{src/mcMeta.cbc}
 
 
+\subsection{meta.pm}
 ノーマルレベルのCodeGearの処理の後に、StubCodeGear以外のMeta Code Gearを実行したい。
 Stub Code Gearに直ちに遷移してしまう\texttt{\_\_code meta}以外のMeta CodeGearに、 特定のCodeGearの計算が終わったら遷移したい。
 このためには、特定のCodeGearの遷移先のMetaCodeGearをユーザーが定義できるAPIが必要となる。
@@ -194,12 +209,13 @@
 変換するCodeGearがルールになかった場合は、 デフォルト設定が呼び出される。
 ソースコード\ref{src:noreplaceMeta}に、meta.pmの設定を書かなかった場合の変換結果を示す。
 ソースコード\ref{src:replaceMcMeta}では、meta.pmの設定を置いた場合の変換結果である。
-継続先がmetaからmcMetaに切り替わっていることが解る。
+継続先がmetaからモデル検査用のMetaCodeGearであるmcMetaに切り替わっていることが解る。
 
 \lstinputlisting[label=src:noreplaceMeta, caption=通常のthinkingPhilsImplのメタレベルのコード]{src/nonreplaceMcMeta.cbc}
 \lstinputlisting[label=src:replaceMcMeta, caption=meta.pmによってmcMetaへと継続が切り替わったthinkingPhilsImpl]{src/replaceMcMeta.cbc}
 
 
+
 \section{コンパイルタイムでのコンストラクタの自動生成}
 
 
--- a/paper/chapter/conclusion.tex	Sat Feb 06 09:26:14 2021 +0900
+++ b/paper/chapter/conclusion.tex	Sat Feb 06 09:52:09 2021 +0900
@@ -10,10 +10,13 @@
 ポインタではなく値そのものを使う場合、 C言語では使用する型の定義は、使う前に書かなければならない。
 そのため本来はソースコード\ref{src:unionOrder2}の様に定義する必要がある。
 \lstinputlisting[label=src:unionOrder2, caption=構造体の定義順を考慮したunionの定義]{src/unionOrder2.cc}
-現在のGearsOSではDataGearの構造体の相互参照は基本はポインタで行われている。
+GearsOSではDataGearの構造体の相互参照は基本はポインタで行われている。
 その為コンパイル時に致命的なエラーは存在していないが、 実装の手法によってはDataGearそのものを内包したいケースがある。
 この場合はcontext.hで定義する構造体の依存関係を調査し、適切に出力する必要がある。
 
+現在はcontext.hがすでに存在していた場合context.hの再生成は行わないようになっているため、 context.hを手で修正すればエラーは回避可能である。
+しかし結局手動で行ってしまっているために、 generate\_context.plで依存関係の解決を自動的に行う必要がある。
+
 \subsection{xv6上での完全な動作}
 
 \subsection{Perlトランスパイラが提供する機能のGearsOS組み込み}
Binary file paper/master_paper.pdf has changed
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/src/mcMeta.cbc	Sat Feb 06 09:52:09 2021 +0900
@@ -0,0 +1,12 @@
+__ncode mcMeta(struct Context* context, enum Code next) {
+    context->next = next; // remember next Code Gear
+    struct MCWorker* mcWorker =  (struct MCWorker*) context->worker->worker;
+    StateNode st ;
+    StateDB out = &st;
+    struct Element* list = NULL;
+    struct MCTaskManagerImpl* mcti = (struct MCTaskManagerImpl *)mcWorker->taskManager->taskManager;
+    out->memory = mcti->mem;
+    out->hash = get_memory_hash(mcti->mem,0);
+...
+    goto meta(context, context->next);
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/src/stackStackcbc.cbc	Sat Feb 06 09:52:09 2021 +0900
@@ -0,0 +1,7 @@
+Stack* stack = createSingleLinkedStack(context);
+StackTest* stackTest = createStackTestImpl3(context);
+Gearef(context, StackTest)->stackTest = (union Data*) stackTest;
+Gearef(context, StackTest)->stack = stack;
+Gearef(context, StackTest)->next = C_shutdown;
+goto meta(context, stackTest->insertTest1);
+