\chapter{GearsOS}

GearsOSとはContinuation Based Cを用いて信頼性と拡張性の両立を目指して実装しているOSプロジェクトである。\cite{gears}
CodeGearとDataGearを基本単位として実行する。
CodeGearを基本単位としているため、 各CodeGearは割り込みされず実行される必要がある。
割り込みを完全に制御することは一般的には不可能であるが、 GearsOSのメタ計算部分でこれを保証したい。
DataGearも基本単位であるため、 各CodeGearがDataGearをどのように扱っているか、書き込みをしたかはGearsOS側で保証するとしている。


GearsOSはOSとして実行する側面と、 CbCのシンタックスを拡張した言語フレームワークとしての側面がある。
GearsOSはノーマルレベルとメタレベルの分離を目指して構築しているOSである。
すべてをプログラマが純粋なCbCで記述してしまうと、 メタレベルの情報を実装しなければならず、ノーマルレベルとメタレベルの分離をした意味がなくなってしまう。
GesrsOSではユーザーが書いたノーマルレベルのコードの特定の記述や、シンタックスをもとに、メタレベルの情報を含む等価なCbCへとコンパイル時にコードを変換する。
コード変換はPerlスクリプトで行われている。

現在のGearsOSはUnixシステム上のアプリケーションとして実装されているものと、 xv6の置き換えとして実装されているもの\cite{weko_195888_1}がある。

\section{GearsOSの構成}

GearsOSは様々な役割を持つCodeGearとDataGearで構成されている。
またCodeGearとDataGearのモジュール化の仕組みとしてInterfaceが導入されている。
GearsOSの構成図を図\ref{fig:gearsstruct}に示す。
中心となるMetaDataGearは以下の要素である。

\begin{itemize}
  \item Context
  \item TaskManager
  \item TaskQueue
  \item Worker
\end{itemize}

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=150mm]{fig/gears_structure.pdf}
  \end{center}
  \caption{GearsOSの構成}
  \label{fig:gearsstruct}
\end{figure}

\section{Context}
Contextとは従来のOSのプロセスに相当する概念である。
GearsOSでのデータの単位から見ると、 MetaDataGearに相当する。
Contextの概要図を図\ref{fig:context}に、実際のCbC上での定義をソースコード\ref{src:structContext}に示す。

ContextはMetaDataGearである為に、 ノーマルレベルのCodeGearからはcontextは直接参照しない。
contextの操作をしてしまうと、メタレベルとノーマルレベルの分離をした意味がなくなってしまう為である。

Contextはプロセスに相当するので、ユーザープログラムごとにCotnextが存在する。
このContextをUser Contextと呼ぶ。
さらに実行しているGPUやCPUごとにContextが必要となる。
これらはCPU Contextと呼ばれる。
GearsOSはOSであるため、全体を管理するKernelのContextも必要となる。
これはKernelContextやKContextと呼ばれる。
KContextはすべてのContextを参照する必要がある。
OSが持たなければならない割り込みのフラグなどはKContextに置かれている。
GearsOSのメタレベルのプログラミングでは、 今処理をしているContextが誰のContextであるかを強く意識する必要がある。

\lstinputlisting[label=src:structContext, caption=contextの定義]{src/structContext.h}
\begin{figure}[t]
  \begin{center}
   \includegraphics[width=120mm]{drawio/context.pdf}
  \end{center}
  \caption{Contextの概要図}
  \label{fig:context}
 \end{figure}


ContextはGearsOSの計算で使用されるすべてのDataGearとCodeGearを持つ。
つまりGearsOSで使われるCodeGearとDataGearは、 誰かのContextに必ず書き込まれている。
各CodeGear、DataGearはContextはそれぞれ配列形式でContextにデータを格納する場所が用意されている。
CodeGearが保存されている配列はソースコード\ref{src:structContext}の6行目で定義している\texttt{code}である。
StubCodeGearはContextのみを引数で持つため、 \texttt{\_\_code stub(struct Context*)}の様なCodeGearの関数ポインタのポインタ、つまりCodeGearの配列としての定義されている。
これは前述したStubCodeGearの関数ポインタが格納されており、 \texttt{\_\_code meta}でのディスパッチに利用される。

DataGearが保存されている配列は7行目で定義している\texttt{data}である 。
すべてのDataGearはGearsOS上では\texttt{union Data}型として取り扱えるので、 \texttt{union Data}のポインタの配列として宣言されている。
ただしGearsOSで使うすべてのDataGearがこのContextに保存されている訳ではない。
Interfaceを利用したgoto時の値の保存場所として、この配列にDataGearごと割り振られた場所にDtaGearを保存する用途で利用している。
CodeGearで利用している配列と同様に、 この配列の添え字もDataGearの番号に対応している。


DataGearは配列形式のデータ格納場所のほかに、Contextが持つヒープに保存することも可能である。
計算で必要なDataGearは、 CbCの中でアロケーションした場合はContextにヒープに書き込まれる。
ヒープにはDataGearと、書き込んだDataGearのメタ情報が記載されているMetaDataGearで構成されている。
\section{Stub Code Gear}
次のCodeGearに継続する際、ノーマルレベルから見ると次のCodeGearを直接指定しているように見える。
さらに次のCodeGearに引数などを直接渡しているようにも見える。
しかしノーマルレベルから次のCodeGearに継続する場合は関数ポインタなどが必要になるが、 これらはメタ計算に含まれる。
その為純粋にノーマルレベルからCodeGear間を自由に継続させてしまうと、 ノーマルレベルとメタレベルの分離ができなくなってしまう。
ノーマルレベルとメタレベルの分離の為に、 次のCodeGearには直接継続させず、間にMetaCodeGearをはさむようにする必要がある。
またポインタをノーマルレベルには持たせず、 継続先のCodeGearは番号を使って指定する。
CodeGear間の継続はGearsOSのビルド時にPerlスクリプトによって書き換えが行われ、MetaCodeGearを経由するように変更される。

GearsOSではDataGearはすべてContextを経由してやり取りをする。
次の継続にDataGearを渡す場合、 継続する前に一度ContextにDataGearを書き込み、 継続先でContextからDataGearを取り出す。
ContextはMetaDataGearであるために、 ノーマルレベルのCodeGearではなくMetaCodeGearで扱う必要がある。
各CodeGearの計算で必要なDataGearをContextから取り出すMetaCodeGearは、 実行したいCodeGearの直前で実行される必要がある。
このCodeGearを特にStubCodeGearと呼ぶ。
StubCodeGearはすべてのCodeGearに対して実装しなければならず、 手で実装するのは煩雑である。
StubCodeGearもGearsOSのビルド時にPerlスクリプトによって自動生成される。

ソースコード\ref{src:StackPush}に示すノーマルレベルで記述したCodeGearを、Perlスクリプトによって変換した結果をソースコード\ref{src:StackPushStub}に示す。
常に自分自身のContextをCodeGearは入力の形で受け取る為、変換後の\texttt{pushSingleLinkedStack}は、 第1引数にContextが加わっている。
pushSingleLinkedStackは引数は3つ要求していた。
これらの引数は生成された\texttt{pushSingleLinkedStack\_stub}がContextの特定の場所から取り出す。
このCodeGearはGearsOSのInterfaceを利用しており、 Stack Interaceの実装となっている。
マクロ\texttt{Gearef}は、 contextのInterface用のDataGearの置き場所にアクセスするマクロであり、 Stack Interfaceの置き場所から、引数情報を取得している。
マクロ\texttt{Gearef}の定義をソースコード\ref{src:gearef}に示す。
マクロ\texttt{Gearef}では引数で与えられたDataGearの名前を、enumを利用した番号に変換し、contextから値を取り出している。
DataGearは\texttt{enum Data}型で各DataGearの型ごとに番号が割り振られている。(ソースコード\ref{src:enumData})
\lstinputlisting[label=src:gearef, caption=Gearefマクロ]{src/gearef.h}
\lstinputlisting[label=src:enumData, caption=enumDataの定義]{src/enumData.h}


すべての引数を取得したのちに、\texttt{goto pushSingleLinkedStack}で、CodeGearに継続する。
\lstinputlisting[label=src:StackPush, caption=StackにPushするCodeGear]{src/StackPush.cbc}
\lstinputlisting[label=src:StackPushStub, caption=\ref{src:StackPush}のStubCodeGear]{src/StackPush.c}


Contextと継続の関係性を図\ref{fig:stubCodeGear}に示す。
StubCodeGearはGearsOSで定義されているノーマルレベルのCodeGearのすべてに生成される。

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=160mm]{drawio/stubCodeGear.pdf}
  \end{center}
  \caption{Contextを参照したCodeGearのデータアクセス}
  \label{fig:stubCodeGear}
 \end{figure}


\texttt{\_\_code meta}の定義をソースコード\ref{src:meta}に示す。
\lstinputlisting[label=src:meta, caption=\_\_code meta]{src/meta.cbc}
\texttt{\_\_code meta}はContextに格納されているCodeGearの配列からCodeGearのアドレスを取得し継続する。
この際に配列の要素を特定する際に使われる添え字は、 各CodeGearに割り振られた番号を利用している。
この番号はC言語の列挙体を使用した\texttt{enum Code}型で定義されている。
\texttt{enum Code}型の定義をソースコード\ref{src:enumCode}に示す。
命名規則は\texttt{C\_CodeGearName}となっている。
\lstinputlisting[label=src:enumCode, caption=CodeGearの番号であるenumCodeの定義]{src/enumCode.h}
\texttt{enum Code}型はGearsOSのコンパイル時に利用されているCodeGearを数え上げて生成される。
Contextのcode配列には、各CodeGearのStubCodeGearの関数ポインタが配置されている。
よって\texttt{\_\_code meta}から継続する先のCodeGearは、呼び出し先のCodeGearの直前に実行されるStubCodeGearになる。

CodeGearからCodeGearへの継続は、関数型プログラミングの継続先に渡すDataとCodeの組のClosureとなっている。
シンタックスでは継続の際に引数\texttt{(...)}を渡す。
これは処理系では特に使用していないキーワードであるが、 このClosureを持ち歩いていることを意識するために導入されている。



\section{TaskManager}
TaskManagerはGearsOS上で実行されるTaskの管理を行う。
GearsOS上のTaskとはContextのことであり、 各Contextには自分の計算に必要なDataGearのカウンタなどが含まれている。
TaskManagerは、CodeGearの計算に必要な入力のDataGear(InputDataGear)が揃っているかの確認、揃っていなかったら待ち合わせを行う処理がある。
すべてのDataGearが揃った場合、 TaskをWorkerのQueueに通知しTaskを実行させる。
この処理はGearsOSを並列実行させる場合に必要な機能となっている。

TaskManagerは性質上シングルトンである。
その為、複数Workerを走らせた場合でも1全体で1つのみの値を持っていたいものはTaskManagerが握っている必要がある。
例えばモデル検査用の状態保存用のデータベース情報は、 TaskManagerが所有している。

\section{TaskQueue}
GearsOSのTaskQueueはSynchronizedQueueで表現されている。
TaskQueueはWorkerが利用するQueueとなっている。

WorkerのQueueは、TaskManagerに接続してTaskを送信するスレッドと、 Taskを実行するWorker自身のスレッドで扱われる。
さらにWorkerが複数走る可能性もある。
その為SynchronizedQueueは、マルチスレッドでもデータの一貫性を保証する必要がある。
GearsOSではCAS(Check and Set, Compare and Swap)を利用して実装が行われている。

\section{Worker}
WorkerはWorkerの初期化にスレッドを作る。
GearsOSではスレッドごとにそれぞれContextが生成される。
Workerはスレッド作製後にContextの初期化APIを呼び出し、自分のフィールドにContextのアドレスを書き込む。

スレッド作製後はTaskManagerからTaskを取得する。
TaskはContextの形で表現されているために、WorkerのContextをTaskに切り替え、 Taskの次の継続に実行する。
OutputDataGearがある場合は、Task実行後にDataGearの書き出しが行われる。

WorkerはCodeGearの前後で確実に呼び出される。
この性質を利用すると、 CodeGearの実行の前後での状態を記録することが可能である。
つまりモデル検査が可能である為、モデル検査用のWorkerを定義して入れ替えるとコードに変更を与えずに実行できる。
Worker自体はInterfaceで表現されているために、入れ替えは容易となっている。
GearsOSでは通常のWorkerとしてCPUWorkerを、GPUに関連した処理をするCUDAWorker、合間にモデル検査関連のメタ計算をはさむMCWorkerが定義されている。
\section{union Data型}

CbC/GearsOSではDataGearは構造体の形で表現されていた。
すべてのDataGearを管理する、Contextは計算で使うすべてのDataGearの型定義を持っている。
各DataGearは当然ではあるが別の型である。
例えばStack DataGearとQueue DataGearは、それぞれstruct Stackとstruct Queueで表現されるが、 C言語のシステム上別の型とみなされる。
メタレベルで見れば、 この型定義は\texttt{union Data}型にすべて書かれている。
しかしContextはこれらの型をすべてDataGearとして等しく扱う必要がある。
この為にC言語の共用体を使用し、汎用的なDataGearの型であるunion Data型を定義している。
共用体とは、構成するメンバ変数で最大の型のメモリサイズと同じメモリサイズになる特徴があり、複数の異なる型をまとめて管理することができる。
構造体と違い、1度に一つの型しか使うことができない。


実際にどの型が書き込まれているかは、 Contextのどこに書き込まれているかによって確認の方法が異なる。
Interfaceの入出力で利用しているdata配列の場合は、enumの番号とdata配列の添え字が対応している。
このためenumで指定した場所に入っているunion Dataの具体的な型は、 enumと対応するDataGearになる。
contextのヒープにアロケートされたDataGearの場合は、 型情報を取得できるMetaDataGearにアクセスすると、なんの型であったかが分かる。

Contextから取り出してきたunion DataからDataGearの型への変換はメタ計算で行われる。
GearsOSの場合は、計算したいCodeGearの直前で実行されるStubCodeGearで値のキャストが行われる。

\section{Interface}
GearsOSのモジュール化の仕組みとしてInterfaceがある。
InterfaceはCodeGearと各CodeGearで使う入出力のDataGearの集合である。
Interfaceに定義されているCodeGearは、各Interfaceが満たすこと期待するAPIである。
GearsOSに実装されているQueueのInterfaceの定義をソースコード\ref{src:queue}に示す。
\lstinputlisting[label=src:queue, caption=QueueのInterface]{src/queue.h}

Intefaceは仕様(Interface)と、実装(Implement, Impl)を別けて記述する。
Interfaceを呼び出す場合は、Interfaceに定義されたAPIに沿ってプログラミングをすることで、Implの内容を隠蔽することができる。
これによってメタ計算部分で実装を入れ替えつつInterfaceを使用したり、 ふるまいを変更することなく具体的な処理の内容のみを変更することが容易にできる。
これはJavaのInterface、Haskellの型クラスに相当する機能である。
GearsOSではStackやQueueがInterfaceとして定義済みであり、 SingleLinkedStackなどが実装として提供されている。
また、WorkerやTaskManagerもInterfaceであり、 コンストラクタを呼び出している箇所を切り替えれば様々な用途に応じたWorkerなどを呼び出すことが可能である。

\lstinputlisting[label=src:SingleLinkedQueueOld, caption=SingleLinkedQueueの実装]{src/SingleLinkedQueueOld.cbc}

Interface自身もDataGearであり、実際の定義はcontextのunion Data型に記述されている。

Interfaceで定義したCodeGearの出力は必ずDataGearでなければならない。
OutputDataGear自体はInteface自身のDataGearにメタレベルで書き込まれる。


\section{GearsOSのビルドシステム}
GearsOSではビルドツールにCMakeを利用している。
ビルドフローを図\ref{fig:gearsbuild1}に示す。
CMakeはautomakeなどのMakeファイルを作成するツールに相当するものである。
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種類実行される。
Perlスクリプトはビルド対象のGearsOSで拡張されたCbCファイルを、純粋なCbCファイルに変換する。
ほかにGearsOSで動作する例題ごとに必要な初期化関数なども生成する。
Perlスクリプトで変換されたCbCファイルなどをもとにCbCコンパイラがコンパイルを行う。
ビルドの処理は自動化されており、 CMake経由でmakeやninjaコマンドを用いてビルドする。

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=150mm]{drawio/geasflow1.pdf}
  \end{center}
  \caption{GearsOSのビルドフロー}
  \label{fig:gearsbuild1}
\end{figure}



\section{GearsOSのCbCから純粋なCbCへの変換}
GearsOSはCbCを拡張した言語となっている。
ただしこの拡張自体はCbCコンパイラであるgcc、 llvm/clangには搭載されていない。
その為GearsOSの拡張部分を、等価な純粋なCbCの記述に変換する必要がある。
現在のGearsOSでは、 CMakeによるコンパイル時にPerlで記述された\texttt{generate\_stub.pl}と\texttt{generate\_context.pl}の2種類のスクリプトで変換される。

\section{generate\_stub.pl}
generate\_stub.plは各CbCファイルごとに呼び出される。
入力としてCbCファイルを受け取りメタ計算を含んだ形に変換し、 純粋なCbCファイルとして書き出す。
図\ref{fig:generate_stub_pl_1}に処理の概要を示す

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=160mm]{drawio/gears_os_build_flow.pdf}
  \end{center}
  \caption{generate\_sub.plを使ったトランスコンパイル}
  \label{fig:generate_stub_pl_1}
\end{figure}

\section{generate\_context.pl}


\begin{itemize}
  \item \texttt{generate\_stub.pl}
  \begin{itemize}
    \item 各CbCファイルごとに呼び出されるスクリプト
    \item 対応するメタ計算を導入したCbCファイル(拡張子はc)に変換する
  \end{itemize}
  \item \texttt{generate\_context.pl}
  \begin{itemize}
    \item 生成したCbCファイルを解析し、使われているCodeGearを確定する
    \item context.hを読み込み、使われているDataGearを確定する
    \item Context関係の初期化ルーチンやCodeGear、 DataGearの番号であるenumを生成する
    \begin{itemize}
      \item 図\ref{fig:generate_context_1}に処理の概要を示す
    \end{itemize}
  \end{itemize}
\end{itemize}

これらのPerlスクリプトはプログラマが自分で動かすことはない。
Perlスクリプトの実行手順はCMakeLists.txtに記述しており、 makeやninja-buildでのビルド時に呼び出される。(ソースコード \ref{src:cmake1})

\lstinputlisting[label=src:cmake1, caption=CMakeList.txt内でのPerlの実行部分]{src/cmakefile.1.txt}

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=130mm]{drawio/old_generate_context.pdf}
  \end{center}
  \caption{generate\_context.plを使ったファイル生成}
  \label{fig:generate_context_1}
 \end{figure}



\section{CbC xv6}
CbC xv6はGearsOSのシステムを利用してxv6 OSの置き換えを目指しているプロジェクトである。\cite{cbcxv6repo}
xv6はv6 OS\cite{lions1996lions}をx86アーキテクチャ用にMITによって実装し直されたものである。
Raspberry Pi上での動作を目指しているため、 ARMアーキテクチャ用に改良されたバージョンを利用している。\cite{xv6rpi}

書き換えにおいてはビルドシステムはCMakeを利用し、 Perlクロスコンパイラを導入してたりとGearsOSのビルドシステムとほぼ同じシステムを利用している。
GearsOSを使った比較的巨大な実用的なアプリケーションであるため、 xv6の書き換えを進むに連れて様々な面で必要な機能や課題が生まれている。
xv6はUNIX OSである為プロセス単位で処理を行っていたが、 ここに部分的にContextを導入した。
xv6では割り込みのフラグなどを大域変数として使っていた。
GearsOSで実装する場合はDataGear単位になるため、 これらのフラグもDataGearの形で実装し直した。
このDataGearは各プロセスに対応するContextではなく、 中心的なContextがシングルトンで持っている必要がある。
CbCxv6の実装を通してKernelの状況を記録しておくContext、つまりKernelContextが必要であることなどが判明した。

\section{ARM用ビルドシステムの作製}
GearsOSをビルドする場合は、x86アーキテクチャのマシンからビルドするのが殆どである。
この場合ビルドしたバイナリはx86向けのバイナリとなる。
これはビルドをするホストマシンに導入されているCbCコンパイラがx86アーキテクチャ向けにビルドされたものである為である。

CbCコンパイラはGCCとllvm/clang上に構築した2種類が主力な処理系である。
LVM/clangの場合はLLVM側でターゲットアーキテクチャを選択することが可能である。
GCCの場合は最初からjターゲットアーキテクチャを指定してコンパイラをビルドする必要がある。

時にマシンスペックの問題などから、 別のアーキテクチャ向けのバイナリを生成したいケースがある。
教育用マイコンボードであるRaspberry Pi\cite{rpi}はARMアーキテクチャが搭載されている。
Raspberry Pi上でGearsOSのビルドをする場合、 ARM用にビルドされたCbCコンパイラが必要となる。
Raspberry Pi自体は非力なマシンであるため、 GearsOSのビルドはもとよりCbCコンパイラの構築をRaspberry Pi上でするのは困難である。
マシンスペックが高めのx86マシンからARM用のバイナリをビルドして、 Raspberry Piに転送し実行したい。
ホストマシンのアーキテクチャ以外のアーキテクチャ向けにコンパイルすることをクロスコンパイルと呼ぶ。


GearsOSはビルドツールにCMakeを利用しているので、 CMakeでクロスコンパイル可能に工夫をしなければならない。
ビルドに使用するコンパイラやリンカはCMakeが自動探索し、 決定した上でMakefileやbuild.ninjaファイルを生成する。
しかしCMakeは今ビルドしようとしている対象が、自分が動作しているアーキテクチャかそうでないか、クロスコンパイラとして使えるかなどはチェックしない。
つまりCMakeが自動でクロスコンパイル対応のGCCコンパイラを探すことはない。
その為そのままビルドするとx86用のバイナリが生成されてしまう。


CMakeを利用してクロスコンパイルする場合、CMakeの実行時に引数でクロスコンパイラを明示的に指定する必要がある。
この場合x86のマシンからARMのバイナリを出力する必要があり、 コンパイラやリンカーなどをARMのクロスコンパイル対応のものに指定する必要がある。
また、 xv6の場合はリンク時に特定のリンカスクリプトを使う必要がある。
これらのリンカスクリプトもCMake側に、 CMakeが提供しているリンカ用の特殊変数を使って自分で組み立てて渡す必要がある。
CMake側に使用したいコンパイラの情報を渡せれば、以降はCMake側が自動的に適切なビルドスクリプトを生成してくれる。
このようなCMakeの処理を手打ちで行うことは難しいので、 \texttt{pmake.pl}を作成した。
\texttt{pmake.pl}の処理の概要を図\ref{fig:pmake}に示す。
\texttt{pmake.pl}はPerlスクリプトで、 シェルコマンドを内部で実行しクロスコンパイル用のオプションを組み立てる。
\texttt{pmake.pl}を経由してCMakeを実行すると、 makeコマンドに対応するMakefile、 ninja-buildに対応するbuild.ninjaが生成される。
以降はcmakeではなくmakeなどのビルドツールがビルドを行う。

\begin{figure}[h]
  \begin{center}
   \includegraphics[width=160mm]{drawio/pmake.pdf}
  \end{center}
  \caption{pmake.plの処理フロー}
  \label{fig:pmake}
 \end{figure}




 \section{Interfaceの取り扱い方法の検討}

 GearsOSのInterfaceはモジュール化の仕組みと\texttt{goto}文での引数の一時保管場所としての機能を持っている。
InterfaceのImplementのヘッダーファイルを実装したことで、 GearsOS上でInterfaceを実装する際に新たな方法での実装を検討した。
ImplementのCodeGearは今まではInterfaceで定義したCodeGearと1対1対応していた。
ImplementのCodeGearからgotoする先は、 入力として与えられたCodeGearか、 Implement内で独自に定義したCodeGearにgotoするケースとなっていた。
後者の独自に定義したCodeGearにgotoするケースも、 実装のCbCファイルの中に記述されているCodeGearに遷移していた。

GearsOSを用いてxv6 OSを再実装した際に、 実装側のCodeGearを細かく別けて記述した。
細分化によって1つのCbCファイルあたりのCodeGearの記述量が増えてしまうという問題が発生した。
見通しをよくする為に、 Interfaceで定義したCodeGearと直接対応するCodeGearの実装と、 それらからgotoするCodeGearで実装ファイルを分離することを試みた。