changeset 36:a039a55d97ae

..
author anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp>
date Tue, 05 May 2020 17:08:08 +0900
parents c2ba9cdb4916
children 9e40a7a00a02
files paper/anatofuz-sigos.md paper/anatofuz-sigos.pdf paper/anatofuz-sigos.tex
diffstat 3 files changed, 16 insertions(+), 18 deletions(-) [+]
line wrap: on
line diff
--- a/paper/anatofuz-sigos.md	Tue May 05 16:17:38 2020 +0900
+++ b/paper/anatofuz-sigos.md	Tue May 05 17:08:08 2020 +0900
@@ -95,7 +95,7 @@
 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。
 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。
 また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。
-MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。
+MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。
 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。
 
 ![lab:meta-cg-dg, cap:CodeGearとMetaCodeGear](./fig/meta-cg-dg.pdf)
@@ -112,7 +112,7 @@
 ![lab:fig:context_ref, cap:Contextと各データの関係図](fig/Context_ref.pdf)
 
 コード上では別のCodeGearに直接遷移している様に見えるが、 実際はcontext内の遷移先のCodeGearに対応するスロットから、対応するMetaCodeGearに遷移する。
-MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。
+MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。
 
 
 # xv6 kernel
@@ -128,7 +128,7 @@
 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。
 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。
 
-本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。
+本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。
 
 
 # xv6のシステムコールの継続の分析
@@ -162,8 +162,8 @@
 システムコールの一連の流れに着目するのではなく、 特定の対象のAPIに着目して継続の分析を検討した。
 
 xv6のファイルシステムに関する定義ファイルは`fs.c`中に記述されている。
-Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。
-`__code`から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合への名前となる。
+Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。
+`__code`から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合の最初の継続となる。
 
 
 ``` lab:src:fs_interface, cap:ファイルシステム操作のAPIの一部
@@ -180,10 +180,9 @@
 } fs;
 ```
 
+Code\ref{src:fs_interface}内の `readsb`などは`fs.c`内で定義されているCの関数名と対応している。
+このCの関数を更に継続ごとに分割するために、 関数内のif文などの分岐を持たない基本単位であるBasic Blockに着目した。
 
-# Basic Blockに基づく分析
-
-まず関数内でif文などの分岐を持たない基本単位であるBasic Blockに着目した。
 CbCのCodeGearの粒度はCの関数とアセンブラの中間であるといえるので、 BasicBlockをCodeGearに置き換える事が可能である。
 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することが可能となる。
 
@@ -227,4 +226,4 @@
 グローバル変数を使用してしまうと、 CodeGearで定義した状態がDataGear以外のグローバル変数によって変更されてしまう。
 グローバル変数を極力使わず継続を中心とした実装を行いたい。
 
-contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。
+contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。
Binary file paper/anatofuz-sigos.pdf has changed
--- a/paper/anatofuz-sigos.tex	Tue May 05 16:17:38 2020 +0900
+++ b/paper/anatofuz-sigos.tex	Tue May 05 17:08:08 2020 +0900
@@ -183,7 +183,7 @@
 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。
 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。
 また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。
-MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。
+MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。
 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。
 
 \begin{figure}[tb]
@@ -212,7 +212,7 @@
 \end{figure}
 
 コード上では別のCodeGearに直接遷移している様に見えるが、 実際はcontext内の遷移先のCodeGearに対応するスロットから、対応するMetaCodeGearに遷移する。
-MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。
+MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。
 
 
 \section{xv6 kernel}
@@ -228,7 +228,7 @@
 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。
 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。
 
-本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。
+本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。
 
 
 \section{xv6のシステムコールの継続の分析}
@@ -268,8 +268,8 @@
 システムコールの一連の流れに着目するのではなく、 特定の対象のAPIに着目して継続の分析を検討した。
 
 xv6のファイルシステムに関する定義ファイルは`fs.c`中に記述されている。
-Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。
-\texttt{\_\_code}から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合への名前となる。
+Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。
+\texttt{\_\_code}から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合の最初の継続となる。
 
 
 \begin{lstlisting}[frame=lrbt,label=src:fs_interface,caption={ファイルシステム操作のAPIの一部}]
@@ -286,10 +286,9 @@
 } fs;
 \end{lstlisting}
 
+Code\ref{src:fs_interface}内の \texttt{readsb}などは`fs.c`内で定義されているCの関数名と対応している。
+このCの関数を更に継続ごとに分割するために、 関数内のif文などの分岐を持たない基本単位であるBasic Blockに着目した。
 
-\section{Basic Blockに基づく分析}
-
-まず関数内でif文などの分岐を持たない基本単位であるBasic Blockに着目した。
 CbCのCodeGearの粒度はCの関数とアセンブラの中間であるといえるので、 BasicBlockをCodeGearに置き換える事が可能である。
 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することが可能となる。
 
@@ -333,7 +332,7 @@
 グローバル変数を使用してしまうと、 CodeGearで定義した状態がDataGear以外のグローバル変数によって変更されてしまう。
 グローバル変数を極力使わず継続を中心とした実装を行いたい。
 
-contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。
+contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。
 
 \nocite{*}
 \bibliographystyle{ipsjunsrt}