|
2
|
1
|
|
|
2 \chapter{GCCにおける実装・改善}
|
|
|
3 \label{chp:impl}
|
|
|
4
|
|
3
|
5 この章では、GCCにおけるCbCコンパイラの実装方法と、 \ref{chp:cbc}章で洗
|
|
|
6 い出したGCCでの問題点の改善を行う。
|
|
2
|
7
|
|
|
8 実装にはGCCのフロントエンドであるcc1というプログラムを直接変更する。
|
|
3
|
9 このcc1はCからアセンブラへ変換を行う純粋なコンパイラとして実行されるプ
|
|
|
10 ログラムである。このcc1をCbCの構文解析に対応させる。
|
|
|
11
|
|
2
|
12 過去の研究においてはGCCのバージョン4.2.3が用いられた。現在はGCCのリリ
|
|
|
13 ースに並ぶ形で4.4.2（2010年1月時）を用いている。
|
|
|
14
|
|
|
15 \section{過去の研究における実装部分}
|
|
3
|
16 今回の改善においての予備知識として、過去の研究での実装部分であるコード
|
|
2
|
17 セグメントと軽量継続がどのように実装されたかを簡単に説明する。
|
|
|
18
|
|
|
19 \subsection{コードセグメントの実装}
|
|
|
20
|
|
|
21 コードセグメント内部の実装は実際は単なる関数で良い。
|
|
|
22 変更の必要があったのは関数の返り値に当たる部分である。コードセグメント
|
|
|
23 では返り値が存在しないのでここは``code''キーワードを入力できるようにす
|
|
|
24 る。このcodeは内部でvoid型に変換する。
|
|
|
25
|
|
|
26 GCC（及び一般的なコンパイラ）ではコンパイルに必要な全ての要素、変数や式
|
|
|
27 、関数、構文などをすべて treeと呼ばれる構文木に保持している。コードセ
|
|
|
28 グメントの構文木も関数とほ
|
|
|
29 ぼ同じものを作成すれば良い。コード\ref{code:build-code-segment}はその
|
|
|
30 構文木を作成している部分である。
|
|
|
31
|
|
|
32 \lstinputlisting
|
|
|
33 [caption=構文木生成(gcc/c-typeck.c),label=code:build-code-segment]
|
|
|
34 {sources/build-code-segment.cbc}
|
|
|
35
|
|
|
36 \verb|build_code_segment_type|関数においてコードセグメントの構文木を作
|
|
|
37 成している。内部の処理は\verb|build_function_type|とほぼ同じだが、関数
|
|
|
38 のテーブルに登録せず、軽量継続の際にそれがコードセグメントであることを
|
|
|
39 示すためのフラグをセットしている。
|
|
|
40
|
|
|
41
|
|
|
42
|
|
3
|
43 \subsection{軽量継続の実装} \label{sec:impl-goto}
|
|
2
|
44 % return somesegment();
|
|
|
45 % expand_call()
|
|
|
46
|
|
|
47 軽量継続はGCCの末尾呼び出し最適化の機構を用いて実装する。
|
|
|
48
|
|
|
49 \subsubsection{末尾呼び出し最適化}
|
|
|
50 プログラム中、関数を呼び出すときには通常はスタックを積み上げ、現在の環
|
|
|
51 境を保持した上で呼び出し先の処理を行う。これは元の関数に復帰して残りの
|
|
|
52 処理を続行する必要があるためである。しかし関数の最後、リターン直前に呼
|
|
|
53 び出しを行う場合は環境を保持する必要がない（図\ref{fig:tailcall}参照）
|
|
|
54 。そのためスタックの状態を変更することなく呼び出すことができる。この最
|
|
|
55 適化は末尾呼び出し最適化(tailcall)と呼ばれている。
|
|
|
56 \begin{figure}[htpb]
|
|
|
57 \begin{center}
|
|
|
58 \includegraphics[width=.6\textwidth]{figures/tailcall.eps}
|
|
|
59 \end{center}
|
|
|
60 \caption{末尾呼び出し最適化が可能な関数funcBの例}
|
|
|
61 \label{fig:tailcall}
|
|
|
62 \end{figure}
|
|
|
63
|
|
|
64 Scheme処理系では仕様上この最適化が必須となっているが、Cはそうではない。
|
|
|
65 しかしGCCはこの最適化をデフォルトで行っている。
|
|
|
66
|
|
|
67 \subsubsection{軽量継続への摘要}
|
|
|
68 tailcallをコードセグメントの呼び出しに適用することで軽量継続が実装でき
|
|
|
69 る。具体的にはソースコード上にコード\ref{code:goto}のような式があった
|
|
|
70 場合に、これをコード\ref{code:ret-call}と同じように解釈すれば良い。
|
|
|
71 この構文解析はGCCのgcc/c-parser.c内で行う。
|
|
|
72
|
|
|
73 \begin{minipage}[t]{.45\textwidth}
|
|
|
74 \lstinputlisting[caption=goto文の例,label=code:goto]
|
|
|
75 {sources/goto-expression.cbc}
|
|
|
76 \end{minipage}
|
|
|
77 \hfill
|
|
|
78 \begin{minipage}[t]{.45\textwidth}
|
|
|
79 \lstinputlisting[caption=構文木での解釈,label=code:ret-call]
|
|
|
80 {sources/ret-call.cbc}
|
|
|
81 \end{minipage}
|
|
|
82
|
|
|
83 しかし構文木の変更だけでは最適化が行われるとは限らない。特にスタックの
|
|
|
84 状態や変数の数、順番によっても最適化はカットされる場合がある。
|
|
|
85 そのため最適化を判断する条件式を修正、また構文木から中間コードを生
|
|
|
86 成する部分でも修正が必要になる。
|
|
|
87
|
|
|
88 \paragraph{expand-call}関数は関数を表す構文木から中間コードを生成する
|
|
|
89 処理である。この関数内では呼び出される関数のアドレスを取得するコードの
|
|
|
90 生成、スタックへの引数をプッシュするコードの生成、引数のプッシュの度に
|
|
|
91 tailcallが可能かのチェックなどが行われている。
|
|
|
92
|
|
|
93 ここでは以下の処理を追加することでtailcallカットの条件判断をパスしている。
|
|
|
94 \begin{itemize}
|
|
|
95 \item スタックのサイズをごまかす
|
|
|
96
|
|
|
97 tailcallは呼び出し元の全引数サイズが呼び出し先のそれより小さい場合
|
|
|
98 には実行できない。そのため呼び出し元、この場合コードセグメント全て
|
|
|
99 の引数にもちいるスタックサイズを大きな値でごまかす。
|
|
|
100 \item 並列代入
|
|
|
101
|
|
|
102 \ref{sec:cbc-problem}で説明したような並列代入の必要な関数呼び出し
|
|
|
103 を行った場合はtailcallは実行されない。そのためここで並列代入が必要
|
|
|
104 になる。
|
|
|
105 \end{itemize}
|
|
|
106
|
|
|
107 上記処理の追加により軽量継続が実装された。
|
|
|
108 継続の際にコードセグメントに渡す引数は関数と同じようにスタック上に格納
|
|
|
109 されるが、このスタックは拡張することはなく、図
|
|
|
110 \ref{fig:gotostack}のように連続した継続の中でスタックポインタは常
|
|
|
111 に同じアドレスを指し示す。（比較のため、図\ref{fig:funcstack}には関数
|
|
|
112 呼び出しの際のスタックの状態を例示した）
|
|
|
113 \begin{figure}[htpb]
|
|
|
114 \begin{center}
|
|
|
115 \subfloat[][関数呼び出し]{\label{fig:funcstack}
|
|
|
116 \includegraphics[width=.6\textwidth]{figures/functionstack.eps}}
|
|
|
117 \subfloat[][軽量継続]{\label{fig:gotostack}
|
|
|
118 \includegraphics[width=.6\textwidth]{figures/interfacestack.eps}}
|
|
|
119 \end{center}
|
|
|
120 \caption{継続制御と関数呼び出しでのスタックの違い}
|
|
|
121 \end{figure}
|
|
|
122
|
|
|
123 しかし並列代入の処理は構造体のようにオーバラップする引数に対しては対応
|
|
|
124 しておらず、プログラムによっては引数がちゃんと渡されないなどのバグが生
|
|
|
125 じていた。
|
|
|
126
|
|
|
127
|
|
|
128 \section{問題点の改善}
|
|
|
129 ここから\ref{sec:cbc-problem}節で紹介した問題点について、本研究での改
|
|
|
130 善点を説明する。
|
|
|
131
|
|
|
132
|
|
|
133 \subsection{並列代入}\label{sec:impl-parallel}
|
|
|
134 % 一時変数を取得する例を示す
|
|
|
135 % 最適化の期待
|
|
|
136 % おい、replace_arguments関数、あんまり意味ないぞ
|
|
|
137
|
|
|
138 \ref{sec:}のコード\ref{code:}で説明した様に、コードセグメントの受け取
|
|
|
139 った引数と継続の際に渡す引数の順序が変わる場合等に並列代入が必要になる。
|
|
|
140 過去の実装ではこの並列代入を、\verb|expand_call|という構文木から中間コ
|
|
|
141 ードを生成する処理の部分で行っていた。
|
|
|
142
|
|
|
143 しかし実際にはGCCは元より並列代入を実装しているため、独自の実装は必要
|
|
|
144 としない。また、この独自の実装にも問題があった。
|
|
|
145 そのため独自の実装は廃止し、GCCの機能を利用することにする。
|
|
|
146
|
|
|
147 コード\ref{code:parallel-example2}は並列代入の必要な軽量継続の例である。
|
|
|
148 \lstinputlisting
|
|
|
149 [caption=並列代入の必要な軽量継続の例,label=code:parallel-example2]
|
|
|
150 {sources/parallel-example.cbc}
|
|
|
151
|
|
|
152 継続の引数は現在の引数と同じメモリに格納されるため、引数\verb|a|は
|
|
|
153 \verb|b|の位置に、引数\verb|b|は\verb|a|の位置に代入されることになる。
|
|
|
154 この場合に並列代入を考慮せず、順に代入すると
|
|
|
155 \begin{verbatim}
|
|
|
156 a = b;
|
|
|
157 b = a;
|
|
|
158 \end{verbatim}
|
|
|
159 となり、両方が同じ値になってしまう。
|
|
|
160 ただしこの例は極端に簡略化した例であり、この程度であればtailcallに問題
|
|
|
161 はない。しかしより複雑な並列代入では同じ問題が現れる。特に、引数に含ま
|
|
|
162 れるコードセグメントポインタへ間接継続する場合には、ほぼ確実に失敗する。
|
|
|
163
|
|
|
164 この問題の回避策として単純にコード\ref{code:avoiding-parallel}の様に変
|
|
|
165 数の値を一時変数に退避することが考えられる。
|
|
|
166
|
|
|
167 \lstinputlisting
|
|
|
168 [caption=引数の退避,label=code:avoiding-parallel]
|
|
|
169 {sources/avoiding-parallel.cbc}
|
|
|
170
|
|
|
171 こうすることで引数が一時変数に確保され、その後そこからコピーする形で所
|
|
|
172 定のメモリ位置に戻されるため問題が回避できる。今回の並列代入の改善では
|
|
|
173 この手法を用いる。
|
|
|
174
|
|
|
175 \subsubsection{問題点と最適化の期待}
|
|
|
176 この手法でどのように引数を入れ替えても正しく代入可能になる。ただし、一
|
|
|
177 時変数の使用は処理速度に問題がある。特にレジスタの少ないアーキテクチャ
|
|
|
178 では一時変数の確保にはメモリ上のスタックを用いるため、余計なメモリアク
|
|
|
179 セスや冗長な命令が増えてしまう。このため、この手法を実践したコードでは
|
|
|
180 そうでないコードに比べて若干の速度低下が見込まれる。
|
|
|
181
|
|
|
182 その代わり、この速度低下はGCCのもつ最適化機構で回避され得るものである。
|
|
|
183 GCCでは中間コード生成後、必要のない一時変数へのコピーなどは最適化によ
|
|
|
184 りカットされる。そのため、最適化を有効にした場合はこの処理速度の低下は
|
|
|
185 起きないはずである。この影響に関しては\ref{chp:eval}章にて評価を行う。
|
|
|
186
|
|
|
187 \subsubsection{一時変数への退避の実装}
|
|
|
188
|
|
|
189 この手法の実装は、中間コード生成時ではなく構文木生成で可能である。
|
|
|
190 tailcallの関数呼び出しを表す構文木の生成時に以下の処理を追加する。
|
|
|
191 \begin{enumerate}
|
|
|
192 \item 関数呼び出しを表す構文木\verb|a|の取得
|
|
|
193 \item \verb|a|から引数を表す構文木を取得、それぞれについて
|
|
|
194 \begin{enumerate}
|
|
|
195 \item 同じ型の名前なし一時変数を作成
|
|
|
196 \item 引数の値を一時変数に代入
|
|
|
197 \item 関数に渡す引数を一時変数に変更
|
|
|
198 \end{enumerate}
|
|
|
199 \item 呼び出す関数がポインタだった場合
|
|
|
200 \item 関数と同じ型（関数ポインタ）の一時変数を作成
|
|
|
201 \item 関数アドレスを一時変数に代入
|
|
|
202 \item 呼び出す関数を一時変数に変更
|
|
|
203 \end{enumerate}
|
|
|
204
|
|
|
205 ここでは関数ポインタも引数と同じように扱い、一時変数に退避する。
|
|
|
206 実際のプログラムはコード\ref{code:replace-args}の様になる。
|
|
|
207 この関数\verb|cbc_replace_arguments|は関数呼び出し構文木を引数として受
|
|
|
208 け取り、上記の処理を行う。tree callがその構文木である。
|
|
|
209 \verb|build_decl|は名無し一時変数の宣言、 \verb|build_modify_expr|は一
|
|
|
210 時変数への代入を行う構文木の生成をしている。
|
|
|
211
|
|
|
212 \lstinputlisting
|
|
|
213 [caption=上記の処理を行う関数,label=code:replace-args]
|
|
|
214 {sources/replace-args.c}
|
|
|
215
|
|
|
216 これによりソースコードの構文解析時、軽量継続をパースしてその構文木を生
|
|
|
217 成した際にこの関数\verb|cbc_replace_arguments|を実行することで、この軽
|
|
|
218 量継続は並列代入に対応できるようになった。
|
|
|
219
|
|
|
220 この影響による速度変化の評価は\ref{sec:compare2old}節で行う。
|
|
|
221
|
|
|
222
|
|
|
223 \subsection{環境付き継続}
|
|
|
224
|
|
|
225 環境付き継続は過去の研究では実装されていなかった。
|
|
|
226 これはCとの互換性のために必要な制御構造である。
|
|
|
227
|
|
|
228 環境付き継続には\ref{ssec:gotowithenv}で述べたように、\verb|__return|
|
|
|
229 という擬似変数を使う。この変数の値を継続先のコードセグメントに渡すこと
|
|
|
230 で、そのコードセグメントから関数の環境へ復帰することを可能にする。
|
|
|
231 渡された\verb|__return|の値は、コードセグメント側からは他のコードセグ
|
|
3
|
232 メントと区別する必要はない。
|
|
2
|
233
|
|
|
234 この環境付き継続にもちいる\verb|_ _return|擬似変数の実装には様々な方法
|
|
|
235 が考えられるが、今回の実装には内部関数をもちいることにした。内部関数は
|
|
3
|
236 GCCによるCの拡張機能である\cite{bib:nestedfunc}。
|
|
2
|
237
|
|
|
238 \subsubsection{GCCにより追加されるコード}
|
|
|
239 環境付き継続で使う\verb|__return|変数は特殊なコードセグメントへのポイ
|
|
|
240 ンタとなる必要がある。このコードセグメントはユーザでは定義せず、その変
|
|
|
241 数を参照した関数の返り値型を基にコンパイラが自動で生成する事が望ましい。
|
|
|
242
|
|
|
243 具体的には、コード\ref{code:cbcreturn}の関数funcBをコンパイラは次のコ
|
|
|
244 ード\ref{code:nestedcode}の様に解釈し、内部コードセグメントを自動生成
|
|
|
245 する。
|
|
|
246 \lstinputlisting
|
|
|
247 [caption=コード\ref{code:cbcreturn}のfuncBに追加される処理,
|
|
|
248 label=code:nestedcode,numbers=left]
|
|
|
249 {sources/nestedcode.cbc}
|
|
|
250
|
|
|
251
|
|
|
252 5--14行がGCCにより追加される処理である。内部コードセグメント
|
|
|
253 \verb|__unnamed_code|は受け取った引数を関数の返り値として保持し、ラベ
|
|
|
254 ル\verb|__unnamed_label|にjumpする。この時点で内部コードセグメントを抜
|
|
|
255 けて元の関数funcBの環境に復帰する。
|
|
|
256
|
|
|
257 さらにjump先もGCCにより自動で追加される。しかしこのjump先は
|
|
|
258 \verb|__unnamd_code|以外からは実行してはならない。そのため条件式が真に
|
|
|
259 ならないif文で囲み、実行を回避している。
|
|
|
260 jump先での処理は、\verb|__unnamed_code|内で代入された値を持ってリター
|
|
|
261 ンするのみである。
|
|
|
262
|
|
|
263
|
|
|
264 \subsubsection{内部コードセグメント自動生成の実装方法}
|
|
|
265
|
|
|
266 GCCは変数や関数、また文字列や数値などのリテラルに関する処理を
|
|
|
267 \verb|c_parser_postfix_expression|で行っている。この関数では変数や数値
|
|
|
268 、文字列などの判定に500行にわたるswitch文を使っているが、ここに
|
|
|
269 \verb|__return|の判定も追加する。
|
|
|
270
|
|
|
271 必要な処理は以下の様になる。
|
|
|
272 \begin{itemize}
|
|
|
273 \item ラベル\verb|_ _unnamed_label|の宣言
|
|
|
274 \item 返り値を保持しておく変数の宣言
|
|
|
275 \item 内部関数の定義
|
|
|
276 \item 条件分岐制御の構文木生成
|
|
|
277 \item 条件分岐内でのラベルの定義
|
|
|
278 \item 条件分岐内での復帰構文の構文木生成
|
|
|
279 \end{itemize}
|
|
|
280 参考のため付録にコード\ref{code:nestedcode}を用意した。
|
|
|
281
|
|
|
282 %コード\ref{code:nestedcode}にその処理を示す。
|
|
|
283 %\lstinputlisting
|
|
|
284 % [caption=c\_parser\_postfix\_expressionでの処理,
|
|
|
285 % label=code:nestedcode]
|
|
|
286 % {sources/c_parser_postfix_expression.c}
|
|
|
287 %ここで使われている関数\verb|cbc_define_nested_code|,
|
|
|
288 %\verb|cbc_define_if_closed_goto |もこの処理のために作成したものである
|
|
|
289 %が割愛する。処理内容は GCCが通常行う関数やif文の構文木生成とほぼ同じで
|
|
|
290 %ある。
|
|
|
291
|
|
|
292 以上でコード\ref{code:nestedcode}に示すような処理がコンパイル時に自動
|
|
|
293 で追加され、環境付き継続の使用が可能になった。
|
|
|
294
|
|
|
295 \subsubsection{関数からの継続}
|
|
|
296
|
|
3
|
297 ここで軽量継続の実装にtailcallを用いたことの弊害がでてくる。
|
|
|
298 \ref{sec:impl-goto}節の実装では関数からの継続は考慮していない。通常の
|
|
2
|
299 継続の際は現コードセグメントのもつ引数は保持しないため、直接継続しよう
|
|
|
300 とすると、その関数やその関数を呼び出した関数の持つ環境（スタック）を破
|
|
3
|
301 壊してしまう（\pageref{fig:gotostack}
|
|
|
302 ページ、図\ref{fig:gotostack}）。
|
|
2
|
303
|
|
|
304 この問題を回避するため、関数からの継続に限り、スタックを拡張し関数の環
|
|
|
305 境を保持する手法をとった。
|
|
|
306 この動作は本来の軽量継続の概念とは相容れないものだが、Cとの互換性維持
|
|
|
307 のために必要である。また、CbC部分での軽量継続ではいずれもスタックは定
|
|
|
308 常なので、CbC の目的である検証、状態遷移記述などの問題にはならない。
|
|
|
309
|
|
|
310
|
|
|
311
|
|
|
312 \subsection{PowerPCにおける間接継続}\label{sec:impl-indirect}
|
|
|
313
|
|
|
314 軽量継続の実装にtailcallを用いたことは\ref{sec:}で説明した。しかし、実
|
|
|
315 際にはtailcallが行われないアーキテクチャがいくつか存在する。 PowerPCも
|
|
|
316 その一つで、このアーキテクチャでは間接呼び出しの場合は tailcallが行わ
|
|
|
317 れない。このためこれまでPowerPCでの間接継続はコンパイルエラーで実行で
|
|
|
318 きなかった。
|
|
|
319
|
|
3
|
320 間接呼び出しのtailcallは専用のRTL表現がある。
|
|
|
321 PowerPCで問題となるのは、このRTLからアセンブラへの変換が定義されていな
|
|
|
322 いことである。この問題に対処するため、PowerPCアーキテクチャにおけるmc
|
|
|
323 を記述する。
|
|
|
324
|
|
2
|
325 \subsubsection{RTLとMachine Description}
|
|
|
326 GCCは構文木からRTLと呼ばれる中間コードを生成する。この中間コードは一部
|
|
|
327 を除いてアーキテクチャ依存性はなく、どのアーキテクチャでもほぼ同じにな
|
|
|
328 る。さらに、最終的にこのRTLはアーキテクチャ毎に異なる規則でアセンブラ
|
|
|
329 に変換される。この規則を定義するのがMachine Description（以下md）であ
|
|
|
330 る。
|
|
|
331
|
|
|
332 RTL、およびmdはどちらもS式で表現されている。
|
|
|
333 GCCは自身のビルドの際、S式をパースするプログラムを作成し、そのプログラ
|
|
|
334 ムはmdを基にアーキテクチャ毎に異なるCのソースコードを出力する。このソ
|
|
|
335 ースコードがコンパイルされてGCCの一部となる。
|
|
|
336
|
|
|
337 RTLの例としてこの問題となっている間接継続を表すS式をコード
|
|
3
|
338 \ref{code:rtl-indirecttailcall}に示す。
|
|
2
|
339 \lstinputlisting
|
|
|
340 [caption=PowerPCにおける間接継続のRTL,
|
|
3
|
341 label=code:rtl-indirecttailcall,
|
|
2
|
342 language=Lisp]
|
|
3
|
343 {sources/rtl-indirecttailcall.rtl}
|
|
2
|
344
|
|
|
345 % TODO: RTLの説明も入れるか？
|
|
|
346
|
|
|
347 \subsubsection{間接継続のmd}
|
|
|
348
|
|
|
349 mdにはこのRTLをアセンブラに変換するための情報を定義する。
|
|
|
350 定義すべき情報は以下の4つである。
|
|
|
351 \begin{itemize}
|
|
|
352 \item 規則の名前
|
|
|
353 \item 変換するRTL
|
|
|
354 \item 変換する条件
|
|
|
355 \item 出力するアセンブラを返すCの構文
|
|
|
356 \end{itemize}
|
|
|
357 同じくmdの例として、この問題となったRTL用の変換規則を定義したものをコ
|
|
|
358 ード\ref{code:md-example}に示す。
|
|
|
359 \lstinputlisting
|
|
3
|
360 [caption=\ref{code:rtl-for-indirect}の変換規則,
|
|
|
361 label=code:md-for-indirect,
|
|
2
|
362 language=Lisp]
|
|
3
|
363 {sources/md-for-indirect.md}
|
|
|
364 このコードの2番目の要素はコード\ref{code:rtl-indirecttailcall}とよく似
|
|
|
365 ていることがわかる。これは変換対象としてこの型に合うものに制限するため
|
|
|
366 である。
|
|
|
367
|
|
2
|
368 ここでは出力するアセンブラとして\verb|b%T0|が使われている。
|
|
|
369 \verb|%T0|はレジスタ名に置き換えられる部分である。このアセンブラは最終
|
|
|
370 的には\verb|bctr|と置き換えられてPowerPCのアセンブラとして出力される。
|
|
|
371 %間接でない、通常の継続ではこれが\verb|bl%T0|となっているので対照的であ
|
|
|
372 %る。コード\ref{code:md-example}は実際に通常の継続用のmd修正して作られ
|
|
|
373 %た。
|
|
|
374
|
|
|
375
|
|
|
376
|
|
|
377
|
|
|
378 \subsection{x86における引数渡し}\label{sec:impl-fastcall}
|
|
|
379
|
|
|
380 コードセグメントの間の軽量継続は、Cの関数呼び出しと同じように引数を渡
|
|
|
381 すことができる。関数呼び出しでのこの引数の渡し型はほとんどの場合アーキ
|
|
|
382 テクチャやオペレーティングシステム、また各プログラミング言語毎に違った
|
|
|
383 規約があり、これは一般に呼出規約(Calling convention)と呼ばれている。
|
|
|
384
|
|
|
385 CbCでは同じアーキテクチャでもコンパイラによってこの呼出規約は違う。mc
|
|
|
386 の軽量継続では、なるべく多くの引数をレジスタに格納するようになっており
|
|
|
387 、 PowerPCでは最大11個のint型をレジスタに格納する。レジスタの少ない
|
|
|
388 x86でも2つだけだがやはりレジスタを使用している。
|
|
|
389
|
|
|
390 GCCベースコンパイラでは継続制御の引数渡しに関数の呼出規約と同じ方法を
|
|
|
391 使っている。そのため、x86では引数渡しに全てスタックを用いることになり
|
|
|
392 、mcに比べて速度低下がみられた。
|
|
|
393
|
|
|
394 引数渡しにレジスタを使用できるようにすることでこの問題を解決したい。
|
|
|
395
|
|
|
396 \subsubsection{fastcall}
|
|
|
397 そもそも引数渡しがスタックだけだということは、CbCだけでなくCにおいても
|
|
|
398 速度面で問題をはらんでいる。そのためGCCではもとより、x86でのレジスタ渡
|
|
|
399 しを可能にする拡張機能を実装している。それがfastcallである。
|
|
|
400
|
|
|
401 このfastcallも使用するレジスタ数は2つだけではあるが、継続制御でもこれ
|
|
|
402 を使うことにより高速化が図れるはずである。
|
|
|
403
|
|
|
404 \subsubsection{コードセグメントを全てfastcallに}
|
|
|
405
|
|
|
406 通常、GCCの拡張機能を用いて関数をfastcallにするにはコード
|
|
|
407 \ref{code:fastcall-example}の様に ``attribute''キーワードを関数宣言の
|
|
|
408 後ろに記述する。
|
|
|
409
|
|
|
410 \begin{minipage}[t]{.7\textwidth}
|
|
|
411 \lstinputlisting
|
|
|
412 [caption=fastcallな関数funcBを呼び出す例,label=code:fastcall-example]
|
|
|
413 {sources/fastcall-example.c}
|
|
|
414 \end{minipage}
|
|
|
415
|
|
|
416 しかし全てのコードセグメントに対してこの属性を宣言するのは現実的でなく
|
|
|
417 、mcとのソースコードレベルの整合性もとれない。そこでGCCではコードセグ
|
|
|
418 メントの解析時に全てfastcall属性を付加することにする。
|
|
|
419
|
|
|
420 具体的には「型」の構文解析の際、キーワード``code''で関数の型が宣言され
|
|
|
421 ている場合に、属性値を表す構文木を付加する。
|
|
|
422 \verb|c_parser_declspecs|関数が「型」に関する構文解析部である。
|
|
|
423 この関数内の型名キーワードを処理するswitch文内で、``code''のみ
|
|
|
424 fastcall属性を付加する。
|
|
|
425
|
|
|
426 コード\ref{code:declspecs}がその処理である。このコードの12--14行目が
|
|
|
427 fastcall属性付加の処理になる。それ以外の行は voidやintなど他の型の処理
|
|
|
428 と変わらない。
|
|
|
429
|
|
|
430 \lstinputlisting
|
|
|
431 [caption=c\_parser\_declspecsにおけるキーワード``code''の処理,
|
|
|
432 label=code:declspecs]
|
|
|
433 {sources/declspecs.c}
|
|
|
434
|
|
|
435 この処理で全てのコードセグメントがfastcall対応となり、軽量継続の際には
|
|
|
436 レジスタ\verb|ecx,edx|に引数をのせることが可能となる。
|
|
|
437
|
|
|
438
|
|
|
439 \subsection{プロトタイプ自動生成}
|
|
|
440 Cのプロトタイプ宣言はコンパイル時のエラー検出に役立っている。
|
|
|
441 しかしCbCのコードセグメントには返り値は存在しない。また状態遷移記
|
|
|
442 述という性質上、プログラムを記述する際は上から下に実行順にコードセ
|
|
|
443 グメントを並べることが多いため、プロトタイプ宣言をするとそれが膨大
|
|
|
444 な数になる。
|
|
|
445
|
|
|
446 また、mcベースコンパイラの方ではプロトタイプ宣言を減らすため、一種の簡
|
|
|
447 単な型推論を実装している。そのためこれまでに作られたCbCのプログラムで
|
|
|
448 は特殊な場合を除いてプロトタイプ宣言がほとんどなく、GCCでコンパイルす
|
|
|
449 る際に問題となる。
|
|
|
450
|
|
|
451 この問題に暫定的に対処するため、Pythonを用いてプロトタイプの自動生成を
|
|
|
452 行うスクリプトを作成した。このスクリプトでは関数の定義部を正規表現で検
|
|
|
453 索し、マッチする部分を変換して関数宣言として出力する。
|
|
|
454
|
|
|
455 全コードは付録\ref{apx:}に掲載する。
|
|
|
456
|
|
|
457 % TODO: prototype declaration
|
|
|
458
|
|
|
459
|
