Mercurial > hg > Papers > 2021 > anatofuz-master
changeset 70:26c9cd7b9b21
update
| author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
|---|---|
| date | Thu, 04 Feb 2021 11:43:18 +0900 |
| parents | 9950430ccc47 |
| children | d2aa3709bfc8 |
| files | paper/chapter/03-gears.tex paper/chapter/06-evaluation.tex paper/drawio/context.drawio paper/drawio/context.pdf paper/master_paper.pdf paper/src/GearsMacroCMake.txt |
| diffstat | 6 files changed, 100 insertions(+), 46 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/chapter/03-gears.tex Wed Feb 03 21:29:14 2021 +0900 +++ b/paper/chapter/03-gears.tex Thu Feb 04 11:43:18 2021 +0900 @@ -17,8 +17,15 @@ \section{GearsOSの構成} GearsOSは様々な役割を持つCodeGearとDataGearで構成されている。 -特にOSであるために並行処理用の機構などが搭載されている。 GearsOSの構成図を図\ref{fig:gearsstruct}に示す。 +中心となるMetaDataGearは以下の要素である。 + +\begin{itemize} + \item Context + \item TaskManager + \item TaskQueue + \item Worker +\end{itemize} \begin{figure}[h] \begin{center} @@ -31,52 +38,19 @@ \section{Context} Contextとは従来のOSのプロセスに相当する概念である。 GearsOSでのデータの単位から見ると、 MetaDataGearに相当する。 -その為ノーマルレベルのCodeGearからはcontextは直接参照しない。 -contextの操作をしてしまうと、メタレベルとノーマルレベルの分離をした意味がなくなってしまう為である。 +Contextの概要図を図\ref{fig:context}に示す。 -ContextはGearsOSの計算で使用されるすべてのDataGearとCodeGearを持つ。 -GearsOSではCodeGearの入力は、 メタレベルから見るとContextのみである。 -実際にCodeGearを実行する際は、Contextから計算に必要なDataGearを取得する必要がある。 -これはStubCodeGearと呼ばれるMetaCodeGearが実行する。 - +ContextはMetaDataGearである為に、 ノーマルレベルのCodeGearからはcontextは直接参照しない。 +contextの操作をしてしまうと、メタレベルとノーマルレベルの分離をした意味がなくなってしまう為である。 \begin{figure}[h] \begin{center} - \includegraphics[width=160mm]{drawio/stubCodeGear.pdf} + \includegraphics[width=120mm]{drawio/context.pdf} \end{center} - \caption{Contextを参照したCodeGearのデータアクセス} - \label{fig:stubCodeGear} + \caption{Contextの概要図} + \label{fig:context} \end{figure} -次のCodeGearに継続する際、ノーマルレベルから見ると次のCodeGearを直接指定しているように見える。 -実はCodeGearは直接次のCodeGearのアドレスを参照するのではなく、 特定のMetaCodeGearに一度継続する。 -CodeGearの処理が実行した後に継続されるCodeGearは\texttt{\_\_code meta}と定義されているMetaCodeGearである。 -\texttt{\_\_code meta}の定義をソースコード\ref{src:meta}に示す。 -\texttt{\_\_code meta}はContextに格納されているCodeGearのリストから番号でCodeGearのアドレスを取得し継続する。 -継続する先のCodeGearは、呼び出し先のCodeGearの直前に実行されるStubCodeGearである。 -\lstinputlisting[label=src:meta, caption=\_\_code meta]{src/meta.cbc} - - - -CodeGearからCodeGearへの継続は、関数型プログラミングの継続先に渡すDataとCodeの組のClosureとなっている。 -シンタックスでは継続の際に引数\texttt{(...)}を渡す。 -これは処理系では特に使用していないキーワードであるが、 このClosureを持ち歩いていることを意識するために導入されている。 - - -各CodeGear、DataGearはContextはそれぞれ配列形式でContextにデータを格納する場所が用意されている。 -CodeGearが保存されている配列は\texttt{context->code}であり、 DataGearが保存されている配列は\texttt{context->data}である。 -CodeGearは配列の中にStubCodeGearへの関数ポインタが格納されている。 -DataGearはInterfaceを利用したgoto時の値の保存場所として配列を利用している。 -これらの配列の添え字はenumの番号である。 - -ノーマルレベルとメタレベルの切り分けの為に、ノーマルレベルではenumの番号を利用している。 -enumの番号から対応するデータを切り分けるのは、 メタレベルでContextにアクセスして行われる。 - - -Contextは配列形式のデータ格納場所のほかに、 ヒープ構造を所持している。 -計算で必要なDataGearは、 CbCの中でアロケーションした場合はContextにヒープに書き込まれる。 -ヒープにはDataGearと、書き込んだDataGearのメタ情報が記載されているMetaDataGearで構成されている。 - Contextはプロセスに相当するので、ユーザープログラムごとにCotnextが存在する。 このContextをUser Contextと呼ぶ。 さらに実行しているGPUやCPUごとにContextが必要となる。 @@ -88,6 +62,61 @@ GearsOSのメタレベルのプログラミングでは、 今処理をしているContextが誰のContextであるかを強く意識する必要がある。 + +ContextはGearsOSの計算で使用されるすべてのDataGearとCodeGearを持つ。 +つまりGearsOSで使われるCodeGearとDataGearは、 誰かのContextに必ず書き込まれている。 +各CodeGear、DataGearはContextはそれぞれ配列形式でContextにデータを格納する場所が用意されている。 +CodeGearが保存されている配列は\texttt{context->code}である。 +これは前述したStubCodeGearの関数ポインタが格納されており、 \texttt{\_\_code meta}でのディスパッチに利用される。 + +DataGearが保存されている配列は\texttt{context->data}である 。 +ただしGearsOSで使うすべてのDataGearがこのContextに保存されている訳ではない。 +Interfaceを利用したgoto時の値の保存場所として、この配列にDataGearごと割り振られた場所にDtaGearを保存する用途で利用している。 +CodeGearで利用している配列と同様に、 この配列の添え字もDataGearの番号に対応している。 + + +DataGearは配列形式のデータ格納場所のほかに、Contextが持つヒープに保存することも可能である。 +計算で必要なDataGearは、 CbCの中でアロケーションした場合はContextにヒープに書き込まれる。 +ヒープにはDataGearと、書き込んだDataGearのメタ情報が記載されているMetaDataGearで構成されている。 + + +\section{Stub Code Gear} + +次のCodeGearに継続する際、ノーマルレベルから見ると次のCodeGearを直接指定しているように見える。 +GearsOSではCodeGearの入力は、 メタレベルから見るとContextのみである。 +ノーマルレベルでは次のCodeGearに引数を渡しているが、 実際は素直に引数を渡せず、 使用するDataGearはContextから取得しなければならない。 +これらの処理はメタ計算である。 +GearsOSではメタ計算はMetaCodeGearが行っていた。 +必ずメタ計算を実行しなければならないので、 CodeGearは直接次のCodeGearに継続するのではなく、 特定のMetaCodeGearに一度継続する。 +ContextからのDataGearの取得は、StubCodeGearと呼ばれるMetaCodeGearが実行する。 +Contextと継続の関係性を図\ref{fig:stubCodeGear}に示す。 +StubCodeGearはGearsOSで定義されているノーマルレベルのCodeGearのすべてに生成される。 +ユーザーが記述したノーマルレベルのCodeGearへのgoto文は、 GearsOSのビルド時にPerlスクリプトによってMetaCodeGearへ継続するように書き換えられる。 + +\begin{figure}[h] + \begin{center} + \includegraphics[width=160mm]{drawio/stubCodeGear.pdf} + \end{center} + \caption{Contextを参照したCodeGearのデータアクセス} + \label{fig:stubCodeGear} + \end{figure} + + +StubCodeGearへの継続は、 CodeGearの処理が実行した後に継続されるCodeGearである\texttt{\_\_code meta}が行う。 +\texttt{\_\_code meta}の定義をソースコード\ref{src:meta}に示す。 +\texttt{\_\_code meta}はContextに格納されているCodeGearの配列からCodeGearのアドレスを取得し継続する。 +この際に配列の要素を特定する際に使われる添え字は、 各CodeGearに割り振られた番号を利用している。 +この番号はC言語の列挙体を使用した\texttt{enum Code}型で定義されている。 +\texttt{enum Code}型はGearsOSのコンパイル時に利用されているCodeGearを数え上げて生成される。 +継続する先のCodeGearは、呼び出し先のCodeGearの直前に実行されるStubCodeGearである。 +\lstinputlisting[label=src:meta, caption=\_\_code meta]{src/meta.cbc} + +CodeGearからCodeGearへの継続は、関数型プログラミングの継続先に渡すDataとCodeの組のClosureとなっている。 +シンタックスでは継続の際に引数\texttt{(...)}を渡す。 +これは処理系では特に使用していないキーワードであるが、 このClosureを持ち歩いていることを意識するために導入されている。 + + + \section{TaskManager} TaskManagerは性質上シングルトンである。 その為、複数Workerを走らせた場合でも1全体で1つのみの値を持っていたいものはTaskManagerが握っている必要がある。 @@ -131,9 +160,15 @@ GearsOSではビルドツールにCMakeを利用している。 ビルドフローを図\ref{fig:gearsbuild1}に示す。 CMakeはautomakeなどのMakeファイルを作成するツールに相当するものである。 -GearsOSでプログラミングする際は、ビルドしたいプロジェクトをCMakeLists.txtに記述する。 -CMakeは自身がコンパイルをすることはなく、ビルドツールであるmakeやninja-buildに処理を移譲している。 -CMakeはmakeやninja-buildが実行可能なMakefile、 build.ninjaの生成までを担当する。 +GearsOSでプログラミングする際は、ビルドしたいプロジェクトで利用するソースコード群をCMakeの設定ファイルであるCMakeLists.txtに記述する。 +CMakeLists.txtではGearsOSのビルドに必要な一連の処理をマクロ\texttt{GearsCommand}で制御している。 +このマクロにプロジェクト名を\texttt{TARGET}として、 コンパイルしたいファイルを\texttt{SOURCES}に記述する。 +ソースコード\ref{src:cmakeGearsMacro}の例では\texttt{pop\_and\_push}が\texttt{TARGET}に指定されている。 +なおヘッダファイルは\texttt{SOURCES}に指定する必要はなく、 自動で解決される。 + +CMake自身はコンパイルに必要なコマンドを実行することはなく、ビルドツールであるmakeやninja-buildに処理を移譲している。 +CMakeはmakeやninja-buildが実行時に必要とするファイルであるMakefile、 build.ninjaの生成までを担当する。 +\lstinputlisting[label=src:cmakeGearsMacro, caption=CMakeList.txt内でのプロジェクト定義]{src/GearsMacroCMake.txt} GearsOSのビルドでは直接CbCコンパイラがソースコードをコンパイルすることはなく、 間にPerlスクリプトが2種類実行される。 @@ -213,7 +248,12 @@ 書き換えにおいてはビルドシステムはCMakeを利用し、 Perlクロスコンパイラを導入してたりとGearsOSのビルドシステムとほぼ同じシステムを利用している。 GearsOSを使った比較的巨大な実用的なアプリケーションであるため、 xv6の書き換えを進むに連れて様々な面で必要な機能や課題が生まれている。 -これらは都度GearsOSの開発に還元されている。 +xv6はUNIX OSである為プロセス単位で処理を行っていたが、 ここに部分的にContextを導入した。 +xv6では割り込みのフラグなどを大域変数として使っていた。 +GearsOSで実装する場合はDataGear単位になるため、 これらのフラグもDataGearの形で実装し直した。 +このDataGearは各プロセスに対応するContextではなく、 中心的なContextがシングルトンで持っている必要がある。 +CbCxv6の実装を通してKernelの状況を記録しておくContext、つまりKernelContextが必要であることなどが判明した。 + \section{ARM用ビルドシステムの作製} GearsOSをビルドする場合は、x86アーキテクチャのマシンからビルドするのが殆どである。 この場合ビルドしたバイナリはx86向けのバイナリとなる。
--- a/paper/chapter/06-evaluation.tex Wed Feb 03 21:29:14 2021 +0900 +++ b/paper/chapter/06-evaluation.tex Thu Feb 04 11:43:18 2021 +0900 @@ -1,7 +1,14 @@ \chapter{評価} -\section{GearsOSのビルドシステム} +\section{GearsOSの構文作製} +GearsOSで使われるInterface、およびそのImplementの型定義ファイルを導入した。 +GearsOSでプログラミングする際に通常のC言語やJavaなどの言語の様に、まず型を作成してからプログラミングすることが可能になった。 + +ただし現状のGearsOSでは1ファイルに1つの型定義しかできない。 +アプリケーションとしてGearsOSを動かす現在の例題ではそこまで問題になっていない。 +しかし、CbC xv6などの実用的なアプリケーションを実装する場合は、ファイルの数が莫大になる可能性がある。 +1ファイル内で様々な型が定義可能になれば、 より見通しの良いプログラミングが可能であると考えられる。 \section{GearsOSのトランスコンパイラ} -\section{GearsOSのメタ計算} \ No newline at end of file +\section{GearsOSのメタ計算}
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/drawio/context.drawio Thu Feb 04 11:43:18 2021 +0900 @@ -0,0 +1,1 @@ +<mxfile host="Electron" modified="2021-02-04T02:38:54.595Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/14.1.8 Chrome/87.0.4280.88 Electron/11.1.1 Safari/537.36" etag="XZ5ZyyAKqiuWcEa4vNqW" version="14.1.8" type="device"><diagram id="X-8TgNY4EpAP3Io8cdn3" name="ページ1">5ZldU6MwFIZ/DZc6JRRaLrV13Qs7407dUffGSSFCViBMSL/89ZuUhK+g1lkrRa+a85IE8pyT5CQ1rEm8uaQwDWfER5EBBv7GsKYGAKbtWvxHKNtcscEgFwKKfVmpFOb4GUlRVVtiH2W1ioyQiOG0LnokSZDHahqklKzr1R5JVH9rCgOkCXMPRrp6i30W5uoYjEr9J8JBqN5sOm7+JIaqshxJFkKfrCuSdWFYE0oIy0vxZoIiAU9xydv9eOFp8WEUJWyfBifw1+zq983Dn8XZyWp6PricPVyfqG4ytlUjRj4HIE1CWUgCksDoolTPKVkmPhLdDrhV1rkiJOWiycW/iLGt9CZcMsKlkMWRfIo2mN3J5qJ8L8qnwJbmdFN5Nt0qI2F0e6d6EEbezFZm2WxnqXYZo+SpcJ7FlUeSMPlt5pjbOQIx7hfRKkxkST30Ck8VopAGiL1Wzy0igE8dRGLEP5k3pCiCDK/qHwJlDAdFvdLNvCA9/R6vg+Px+jdyemXad+B02e8KRkv5Ji0I6i5eh5iheQp3Y1/z5b3uzn0RrxBlaPM6ZJ2JbAAGcvWU28dYmutyLTaVFlbW4aESP37uaBjnbLngyoTvffznEkFqAAfGAleyyNICxHGDtuqg3RbQoAW0cyjO1vfgbNpdgx5qoKeQwRxv73CCznHaXwmnZXaN0+njrmWbjUm+77Zl2Yfi6PaSY3OxHNs6x2ELx0L8+CxKT6N6NL/tYXO5HJ22IP3UGW7qGVUfSDZXStB9aDoat0881anyu051hXFfNY7iTCfd+eahzmkPk73PdLumZ5TCbaVCSnDCskrP10Ioo2/YiL6h07j7eaO+2nzKcMu/oAy+Yij/EY96KhQiPlmPf3I306ACX3eL5Gg/lnzMrA4MRjhIeNnjY0eUC4IM9mB0Jh/E2PfzpQBl+Bkudl0JT8gg5P3a54Y9FX3x2Z9J1J3lUi2+cNpSqYO5Qk+lbgl9Qvr+zzvDaYa6DmoFztkziA93dTLQyN3A7GkGExgcPb7Wq6fPxadficwQgwZwIjHnF+I6JBClHiekptt9Qgr0G5Evx9myOqfc64sSjafbOU/9psTj4xb5wNdPEoBt19zRcgs4+pgcgZvlX7Z5plz+8W1d/AM=</diagram></mxfile> \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/paper/src/GearsMacroCMake.txt Thu Feb 04 11:43:18 2021 +0900 @@ -0,0 +1,6 @@ +GearsCommand( + TARGET + pop_and_push + SOURCES + examples/pop_and_push/main.cbc examples/pop_and_push/StackTestImpl.cbc TaskManagerImpl.cbc CPUWorker.cbc SynchronizedQueue.cbc AtomicReference.cbc SingleLinkedStack.cbc examples/pop_and_push/StackTest2Impl.cbc examples/pop_and_push/StackTestImpl3.cbc +)