Mercurial > hg > Papers > 2021 > anatofuz-master
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組み込み}
--- /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); +