|
33
|
1 \chapter{GearsOS}
|
|
|
2
|
|
142
|
3 GearsOSとはContinuation Based Cを用いて信頼性と拡張性の両立を目指して実装しているOSプロジェクト\cite{gears}である。
|
|
34
|
4 CodeGearとDataGearを基本単位として実行する。
|
|
65
|
5 CodeGearを基本単位としているため、 各CodeGearは割り込みされず実行される必要がある。
|
|
|
6 割り込みを完全に制御することは一般的には不可能であるが、 GearsOSのメタ計算部分でこれを保証したい。
|
|
|
7 DataGearも基本単位であるため、 各CodeGearがDataGearをどのように扱っているか、書き込みをしたかはGearsOS側で保証するとしている。
|
|
|
8
|
|
|
9
|
|
34
|
10 GearsOSはOSとして実行する側面と、 CbCのシンタックスを拡張した言語フレームワークとしての側面がある。
|
|
65
|
11 GearsOSはノーマルレベルとメタレベルの分離を目指して構築しているOSである。
|
|
|
12 すべてをプログラマが純粋なCbCで記述してしまうと、 メタレベルの情報を実装しなければならず、ノーマルレベルとメタレベルの分離をした意味がなくなってしまう。
|
|
71
|
13 GesrsOSではユーザーが書いたノーマルレベルのコードの特定の記述や、シンタックスをもとに、メタレベルの情報を含む等価なCbCへとコンパイル時にコードを変換する。
|
|
|
14 コード変換はPerlスクリプトで行われている。
|
|
34
|
15
|
|
57
|
16 現在のGearsOSはUnixシステム上のアプリケーションとして実装されているものと、 xv6の置き換えとして実装されているもの\cite{weko_195888_1}がある。
|
|
67
|
17
|
|
|
18 \section{GearsOSの構成}
|
|
|
19
|
|
68
|
20 GearsOSは様々な役割を持つCodeGearとDataGearで構成されている。
|
|
71
|
21 またCodeGearとDataGearのモジュール化の仕組みとしてInterfaceが導入されている。
|
|
68
|
22 GearsOSの構成図を図\ref{fig:gearsstruct}に示す。
|
|
70
|
23 中心となるMetaDataGearは以下の要素である。
|
|
|
24
|
|
|
25 \begin{itemize}
|
|
|
26 \item Context
|
|
|
27 \item TaskManager
|
|
|
28 \item TaskQueue
|
|
|
29 \item Worker
|
|
|
30 \end{itemize}
|
|
68
|
31
|
|
67
|
32 \begin{figure}[h]
|
|
|
33 \begin{center}
|
|
|
34 \includegraphics[width=150mm]{fig/gears_structure.pdf}
|
|
|
35 \end{center}
|
|
|
36 \caption{GearsOSの構成}
|
|
|
37 \label{fig:gearsstruct}
|
|
|
38 \end{figure}
|
|
|
39
|
|
60
|
40 \section{Context}
|
|
|
41 Contextとは従来のOSのプロセスに相当する概念である。
|
|
61
|
42 GearsOSでのデータの単位から見ると、 MetaDataGearに相当する。
|
|
71
|
43 Contextの概要図を図\ref{fig:context}に、実際のCbC上での定義をソースコード\ref{src:structContext}に示す。
|
|
61
|
44
|
|
155
|
45 ContextはMetaDataGearである為に、 ノーマルレベルのCodeGearからはcontextを直接参照しない。
|
|
70
|
46 contextの操作をしてしまうと、メタレベルとノーマルレベルの分離をした意味がなくなってしまう為である。
|
|
69
|
47
|
|
66
|
48 Contextはプロセスに相当するので、ユーザープログラムごとにCotnextが存在する。
|
|
|
49 このContextをUser Contextと呼ぶ。
|
|
|
50 さらに実行しているGPUやCPUごとにContextが必要となる。
|
|
|
51 これらはCPU Contextと呼ばれる。
|
|
|
52 GearsOSはOSであるため、全体を管理するKernelのContextも必要となる。
|
|
|
53 これはKernelContextやKContextと呼ばれる。
|
|
|
54 KContextはすべてのContextを参照する必要がある。
|
|
|
55 OSが持たなければならない割り込みのフラグなどはKContextに置かれている。
|
|
|
56 GearsOSのメタレベルのプログラミングでは、 今処理をしているContextが誰のContextであるかを強く意識する必要がある。
|
|
|
57
|
|
71
|
58 \lstinputlisting[label=src:structContext, caption=contextの定義]{src/structContext.h}
|
|
|
59 \begin{figure}[t]
|
|
|
60 \begin{center}
|
|
|
61 \includegraphics[width=120mm]{drawio/context.pdf}
|
|
|
62 \end{center}
|
|
|
63 \caption{Contextの概要図}
|
|
|
64 \label{fig:context}
|
|
|
65 \end{figure}
|
|
66
|
66
|
|
70
|
67
|
|
|
68 ContextはGearsOSの計算で使用されるすべてのDataGearとCodeGearを持つ。
|
|
|
69 つまりGearsOSで使われるCodeGearとDataGearは、 誰かのContextに必ず書き込まれている。
|
|
155
|
70 各CodeGear、DataGearは、それぞれ配列形式でContextにデータを格納する場所が用意されている。
|
|
71
|
71 CodeGearが保存されている配列はソースコード\ref{src:structContext}の6行目で定義している\texttt{code}である。
|
|
|
72 StubCodeGearはContextのみを引数で持つため、 \texttt{\_\_code stub(struct Context*)}の様なCodeGearの関数ポインタのポインタ、つまりCodeGearの配列としての定義されている。
|
|
70
|
73 これは前述したStubCodeGearの関数ポインタが格納されており、 \texttt{\_\_code meta}でのディスパッチに利用される。
|
|
|
74
|
|
71
|
75 DataGearが保存されている配列は7行目で定義している\texttt{data}である 。
|
|
|
76 すべてのDataGearはGearsOS上では\texttt{union Data}型として取り扱えるので、 \texttt{union Data}のポインタの配列として宣言されている。
|
|
70
|
77 ただしGearsOSで使うすべてのDataGearがこのContextに保存されている訳ではない。
|
|
|
78 Interfaceを利用したgoto時の値の保存場所として、この配列にDataGearごと割り振られた場所にDtaGearを保存する用途で利用している。
|
|
|
79 CodeGearで利用している配列と同様に、 この配列の添え字もDataGearの番号に対応している。
|
|
|
80
|
|
|
81
|
|
|
82 DataGearは配列形式のデータ格納場所のほかに、Contextが持つヒープに保存することも可能である。
|
|
|
83 計算で必要なDataGearは、 CbCの中でアロケーションした場合はContextにヒープに書き込まれる。
|
|
|
84 ヒープにはDataGearと、書き込んだDataGearのメタ情報が記載されているMetaDataGearで構成されている。
|
|
71
|
85 \section{Stub Code Gear}
|
|
|
86 次のCodeGearに継続する際、ノーマルレベルから見ると次のCodeGearを直接指定しているように見える。
|
|
|
87 さらに次のCodeGearに引数などを直接渡しているようにも見える。
|
|
|
88 しかしノーマルレベルから次のCodeGearに継続する場合は関数ポインタなどが必要になるが、 これらはメタ計算に含まれる。
|
|
|
89 その為純粋にノーマルレベルからCodeGear間を自由に継続させてしまうと、 ノーマルレベルとメタレベルの分離ができなくなってしまう。
|
|
|
90 ノーマルレベルとメタレベルの分離の為に、 次のCodeGearには直接継続させず、間にMetaCodeGearをはさむようにする必要がある。
|
|
72
|
91 またポインタをノーマルレベルには持たせず、 継続先のCodeGearは番号を使って指定する。
|
|
71
|
92 CodeGear間の継続はGearsOSのビルド時にPerlスクリプトによって書き換えが行われ、MetaCodeGearを経由するように変更される。
|
|
|
93
|
|
|
94 GearsOSではDataGearはすべてContextを経由してやり取りをする。
|
|
|
95 次の継続にDataGearを渡す場合、 継続する前に一度ContextにDataGearを書き込み、 継続先でContextからDataGearを取り出す。
|
|
|
96 ContextはMetaDataGearであるために、 ノーマルレベルのCodeGearではなくMetaCodeGearで扱う必要がある。
|
|
|
97 各CodeGearの計算で必要なDataGearをContextから取り出すMetaCodeGearは、 実行したいCodeGearの直前で実行される必要がある。
|
|
|
98 このCodeGearを特にStubCodeGearと呼ぶ。
|
|
|
99 StubCodeGearはすべてのCodeGearに対して実装しなければならず、 手で実装するのは煩雑である。
|
|
|
100 StubCodeGearもGearsOSのビルド時にPerlスクリプトによって自動生成される。
|
|
|
101
|
|
|
102 ソースコード\ref{src:StackPush}に示すノーマルレベルで記述したCodeGearを、Perlスクリプトによって変換した結果をソースコード\ref{src:StackPushStub}に示す。
|
|
|
103 常に自分自身のContextをCodeGearは入力の形で受け取る為、変換後の\texttt{pushSingleLinkedStack}は、 第1引数にContextが加わっている。
|
|
155
|
104 pushSingleLinkedStackは引数を3つ要求していた。
|
|
71
|
105 これらの引数は生成された\texttt{pushSingleLinkedStack\_stub}がContextの特定の場所から取り出す。
|
|
|
106 このCodeGearはGearsOSのInterfaceを利用しており、 Stack Interaceの実装となっている。
|
|
|
107 マクロ\texttt{Gearef}は、 contextのInterface用のDataGearの置き場所にアクセスするマクロであり、 Stack Interfaceの置き場所から、引数情報を取得している。
|
|
72
|
108 マクロ\texttt{Gearef}の定義をソースコード\ref{src:gearef}に示す。
|
|
|
109 マクロ\texttt{Gearef}では引数で与えられたDataGearの名前を、enumを利用した番号に変換し、contextから値を取り出している。
|
|
145
|
110 DataGearは\texttt{enum Data}型で各DataGearの型ごとに番号が割り振られている(ソースコード\ref{src:enumData})。
|
|
72
|
111 \lstinputlisting[label=src:gearef, caption=Gearefマクロ]{src/gearef.h}
|
|
|
112 \lstinputlisting[label=src:enumData, caption=enumDataの定義]{src/enumData.h}
|
|
|
113
|
|
|
114
|
|
71
|
115 すべての引数を取得したのちに、\texttt{goto pushSingleLinkedStack}で、CodeGearに継続する。
|
|
|
116 \lstinputlisting[label=src:StackPush, caption=StackにPushするCodeGear]{src/StackPush.cbc}
|
|
|
117 \lstinputlisting[label=src:StackPushStub, caption=\ref{src:StackPush}のStubCodeGear]{src/StackPush.c}
|
|
70
|
118
|
|
|
119
|
|
|
120 Contextと継続の関係性を図\ref{fig:stubCodeGear}に示す。
|
|
|
121 StubCodeGearはGearsOSで定義されているノーマルレベルのCodeGearのすべてに生成される。
|
|
|
122
|
|
|
123 \begin{figure}[h]
|
|
|
124 \begin{center}
|
|
|
125 \includegraphics[width=160mm]{drawio/stubCodeGear.pdf}
|
|
|
126 \end{center}
|
|
|
127 \caption{Contextを参照したCodeGearのデータアクセス}
|
|
|
128 \label{fig:stubCodeGear}
|
|
|
129 \end{figure}
|
|
|
130
|
|
|
131
|
|
|
132 \texttt{\_\_code meta}の定義をソースコード\ref{src:meta}に示す。
|
|
72
|
133 \lstinputlisting[label=src:meta, caption=\_\_code meta]{src/meta.cbc}
|
|
70
|
134 \texttt{\_\_code meta}はContextに格納されているCodeGearの配列からCodeGearのアドレスを取得し継続する。
|
|
|
135 この際に配列の要素を特定する際に使われる添え字は、 各CodeGearに割り振られた番号を利用している。
|
|
|
136 この番号はC言語の列挙体を使用した\texttt{enum Code}型で定義されている。
|
|
72
|
137 \texttt{enum Code}型の定義をソースコード\ref{src:enumCode}に示す。
|
|
|
138 命名規則は\texttt{C\_CodeGearName}となっている。
|
|
|
139 \lstinputlisting[label=src:enumCode, caption=CodeGearの番号であるenumCodeの定義]{src/enumCode.h}
|
|
70
|
140 \texttt{enum Code}型はGearsOSのコンパイル時に利用されているCodeGearを数え上げて生成される。
|
|
146
|
141 その為計算で使用されるCodeGearには一意に番号が振り付けられる。
|
|
|
142 この番号は呼び出すContextなどによらず、 GearsOS内で不変の値となっている。
|
|
72
|
143 Contextのcode配列には、各CodeGearのStubCodeGearの関数ポインタが配置されている。
|
|
|
144 よって\texttt{\_\_code meta}から継続する先のCodeGearは、呼び出し先のCodeGearの直前に実行されるStubCodeGearになる。
|
|
70
|
145
|
|
|
146 CodeGearからCodeGearへの継続は、関数型プログラミングの継続先に渡すDataとCodeの組のClosureとなっている。
|
|
|
147 シンタックスでは継続の際に引数\texttt{(...)}を渡す。
|
|
|
148 これは処理系では特に使用していないキーワードであるが、 このClosureを持ち歩いていることを意識するために導入されている。
|
|
|
149
|
|
|
150
|
|
|
151
|
|
66
|
152 \section{TaskManager}
|
|
73
|
153 TaskManagerはGearsOS上で実行されるTaskの管理を行う。
|
|
|
154 GearsOS上のTaskとはContextのことであり、 各Contextには自分の計算に必要なDataGearのカウンタなどが含まれている。
|
|
|
155 TaskManagerは、CodeGearの計算に必要な入力のDataGear(InputDataGear)が揃っているかの確認、揃っていなかったら待ち合わせを行う処理がある。
|
|
|
156 すべてのDataGearが揃った場合、 TaskをWorkerのQueueに通知しTaskを実行させる。
|
|
|
157 この処理はGearsOSを並列実行させる場合に必要な機能となっている。
|
|
|
158
|
|
66
|
159 TaskManagerは性質上シングルトンである。
|
|
|
160 その為、複数Workerを走らせた場合でも1全体で1つのみの値を持っていたいものはTaskManagerが握っている必要がある。
|
|
|
161 例えばモデル検査用の状態保存用のデータベース情報は、 TaskManagerが所有している。
|
|
|
162
|
|
73
|
163 \section{TaskQueue}
|
|
|
164 GearsOSのTaskQueueはSynchronizedQueueで表現されている。
|
|
|
165 TaskQueueはWorkerが利用するQueueとなっている。
|
|
|
166
|
|
|
167 WorkerのQueueは、TaskManagerに接続してTaskを送信するスレッドと、 Taskを実行するWorker自身のスレッドで扱われる。
|
|
|
168 さらにWorkerが複数走る可能性もある。
|
|
|
169 その為SynchronizedQueueは、マルチスレッドでもデータの一貫性を保証する必要がある。
|
|
|
170 GearsOSではCAS(Check and Set, Compare and Swap)を利用して実装が行われている。
|
|
|
171
|
|
66
|
172 \section{Worker}
|
|
|
173 WorkerはWorkerの初期化にスレッドを作る。
|
|
|
174 GearsOSではスレッドごとにそれぞれContextが生成される。
|
|
|
175 Workerはスレッド作製後にContextの初期化APIを呼び出し、自分のフィールドにContextのアドレスを書き込む。
|
|
|
176
|
|
|
177 スレッド作製後はTaskManagerからTaskを取得する。
|
|
|
178 TaskはContextの形で表現されているために、WorkerのContextをTaskに切り替え、 Taskの次の継続に実行する。
|
|
|
179 OutputDataGearがある場合は、Task実行後にDataGearの書き出しが行われる。
|
|
|
180
|
|
|
181 WorkerはCodeGearの前後で確実に呼び出される。
|
|
|
182 この性質を利用すると、 CodeGearの実行の前後での状態を記録することが可能である。
|
|
|
183 つまりモデル検査が可能である為、モデル検査用のWorkerを定義して入れ替えるとコードに変更を与えずに実行できる。
|
|
|
184 Worker自体はInterfaceで表現されているために、入れ替えは容易となっている。
|
|
|
185 GearsOSでは通常のWorkerとしてCPUWorkerを、GPUに関連した処理をするCUDAWorker、合間にモデル検査関連のメタ計算をはさむMCWorkerが定義されている。
|
|
61
|
186 \section{union Data型}
|
|
|
187
|
|
68
|
188 CbC/GearsOSではDataGearは構造体の形で表現されていた。
|
|
|
189 すべてのDataGearを管理する、Contextは計算で使うすべてのDataGearの型定義を持っている。
|
|
|
190 各DataGearは当然ではあるが別の型である。
|
|
|
191 例えばStack DataGearとQueue DataGearは、それぞれstruct Stackとstruct Queueで表現されるが、 C言語のシステム上別の型とみなされる。
|
|
152
|
192 メタレベルで見れば、 これらDataGearの型はcontext.hの中に構造体の形で型定義されている。
|
|
|
193 Contextはこれらの型をすべてDataGearとして等しく扱う必要がある。
|
|
68
|
194 この為にC言語の共用体を使用し、汎用的なDataGearの型であるunion Data型を定義している。
|
|
152
|
195 すべてのDataGearの型定義は、このunion Data型の中で定義されている。
|
|
68
|
196 共用体とは、構成するメンバ変数で最大の型のメモリサイズと同じメモリサイズになる特徴があり、複数の異なる型をまとめて管理することができる。
|
|
61
|
197 構造体と違い、1度に一つの型しか使うことができない。
|
|
|
198
|
|
|
199
|
|
68
|
200 実際にどの型が書き込まれているかは、 Contextのどこに書き込まれているかによって確認の方法が異なる。
|
|
|
201 Interfaceの入出力で利用しているdata配列の場合は、enumの番号とdata配列の添え字が対応している。
|
|
|
202 このためenumで指定した場所に入っているunion Dataの具体的な型は、 enumと対応するDataGearになる。
|
|
|
203 contextのヒープにアロケートされたDataGearの場合は、 型情報を取得できるMetaDataGearにアクセスすると、なんの型であったかが分かる。
|
|
60
|
204
|
|
71
|
205 Contextから取り出してきたunion DataからDataGearの型への変換はメタ計算で行われる。
|
|
68
|
206 GearsOSの場合は、計算したいCodeGearの直前で実行されるStubCodeGearで値のキャストが行われる。
|
|
73
|
207
|
|
|
208 \section{Interface}
|
|
|
209 GearsOSのモジュール化の仕組みとしてInterfaceがある。
|
|
|
210 InterfaceはCodeGearと各CodeGearで使う入出力のDataGearの集合である。
|
|
|
211 Interfaceに定義されているCodeGearは、各Interfaceが満たすこと期待するAPIである。
|
|
|
212
|
|
|
213 Intefaceは仕様(Interface)と、実装(Implement, Impl)を別けて記述する。
|
|
|
214 Interfaceを呼び出す場合は、Interfaceに定義されたAPIに沿ってプログラミングをすることで、Implの内容を隠蔽することができる。
|
|
|
215 これによってメタ計算部分で実装を入れ替えつつInterfaceを使用したり、 ふるまいを変更することなく具体的な処理の内容のみを変更することが容易にできる。
|
|
|
216 これはJavaのInterface、Haskellの型クラスに相当する機能である。
|
|
74
|
217
|
|
|
218 \subsection{Interfaceの定義}
|
|
|
219 GearsOSに実装されているQueueのInterfaceの定義をソースコード\ref{src:queue}に示す。
|
|
|
220 \lstinputlisting[label=src:queue, caption=QueueのInterface]{src/queue.h}
|
|
|
221 Interfaceの定義は、前半に入出力で利用するDataGearを列挙する。
|
|
|
222 ここでは\texttt{queue}と\texttt{data}を利用する。
|
|
|
223 4行目からはAPIの宣言である。
|
|
|
224 各APIはCodeGearであるので\texttt{\_\_code}で宣言する。
|
|
|
225 各CodeGearの第1引数は\texttt{Impl*}型の変数になっている。
|
|
|
226 これはInterfaceと対応するImplementのDataGearのポインタである。
|
|
|
227 Javaなどのオブジェクト指向言語ではselfやthisのキーワードで参照できるものとほぼ等しい。
|
|
|
228 Interface宣言時には具体的にどの型が来るかは不定であるため、 キーワードを利用している。
|
|
|
229 ImplはInterfaceのAPI呼び出し時に、メタレベルの処理であるStubCodeGearで自動で入力される。
|
|
|
230 その為ユーザーはInterfaceのAPIを呼び出す際は、 このImplに対応する引数は設定しない。
|
|
155
|
231 すなわち実際に設定すべき引数は、 Implを抜いたものになる。
|
|
74
|
232
|
|
|
233 第1引数にImplが来ないCodeGearとして\texttt{whenEmpty}と\texttt{next}がQueueの例で存在している。
|
|
|
234 これらはAPIの呼び出し時に継続として渡されるCodeGearであるため、 Interfaceの定義時には不定である。
|
|
152
|
235 GearsOSはCbCで実装されているため、 goto文で継続してきた場合、次の継続に使われる引数はスタック以外の場所から取り出す必要がある。
|
|
|
236 \texttt{...}を用いて、不定なCodeGearとDataGearの組であるClosureが来ると仮定している。
|
|
|
237 このClosureは実際にはContextであり、 GearsOSがContextからすべての値を取り出していることを意味している。
|
|
74
|
238 8行目で定義している\texttt{whenEmpty}はQueueの状態を確認し、空でなければ\texttt{next}、空であれば\texttt{whenEmpty}に継続する。
|
|
|
239 これらは呼び出し時にCodeGearを入力して与えることになる。
|
|
|
240
|
|
73
|
241
|
|
74
|
242 \subsection{Interfaceの呼び出し}
|
|
|
243 Interfaceで定義したAPIは\texttt{interface->method}の記法で呼びだすことが可能である。
|
|
|
244 ソースコード\ref{src:queueTake}では、 Queue Interfaceのtake APIを呼び出している。
|
|
|
245 takeは\texttt{\_\_code next}を要求しているので、 CodeGearの名前を引数として渡している。
|
|
|
246 これはノーマルレベルではenumの番号として処理される。
|
|
|
247 takeは出力を1つ出すCodeGearである為、継続で渡された\texttt{odgCommitCUDAWorker4}はStubでこの出力を受け取る。
|
|
|
248 \lstinputlisting[label=src:queueTake, caption=InterfaceのAPIの呼び出し]{src/queueTake.cbc}
|
|
|
249
|
|
77
|
250 また、Interfaceを利用する場合はソースコード中に\texttt{\#interface "interfaceName.h"}と記述する必要がある。
|
|
|
251 例えばQueueを利用する場合は\texttt{\#interface "Queue.h"}と記述しなければならない。
|
|
|
252 \texttt{\#interface}構文は、一見するとC言語のマクロの様に見える。
|
|
|
253 実際にはマクロではなく、 Perlスクリプトによってメタレベルの情報を含むCbCファイルに変換する際に、 Perlスクリプトに使っているInterfaceを教えるアノテーションの様な役割である。
|
|
|
254 Perlスクリプトによって変換時に、 \texttt{\#interface}の宣言は削除される。
|
|
76
|
255
|
|
74
|
256 \subsection{Interfaceのメタレベルの実装}
|
|
|
257 Interface自身もDataGearであり、実際の定義はcontextのunion Data型に記述されている。
|
|
|
258 メタレベルではIntefaceのDataGearのGearsOS上の実装である構造体自身にアクセス可能である。
|
|
|
259 Queue Interfaceに対応する構造体の定義をソースコード\ref{src:queueStruct}に示す。
|
|
|
260 \lstinputlisting[label=src:queueStruct, caption=QueueのInterfaceに対応する構造体]{src/queueStruct.h}
|
|
|
261
|
|
|
262 Interfaceの実装は、この構造体に代入されている値で表現される。
|
|
|
263 Interfaceの定義(ソースコード\ref{src:queue})と、 実際の構造体(ソースコード\ref{src:queueStruct})を見比べると、 CodeGearは\texttt{enum Code}として表現し直されている。
|
|
|
264 \texttt{enum Code}はGearsOSで使うすべてのCodeGearに割り振られた番号である。
|
|
|
265 InterfaceはAPIに対応するenum Codeに、Impl側のenumCodeを代入することで、実装を表現している。
|
|
|
266 InterfaceのImpl側のDataGearは、 各Interfaceに存在する、Interface名の最初の一文字が小文字になったunion Data型のポインタ経由で取得可能である。
|
|
|
267
|
|
|
268 \subsection{InterfaceのImplの実装}
|
|
|
269 実際にInterfaceの初期化をしている箇所を確認する。
|
|
|
270 Queue Interfaceに対応するSingleLinkedQueueの実装を\ref{src:SingleLinkedQueueOld}に示す。
|
|
73
|
271 \lstinputlisting[label=src:SingleLinkedQueueOld, caption=SingleLinkedQueueの実装]{src/SingleLinkedQueueOld.cbc}
|
|
|
272
|
|
77
|
273 Interfaceの実装の場合も、 Interface呼び出しのAPIである\texttt{\#interface "Queue.h"}を記述する必要がある。
|
|
74
|
274 \texttt{createSingleLinkedQueue}はSingleLinkedQueueで実装したQueue Interfaceのコンストラクタである。
|
|
|
275 これは関数呼び出しで実装されており、 返り値はInterfaceのポインタである。
|
|
|
276 コンストラクタ内ではQueueおよびSingleLinkedQueueのアロケーションを行っている。
|
|
|
277 \texttt{new}演算子が使われているが、 これはGearsOSで拡張されたシンタックスの1つである。
|
|
|
278 newはGearsOSのビルド時にPerlスクリプトによって、contextが持つDataGearのヒープ領域の操作のマクロに切り替わる。
|
|
|
279 ノーマルレベルではcontextにアクセスできないので、 Javaの様なアロケーションのシンタックスを導入している。
|
|
|
280
|
|
76
|
281 \subsection{goto時のContextとInterfaceの関係}
|
|
|
282 Interfaceはモジュール化の仕組みとしてでなく、 メタレベルでは一時的な変数の置き場所としても利用している。
|
|
155
|
283 ソースコード\ref{src:queueTake}で呼び出しているtakeは、 OutputDataGearが存在するAPIである。
|
|
76
|
284 このOutputDataGearは、 context内のDataGearの置き場所であるdata配列の、 Interfaceのデータ格納場所に書き込まれる。
|
|
|
285 OutputDataGearを取得する場合は、 継続先でなく、APIのInterfaceから取得しないといけない。
|
|
73
|
286
|
|
76
|
287 また、goto文で別のCodeGearに遷移する際も、引数情報を継続先のcontextのdata配列の場所に書き込む必要がある。
|
|
|
288 この処理はメタレベルの計算であるため、 GearsOSのビルド時にPerlで変換される。
|
|
|
289 ソースコード\ref{src:takeStub}にソースコード\ref{src:queueTake}の変換結果を示す。
|
|
|
290 この例ではStubCodeGearのディスパッチを行う\texttt{\_\_code meta}へのgotoの前に、Gearefマクロを使ったcontextへの書き戻しが行われている。
|
|
|
291 GearsOSはCbCを用いて実装している為、スタックを持っていない。
|
|
|
292 その為都度データはContextに書き戻す必要があるが、データの一時保管場所としても利用されている。
|
|
|
293 \lstinputlisting[label=src:takeStub, caption=takeを呼び出す部分の変換後]{src/queueTakeStub.cbc}
|
|
|
294 この性質からInterfaceには、Interfaceを実装するDataGearが持っておきたい変数はいれてはいけない。
|
|
|
295 例えばQueueの実装では先頭要素を指し示す情報が必要であるが、 これをInterface側のDataGearにしてしまうと、 呼び出し時に毎回更新されてしまう。
|
|
|
296 常に持っておきたい値は、 Impl側のDataGearの要素として定義する必要がある。
|
|
73
|
297
|
|
100
|
298 \subsection{Stack.Stack-{\textgreater}Stack.stack}
|
|
|
299 Contextのデータ保管場所について確認する。
|
|
101
|
300 ここではソースコード\ref{src:StackStackCbC}を実行する際に、 Contextが持つ引数保管場所がどのような値になるかを見る。
|
|
|
301 \lstinputlisting[label=src:StackStackCbC, caption=Contextの引数格納用の場所の確認の例題]{src/stackStackcbc.cbc}
|
|
100
|
302
|
|
|
303 ソースコード\ref{src:StackStack1}の1行目で作製したStackTest Interfaceのアドレスは、 3行目の出力である\texttt{0x7fff2f806b50}である。
|
|
|
304 Interfaceが持つ実装へのポインタは、 5行目の先頭のstackTestに代入されている値である\texttt{0x7fff2f806bb8}となっている。
|
|
|
305 \lstinputlisting[label=src:StackStack1, caption=gdbを使って作製したInterfaceのアドレスを確認する]{src/stackStack1.sh}
|
|
|
306
|
|
|
307 ソースコード\ref{src:StackStack2}の行を実行し、 contextの引数格納用の場所にInterfaceのアドレスを書き込む。
|
|
|
308 \lstinputlisting[label=src:StackStack2, caption=contextの引数格納用の場所に代入]{src/stackStack2.sh}
|
|
|
309 ソースコード\ref{src:StackStack3}では、 引数格納用の場所の値を確認する。
|
|
156
|
310 これはunion Data型であるので、StackTest型を指定して確認する(4行目)。
|
|
100
|
311
|
|
156
|
312 出力結果のstackTestの値は\texttt{0x7fff2f806b50}である(4行目、8行目)。
|
|
100
|
313 この値はInterfaceのアドレスと一致している。
|
|
|
314 \lstinputlisting[label=src:StackStack3, caption=contextの引数格納用の場所の値を確認]{src/stackStack3.sh}
|
|
|
315
|
|
|
316
|
|
156
|
317 ソースコード\ref{src:StackStack4}で続けてstackTestフィールドが指すunion DataのポインタをStackTest型として指定し値を確認する(1行目)。
|
|
100
|
318 2行目で表示されているstackTestフィールドの値は、StackInterfaceが持つ実装へのアドレスと一致している。
|
|
|
319 CbC上では5行目のように、ドットでフィールドを指定すると値が取れる。
|
|
|
320 \lstinputlisting[label=src:StackStack4, caption=contextのdata配列からInterfaceを取り出す]{src/stackStack4.sh}
|
|
|
321 この状況を纏めると、図\ref{fig:stackstackstackstack}のようになる。
|
|
|
322 Contextの引数格納用の場所は、最初はその型のInterfaceへのポインタが、Interfaceが通常実装へのポインタを指すフィールドに書き込まれる。
|
|
146
|
323 この様にメタレベルで見ると実装を取り出すまでに煩雑な記述が必要となる。
|
|
|
324 現在はInterfaceを取り出す\texttt{Gearef}や、Interfaceが持つ実装を取得する\texttt{GearImpl}などのマクロで簡略化している。
|
|
|
325 しかしlldbなどのデバッガでメタレベルのデバッグをする際は、マクロ展開が使えないために、手動で煩雑な記述を入力する必要がある。
|
|
101
|
326 これはGearsOSではStack.stack-{\textgreater}Stack.stack問題と言われている。
|
|
100
|
327
|
|
|
328
|
|
|
329 \begin{figure}[ht]
|
|
|
330 \begin{center}
|
|
|
331 \includegraphics[width=120mm]{drawio/stackstackstackstack.pdf}
|
|
|
332 \end{center}
|
|
|
333 \caption{Stack.stack-{\textgreater}Stack.stack}
|
|
|
334 \label{fig:stackstackstackstack}
|
|
|
335 \end{figure}
|
|
|
336
|
|
90
|
337 \section{par goto}
|
|
99
|
338 \texttt{par goto}とはGearsOSの並列処理用の構文である。
|
|
|
339 ソースコード\ref{src:twice}では、 配列を初期化するcreateArray、 配列要素を2倍するtwice、 配列の状況を出力するprintArrayを並列で動作させている。
|
|
|
340 par gotoした処理がそれぞれ終了すると、 code2に継続する。
|
|
|
341 \lstinputlisting[label=src:twice, caption=par gotoの呼び出し]{src/twiceNormal.cbc}
|
|
|
342
|
|
|
343 GearsOSで並列処理をする場合、 Contextの複製などのメタレベルの計算を多数行わなければならない。
|
|
|
344 ノーマルレベルからは通常のgoto文のように記述可能な構文を導入し、 メタレベルとの分離を行っている。
|
|
|
345 メタレベルに変換された結果をソースコード\ref{src:twiceMeta}に示す。
|
|
|
346 \texttt{par goto}でCodeGearへの継続を指定すると、\texttt{par goto}の数に応じてContextが生成される。
|
|
|
347 CodeGearの実行は、割り当てられたContextが担当する。
|
|
|
348 作製されたContextは一度大本のContextのtaskフィールドにアドレスが書き込まれ、初期化が行われる。
|
|
|
349 InputDataGearとOutputDataGearのQueueの用意を行った後に、contextのTaskListにElement 各DataGearは構造体の形で表現されている。
|
|
|
350 Elementはリスト構造を作製する際に使われるデータ構造で、 次のElementを取得できる。
|
|
|
351
|
|
|
352 各CodeGearは入力のDataGearであるInputDataGearの依存関係が解決したら実行され、OutputDataGearの状況をTaskManagerに通知するようになっている。
|
|
|
353 par gotoの場合はTaskManager関係のメタ計算を挟む必要があるため、 通常のgoto metaではなく、初回はgoto parGotoMetaが実行される。
|
|
|
354 \lstinputlisting[label=src:twiceMeta, caption=par gotoのメタレベル計算]{src/twiceMeta.c}
|
|
90
|
355
|
|
34
|
356 \section{GearsOSのビルドシステム}
|
|
|
357 GearsOSではビルドツールにCMakeを利用している。
|
|
35
|
358 ビルドフローを図\ref{fig:gearsbuild1}に示す。
|
|
34
|
359 CMakeはautomakeなどのMakeファイルを作成するツールに相当するものである。
|
|
70
|
360 GearsOSでプログラミングする際は、ビルドしたいプロジェクトで利用するソースコード群をCMakeの設定ファイルであるCMakeLists.txtに記述する。
|
|
|
361 CMakeLists.txtではGearsOSのビルドに必要な一連の処理をマクロ\texttt{GearsCommand}で制御している。
|
|
|
362 このマクロにプロジェクト名を\texttt{TARGET}として、 コンパイルしたいファイルを\texttt{SOURCES}に記述する。
|
|
|
363 ソースコード\ref{src:cmakeGearsMacro}の例では\texttt{pop\_and\_push}が\texttt{TARGET}に指定されている。
|
|
|
364 なおヘッダファイルは\texttt{SOURCES}に指定する必要はなく、 自動で解決される。
|
|
|
365
|
|
|
366 CMake自身はコンパイルに必要なコマンドを実行することはなく、ビルドツールであるmakeやninja-buildに処理を移譲している。
|
|
|
367 CMakeはmakeやninja-buildが実行時に必要とするファイルであるMakefile、 build.ninjaの生成までを担当する。
|
|
155
|
368 \lstinputlisting[label=src:cmakeGearsMacro, caption=CMakeLists.txt内でのプロジェクト定義]{src/GearsMacroCMake.txt}
|
|
34
|
369
|
|
|
370
|
|
35
|
371 GearsOSのビルドでは直接CbCコンパイラがソースコードをコンパイルすることはなく、 間にPerlスクリプトが2種類実行される。
|
|
|
372 Perlスクリプトはビルド対象のGearsOSで拡張されたCbCファイルを、純粋なCbCファイルに変換する。
|
|
|
373 ほかにGearsOSで動作する例題ごとに必要な初期化関数なども生成する。
|
|
|
374 Perlスクリプトで変換されたCbCファイルなどをもとにCbCコンパイラがコンパイルを行う。
|
|
|
375 ビルドの処理は自動化されており、 CMake経由でmakeやninjaコマンドを用いてビルドする。
|
|
|
376
|
|
60
|
377 \begin{figure}[h]
|
|
34
|
378 \begin{center}
|
|
60
|
379 \includegraphics[width=150mm]{drawio/geasflow1.pdf}
|
|
34
|
380 \end{center}
|
|
|
381 \caption{GearsOSのビルドフロー}
|
|
|
382 \label{fig:gearsbuild1}
|
|
61
|
383 \end{figure}
|
|
|
384
|
|
|
385
|
|
34
|
386
|
|
60
|
387 \section{GearsOSのCbCから純粋なCbCへの変換}
|
|
|
388 GearsOSはCbCを拡張した言語となっている。
|
|
|
389 ただしこの拡張自体はCbCコンパイラであるgcc、 llvm/clangには搭載されていない。
|
|
|
390 その為GearsOSの拡張部分を、等価な純粋なCbCの記述に変換する必要がある。
|
|
|
391 現在のGearsOSでは、 CMakeによるコンパイル時にPerlで記述された\texttt{generate\_stub.pl}と\texttt{generate\_context.pl}の2種類のスクリプトで変換される。
|
|
|
392
|
|
76
|
393 これらのPerlスクリプトはプログラマが自分で動かすことはない。
|
|
151
|
394 Perlスクリプトの実行手順はCMakeLists.txtに記述しており、 makeやninja-buildでのビルド時に呼び出される(ソースコード \ref{src:cmake1})。
|
|
76
|
395
|
|
155
|
396 \lstinputlisting[label=src:cmake1, caption=CMakeLists.txt内でのPerlの実行部分]{src/cmakefile.1.txt}
|
|
76
|
397
|
|
150
|
398 従来のGearsOSではPerlスクリプトを利用した変換時には、厳格なエラーチェックを行っていなかった。
|
|
|
399 例えばContextへの値の代入の式が正常に生成できなくても、 Perlスクリプトは正常に動作を終了したことにしてしまう。
|
|
|
400 その為従来のGearsOSでのプログラミングの場合は、 変換された後のCbCソースコードをCbCコンパイラがコンパイルした際に初めてエラーが発覚する様に実装されていた。
|
|
|
401
|
|
60
|
402 \section{generate\_stub.pl}
|
|
|
403 generate\_stub.plは各CbCファイルごとに呼び出される。
|
|
77
|
404 図\ref{fig:generate_stub_pl_1}にgenerate\_stub.plを使った処理の概要を示す。
|
|
|
405 ユーザーが記述したGearsOSのCbCファイルは、 ノーマルレベルのコードである。
|
|
|
406 generate\_stub.plは、 CbCファイルにメタレベルの情報を付け加え、GearsOSの拡張構文を取り除いた結果のCbCファイルを新たに生成する。
|
|
|
407 返還前のGearsOSのファイルの拡張子は.cbcであるが、 generate\_stub.plによって変換されると、 同名で拡張子のみ.cに切り替わったファイルが生成される。
|
|
|
408 拡張子は.cであるが、中身はCbCで記述されている。
|
|
91
|
409 generate\_stub.plはあるプログラムのソースコードから別のプログラムのソースコードを生成するトランスパイラとして見ることができる。
|
|
77
|
410
|
|
60
|
411
|
|
|
412 \begin{figure}[h]
|
|
|
413 \begin{center}
|
|
|
414 \includegraphics[width=160mm]{drawio/gears_os_build_flow.pdf}
|
|
|
415 \end{center}
|
|
|
416 \caption{generate\_sub.plを使ったトランスコンパイル}
|
|
|
417 \label{fig:generate_stub_pl_1}
|
|
|
418 \end{figure}
|
|
|
419
|
|
77
|
420 generate\_stub.plはGearsOSのソースコードを2回読む。
|
|
152
|
421 1度目の読み込みは関数getDataGearが担当する(図\ref{fig:aboutDataGear})。
|
|
91
|
422 ソースコード中に登場するCodeGearと、CodeGearの入出力を検知する。
|
|
|
423 この際に\texttt{\#interface}構文でInterfaceの利用が確認された場合、 Interfaceの定義ファイルを開き、getDataGearをさらに呼び出す。
|
|
|
424 これらの処理で、 1つのGearsOSのファイル自身と、 呼び出しているInterfaceの定義ファイルに実装されているCodeGearとDataGearの組を取得する。
|
|
|
425 データの収集は、入力で与えられたファイルを1行ずつ読み込み、 あらかじめ設定した正規表現にパターンマッチすることで処理を行っている。
|
|
|
426 ソースコード\ref{src:generateExampleInterface}は、GearsOSのソースコード中でInterfaceの使用宣言部分のパターンマッチ処理である。
|
|
155
|
427 \lstinputlisting[label=src:generateExampleInterface, caption=Interfaceの使用宣言部分のパターンマッチ]{src/generateStubInterfaceExample.pl}
|
|
91
|
428
|
|
|
429 ここでは使用しているInterfaceの名前を変数\texttt{\$interfaceHeader}にキャプチャし、 Interfaceの読み込み処理を8行目の\texttt{includeInterface}関数で実行している。
|
|
|
430 includeInterface関数の中ではgetDataGearを呼び出し、CodeGear、DataGearの情報を取得している。
|
|
|
431
|
|
|
432
|
|
|
433 取得した情報はgenerate\_stub.plが持つ変数に書き込まれる。
|
|
|
434 この変数は主にPerlのハッシュ(連想配列)が利用される。
|
|
|
435
|
|
|
436
|
|
|
437 \begin{figure}[h]
|
|
|
438 \begin{center}
|
|
|
439 \includegraphics[width=120mm]{drawio/getDataGearAbout.pdf}
|
|
|
440 \end{center}
|
|
|
441 \caption{getDataGearの処理の概要}
|
|
|
442 \label{fig:aboutDataGear}
|
|
|
443 \end{figure}
|
|
77
|
444
|
|
|
445 1度ファイルを完全に読み込み、 CodeGear、DataGearの情報を取得し終わると、以降はその情報をもとに変換したファイルを書き出す。
|
|
152
|
446 この書き出しはgenerateDataGear関数で行われる(図\ref{fig:aboutgenerateDataGear})。
|
|
77
|
447 ファイルを書き出す際は、 元のCbCファイルを再読み込みし、 変換する必要があるキーワードが出現するまでは、変換後のファイルに転記を行う。
|
|
|
448 例えば各CodeGearの最後に実行される\texttt{goto}文は、 GearsOSの場合はMetaCodeGearに継続するように、 対象を切り替える必要がある。
|
|
|
449 この為にgenerate\_stub.plは、goto文を検知するとcontext経由で引数のやりとりをするメタ処理を付け加える。
|
|
|
450 また、すべてのCodeGearはcontextを入力として受け取る必要があるため、 引数を書き換えてContextを付け加えている。
|
|
|
451
|
|
93
|
452 \begin{figure}[h]
|
|
|
453 \begin{center}
|
|
|
454 \includegraphics[width=130mm]{drawio/generateDataGearAbout.pdf}
|
|
|
455 \end{center}
|
|
|
456 \caption{generateDataGearの処理の概要}
|
|
|
457 \label{fig:aboutgenerateDataGear}
|
|
|
458 \end{figure}
|
|
|
459
|
|
|
460
|
|
91
|
461 generate\_stub.plはPerlで書かれたトランスパイラであり、 C言語のコンパイラのように文字列を字句解析、構文解析をする訳ではない。
|
|
77
|
462 いくつかあらかじめ定義した正規表現パターンに読み込んでいるCbCファイルの行がパターンマッチされたら、 特定の処理をする様に実装されている。
|
|
|
463
|
|
|
464 CodeGearの入力をcontextから取り出すStubCodeGearの生成もgenerate\_stub.plで行う。
|
|
|
465 なおすでにStubCodeGearが実装されていた場合は、 generate\_stub.plはStubCodeGearは生成しない。
|
|
|
466
|
|
|
467
|
|
|
468
|
|
60
|
469 \section{generate\_context.pl}
|
|
76
|
470 generate\_context.plは、Contextの初期化関連のファイルを生成するPerlスクリプトである。
|
|
|
471 Contextを初期化するためには、下記の処理をしなければならない。
|
|
60
|
472
|
|
|
473 \begin{itemize}
|
|
76
|
474 \item CodeGearのリストにStubCodeGearのアドレスの代入
|
|
|
475 \item goto meta時に引数を格納するdata配列のアロケーション
|
|
|
476 \item 計算で使用するすべてのDataGear、CodeGearに対して番号を割り振り、 enumを作製する
|
|
|
477 \item コンストラクタ関数のexternの生成
|
|
60
|
478 \end{itemize}
|
|
|
479
|
|
76
|
480 これらの記述は煩雑であるものの、CbCファイルとDataGearの情報が纏められたcontext.hを見れば、記述すべき内容は一意に決定でき為、自動化が可能である。
|
|
|
481 generate\_context.plは、 context.hを読み、まずDataGearの取得を行う。
|
|
|
482 CodeGearは、generate\_stub.plで変換されたCbCファイルを読み込み、 \texttt{\_\_code}があるものをCodeGearとして判断する。
|
|
|
483 また、Cの一般関数でも\texttt{create}が関数名に含まれており、 ポインタ型を返す関数はInterfaceのコンストラクタとして判断する。
|
|
|
484 これらの情報をもとに、 CodeGear、DataGearの番号を作製し、enumCode.hとenumData.hとして書き出す。
|
|
60
|
485
|
|
76
|
486
|
|
60
|
487
|
|
|
488 \begin{figure}[h]
|
|
|
489 \begin{center}
|
|
76
|
490 \includegraphics[width=90mm]{drawio/old_generate_context.pdf}
|
|
60
|
491 \end{center}
|
|
|
492 \caption{generate\_context.plを使ったファイル生成}
|
|
|
493 \label{fig:generate_context_1}
|
|
|
494 \end{figure}
|
|
|
495
|
|
|
496
|
|
|
497
|
|
57
|
498 \section{CbC xv6}
|
|
142
|
499 CbC xv6はGearsOSのシステムを利用してxv6 OSの置き換えを目指しているプロジェクト\cite{cbcxv6repo}である。
|
|
57
|
500 xv6はv6 OS\cite{lions1996lions}をx86アーキテクチャ用にMITによって実装し直されたものである。
|
|
142
|
501 Raspberry Pi上での動作を目指しているため、 ARMアーキテクチャ用に改良されたバージョン\cite{xv6rpi}を利用している。
|
|
57
|
502
|
|
|
503 書き換えにおいてはビルドシステムはCMakeを利用し、 Perlクロスコンパイラを導入してたりとGearsOSのビルドシステムとほぼ同じシステムを利用している。
|
|
|
504 GearsOSを使った比較的巨大な実用的なアプリケーションであるため、 xv6の書き換えを進むに連れて様々な面で必要な機能や課題が生まれている。
|
|
91
|
505
|
|
|
506 従来の研究ではxv6はCMakeを使わずにMakeを用いてクロスコンパイルしていた。
|
|
|
507 現在はxv6にGearsOSのCMakeを使ったビルドシステムを導入している。
|
|
|
508 ARM用のバイナリが出力できるCbCコンパイラがある場合、x86マシンからCMakeを利用してクロスコンパイル可能となっている。
|
|
|
509
|
|
|
510 CMakeを導入したことでGearsOSの拡張構文が使えるようになった。
|
|
70
|
511 xv6はUNIX OSである為プロセス単位で処理を行っていたが、 ここに部分的にContextを導入した。
|
|
|
512 xv6では割り込みのフラグなどを大域変数として使っていた。
|
|
|
513 GearsOSで実装する場合はDataGear単位になるため、 これらのフラグもDataGearの形で実装し直した。
|
|
|
514 このDataGearは各プロセスに対応するContextではなく、 中心的なContextがシングルトンで持っている必要がある。
|
|
|
515 CbCxv6の実装を通してKernelの状況を記録しておくContext、つまりKernelContextが必要であることなどが判明した。
|
|
|
516
|
|
57
|
517 \section{ARM用ビルドシステムの作製}
|
|
33
|
518 GearsOSをビルドする場合は、x86アーキテクチャのマシンからビルドするのが殆どである。
|
|
|
519 この場合ビルドしたバイナリはx86向けのバイナリとなる。
|
|
|
520 これはビルドをするホストマシンに導入されているCbCコンパイラがx86アーキテクチャ向けにビルドされたものである為である。
|
|
|
521
|
|
|
522 CbCコンパイラはGCCとllvm/clang上に構築した2種類が主力な処理系である。
|
|
|
523 LVM/clangの場合はLLVM側でターゲットアーキテクチャを選択することが可能である。
|
|
153
|
524 GCCの場合は最初からターゲットアーキテクチャを指定してコンパイラをビルドする必要がある。
|
|
33
|
525
|
|
|
526 時にマシンスペックの問題などから、 別のアーキテクチャ向けのバイナリを生成したいケースがある。
|
|
|
527 教育用マイコンボードであるRaspberry Pi\cite{rpi}はARMアーキテクチャが搭載されている。
|
|
|
528 Raspberry Pi上でGearsOSのビルドをする場合、 ARM用にビルドされたCbCコンパイラが必要となる。
|
|
|
529 Raspberry Pi自体は非力なマシンであるため、 GearsOSのビルドはもとよりCbCコンパイラの構築をRaspberry Pi上でするのは困難である。
|
|
|
530 マシンスペックが高めのx86マシンからARM用のバイナリをビルドして、 Raspberry Piに転送し実行したい。
|
|
|
531 ホストマシンのアーキテクチャ以外のアーキテクチャ向けにコンパイルすることをクロスコンパイルと呼ぶ。
|
|
|
532
|
|
|
533
|
|
58
|
534 GearsOSはビルドツールにCMakeを利用しているので、 CMakeでクロスコンパイル可能に工夫をしなければならない。
|
|
35
|
535 ビルドに使用するコンパイラやリンカはCMakeが自動探索し、 決定した上でMakefileやbuild.ninjaファイルを生成する。
|
|
33
|
536 しかしCMakeは今ビルドしようとしている対象が、自分が動作しているアーキテクチャかそうでないか、クロスコンパイラとして使えるかなどはチェックしない。
|
|
|
537 つまりCMakeが自動でクロスコンパイル対応のGCCコンパイラを探すことはない。
|
|
|
538 その為そのままビルドするとx86用のバイナリが生成されてしまう。
|
|
|
539
|
|
|
540
|
|
|
541 CMakeを利用してクロスコンパイルする場合、CMakeの実行時に引数でクロスコンパイラを明示的に指定する必要がある。
|
|
|
542 この場合x86のマシンからARMのバイナリを出力する必要があり、 コンパイラやリンカーなどをARMのクロスコンパイル対応のものに指定する必要がある。
|
|
|
543 また、 xv6の場合はリンク時に特定のリンカスクリプトを使う必要がある。
|
|
|
544 これらのリンカスクリプトもCMake側に、 CMakeが提供しているリンカ用の特殊変数を使って自分で組み立てて渡す必要がある。
|
|
68
|
545 CMake側に使用したいコンパイラの情報を渡せれば、以降はCMake側が自動的に適切なビルドスクリプトを生成してくれる。
|
|
33
|
546 このようなCMakeの処理を手打ちで行うことは難しいので、 \texttt{pmake.pl}を作成した。
|
|
|
547 \texttt{pmake.pl}の処理の概要を図\ref{fig:pmake}に示す。
|
|
|
548 \texttt{pmake.pl}はPerlスクリプトで、 シェルコマンドを内部で実行しクロスコンパイル用のオプションを組み立てる。
|
|
|
549 \texttt{pmake.pl}を経由してCMakeを実行すると、 makeコマンドに対応するMakefile、 ninja-buildに対応するbuild.ninjaが生成される。
|
|
|
550 以降はcmakeではなくmakeなどのビルドツールがビルドを行う。
|
|
|
551
|
|
35
|
552 \begin{figure}[h]
|
|
33
|
553 \begin{center}
|
|
|
554 \includegraphics[width=160mm]{drawio/pmake.pdf}
|
|
|
555 \end{center}
|
|
|
556 \caption{pmake.plの処理フロー}
|
|
|
557 \label{fig:pmake}
|
|
|
558 \end{figure}
|
|
|
559
|
|
61
|
560
|
|
37
|
561
|
