Mercurial > hg > Papers > 2010 > kent-master
annotate cbc.tex @ 7:8ef81ff8cb52
emended.
| author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
|---|---|
| date | Fri, 12 Feb 2010 13:10:57 +0900 |
| parents | b59d31966d7d |
| children | 4b2af58b0302 |
| rev | line source |
|---|---|
| 0 | 1 \chapter{Continuation based C (CbC)} |
| 2 \label{chp:cbc} | |
| 3 | 3 |
| 4 Continuation based C（以下CbC）は当研究室の提案する、アセンブラよりも | |
| 7 | 5 上位でCよりも下位な記述言語である。我々は様々な視点からこのCbCを用いた |
| 6 研究を行っている。本章ではそのCbCの仕様と現在の状況について説明し、ま | |
| 7 たCbCを用いた研究例についても紹介する。 | |
| 0 | 8 |
| 9 \section{CbCの要求仕様} | |
| 10 90 年代以降、ハードウェアの進歩がプログラミング言語よりも早く進みつつ | |
| 11 あり、70 年代、80 年代に設計された言語は矛盾を抱えて来ている。 | |
| 12 | |
| 13 オブジェクト指向技術とそれに基づいたJava などの言語が注目されているが | |
| 14 、これらの言語は動的な適合性を中心に設計されたものである。C などの低レ | |
| 1 | 15 ベルな言語による記述に比べて、余分な条件判断（Method search, Meta level |
| 16 での実行） を増やしてしまい、コンパクトで高速な応答を期待される | |
| 7 | 17 Real-time 処理や組み込み用途には適さない。この用途にはハードウェアに近 |
| 18 い記述が要求される。 | |
| 0 | 19 |
| 7 | 20 %ハードウェアに一番近い言語はアセンブラであるがマクロアセンブラなどの記 |
| 21 %述はあまりにも低レベルであり、長年進歩していない。しかし使用可能なゲー | |
| 22 %ト数が増えるにつれ、RISC 的な対称性の高い小数の命令よりも、複雑なマル | |
| 23 %チメディア関係の命令などを持つCISC 的なCPU が増えてきている。そのため | |
| 24 %に既存の言語に対するコンパイラをその都度設計し直すことが必要になってき | |
| 25 %ている。 | |
| 0 | 26 ハードウェアに一番近い言語はアセンブラであるがマクロアセンブラなどの記 |
| 7 | 27 述はあまりにも低レベルであり、依存性が強く汎用的ではない。さらに使用可 |
| 28 能なゲート数が増えるにつれ、RISC 的な対称性の高い少数の命令よりも、複 | |
| 29 雑なSIMD命令やソフトウェアパイプライン命令を持つCPU が増えてきている。 | |
| 30 そのために既存の言語に対するコンパイラをその都度設計し直すことが必要に | |
| 31 なってきている。 | |
| 0 | 32 |
| 33 VHDL, Verilog などのハードウェア記述言語は有限状態遷移の中に閉じており | |
| 34 、オブジェクト指向などの抽象化とはまったく別なものとなってしまっている。 | |
| 35 | |
| 7 | 36 このようにハードウェア記述言語、アセンブラ、プログラミング言語の3つは |
| 37 全く異なる方向を向いている。コンパイラの自動生成などが重要な研究テーマ | |
| 38 となると考えられるが、この3つが全く独立したものであれば困難なものにな | |
| 39 ると考えられる。 | |
| 0 | 40 |
| 41 そこでCbC はこの3 つを埋めるべく以下のような要求仕様に従って設計された。 | |
| 42 \begin{itemize} | |
| 43 \item ハードウェアとスタックマシンの中間言語 | |
| 44 | |
| 7 | 45 インタプリタ記述やコンパイラターゲットとして優れる。アーキテクチャ |
| 46 依存性が少ない。また、アーキテクチャ依存性をモデル化できる。 | |
| 0 | 47 |
| 48 \item C 言語よりも下位の言語 | |
| 49 | |
| 7 | 50 アセンブラよりも汎用性と記述性に優れC と互換である。C をCbC にコン |
| 51 パイルでき、ハンドコンパイルの結果を同値なコードに変換できる。 | |
| 0 | 52 |
| 53 \item 明確な実行モデル | |
| 54 | |
| 55 C++やProlog のような複雑な実行モデルは好ましくなく、ハードウェアに | |
| 56 実行順序の変更を許す範囲を広くする。 | |
| 57 | |
| 58 \item 状態遷移を直接記述できる | |
| 59 | |
| 60 Yacc のような表駆動やC のような巨大なswitch 文ではなく直接に状態遷 | |
| 61 移ができ実行できる。 | |
| 62 | |
| 63 \item Thread を実行モデルに内蔵できる | |
| 64 | |
| 7 | 65 %並列処理記述法ではなく状態遷移として表現できる。 |
| 66 状態遷移記述とCbC上のスケジューラ実装によりスレッドを実現可能にす | |
| 67 る。 | |
| 0 | 68 |
| 69 \item クリティカルパスの最適化 | |
| 70 | |
| 7 | 71 全体を散漫に最適化するのではなく、実行ルーチンから重要な箇所を抜き |
| 72 出し、アセンブラに近い最適化をソースコードレベルで実現する。 | |
| 73 | |
| 74 %全体を散漫に最適化するコンパイルではなくクリティカルパスを見つけ出 | |
| 75 %して最適化できる。 | |
| 0 | 76 \end{itemize} |
| 77 | |
| 78 これらの仕様はハードウェア記述とソフトウェア記述の両方を同時に行いつつ | |
| 79 、C よりも精密な実行記述を可能にするためのものである。また、CbC はプロ | |
| 7 | 80 グラム変換やコンパイラターゲットとしての使用を意識している。状態遷移記 |
| 81 述のみでは制御機構は静的なものになってしまう。CbC では状態遷移記述に適 | |
| 82 した言語を作ることを考え、スタックマシンを避けてContinuation（継続）が | |
| 83 導入されている。 | |
| 0 | 84 |
| 85 | |
| 86 \section{コードセグメントと継続} | |
| 87 | |
| 88 \subsection{call-returnから継続制御へ} | |
| 89 Cなどの一般的な手続き型言語では、呼び出した手続きの処理のあと、呼出し | |
| 90 元の環境に復帰する。そのためプログラム全体においてスタックが用意され、 | |
| 91 呼出し元はスタックに復帰先アドレス及び環境を保持しておく事で呼出し先か | |
| 92 らの復帰を可能とする。これはcall-return制御と呼ばれるものである（図 | |
| 93 \ref{fig:call-return}）。 | |
| 1 | 94 しかし復帰先が決まっていて環境を受け継ぐことができれば、この |
| 95 call-return制御は図 \ref{fig:continuation}の様に手続き呼び出しの前後で | |
| 96 分割する事ができ、スタック操作を伴わないシーケンシャルな呼び出しに変換 | |
| 97 する事ができる。 | |
| 0 | 98 これは継続制御構造と呼ばれている。schemeのcall-with-continuationの実装 |
| 99 や、 Java,C++の例外処理、Cのsetjmp()/longjmp()による大域脱出もこの継続 | |
| 100 制御の一種である。 | |
| 101 \begin{figure}[hptb] | |
| 102 \begin{center} | |
| 103 %\includegraphics[width=\textwidth,bb=0 0 595 842]{figures/call-return.pdf} | |
| 104 \includegraphics[width=.6\textwidth]{figures/call-return.eps} | |
| 105 \end{center} | |
| 106 \caption{call-return制御} | |
| 107 \label{fig:call-return} | |
| 108 \end{figure} | |
| 109 \begin{figure}[hptb] | |
| 110 \begin{center} | |
| 111 \includegraphics[width=.6\textwidth]{figures/continuation.eps} | |
| 112 \end{center} | |
| 113 \caption{継続制御} | |
| 114 \label{fig:continuation} | |
| 115 \end{figure} | |
| 116 | |
| 7 | 117 \subsection{Schemeにおける継続制御} |
| 118 継続とは一般的には「現在の処理を続行するための情報」と解釈されている。 | |
| 119 継続制御はその情報をプログラム記述で操作するための構文である。 | |
| 120 例としてSchemeでの継続の使用をコード\ref{code:scheme-cont}に挙げる。 | |
| 121 | |
| 122 %\lstset{morecomment=[is]{/*}{*/}} % /*コメント内を非表示にする*/ | |
| 123 \lstinputlisting | |
| 124 [caption=Schemeでの継続制御の例, | |
| 125 label=code:scheme-cont, | |
| 126 language=Lisp, | |
| 127 morekeywords={cont,cont-test}, | |
| 128 emph={gosh}, | |
| 129 emphstyle=\bfseries\underbar] | |
| 130 {sources/scheme-cont-out.scmout} | |
| 131 | |
| 132 この例では関数\verb|cont-test|内にて\verb|call/cc|を呼ぶことで、現在の | |
| 133 計算処理の``継続''を関数として変数\verb|cont|に保持している。 | |
| 134 | |
| 135 その後、\verb|(cont)|という命令でその関数を実行すると、contが代入され | |
| 136 た位置に処理が復帰する。そのため、直前の``before''は出力されずに | |
| 137 ``after''が出力されていることが分かる。\verb|cont|では関数の継続処理だ | |
| 138 けでなく、引数などの環境も一緒に保持しているので、この\verb|cont|は呼 | |
| 139 ばれる度に \verb|i|カウントアップし、その値を返すことになる。 | |
| 140 | |
| 141 | |
| 0 | 142 CbCはこの継続制御を基本として設計されており、その実現のためにコードセ |
| 143 グメントと軽量継続という概念を用いている。 | |
| 144 以下ではその二つについて説明する。 | |
| 145 | |
| 146 \subsection{コードセグメント} | |
| 147 CbCは図\ref{fig:continuation}の様に分割された手続きのそれぞれを一つの | |
| 4 | 148 処理単位として用い、これを``コードセグメント(code-segment)''と呼ぶ。 |
| 0 | 149 |
| 150 コードセグメントはキーワード``code''を用いてCの関数の様に定義される。 | |
| 2 | 151 引数部分はインタフェイスと呼ばれ、継続前のコードセグメントからの出力に |
| 152 あたる。例として、引数で与えられた数xの階乗を求めるプログラムをコード | |
| 0 | 153 \ref{code:factorial}に示した。 |
| 2 | 154 |
| 155 \lstinputlisting[caption=CbCプログラムの例（階乗計算）,label=code:factorial]{sources/factorial.cbc} | |
| 0 | 156 |
| 157 %コードセグメントは手続きを細かく分割したものなので、Cの関数と比べより | |
| 158 %小さい処理単位となる。しかしコードセグメント内部ではCのステートメント | |
| 159 %と同様の記述が可能であり、処理単位としてはステートメントより大きいもの | |
| 160 %となる。 | |
| 161 | |
| 1 | 162 \subsection{軽量継続(light-weight continuation)} |
| 0 | 163 コードセグメントはCにおける関数とは違い、呼出し元への復帰は存在しない。 |
| 164 そのためコードセグメントの処理の末尾で別のコードセグメントへ継続するこ | |
| 4 | 165 とになる。CbCではこの継続制御を``軽量継続(light-weight continuation)'' |
| 0 | 166 と呼ぶ。 |
| 167 | |
| 168 軽量継続はキーワード``goto''のあとにコードセグメント名とそのコードセグ | |
| 169 メントのインタフェイスに渡す引数列を並べて記述する。（同じく軽量継続の | |
| 170 例がコード \ref{code:factorial}にみられる。） | |
| 171 | |
| 172 %この引数列は継続前のコードセグメントの状態、つまりインタフェイスの値に | |
| 173 %よって一意に決まる | |
| 174 | |
| 2 | 175 この例の様に、プログラムはforやwhileなどのループ制御構造を含んでいない |
| 176 。代わりに、コードセグメント\verb|factorial0|の様に自分自身への軽量継 | |
| 177 続を用いることで繰り返し処理を実現している。Cでは再帰関数を使うことで | |
| 178 同じことを行えるが、そこにはスタックの拡張という処理が入る。しかしCbC | |
| 179 ではスタックの拡張は行われず、元の環境に戻ることはない。 | |
| 0 | 180 |
| 181 | |
| 182 \section{状態遷移に適した言語} | |
| 183 Continuation based Cは値を返すプログラムよりも、状態遷移記述に適している。 | |
| 184 | |
| 185 従来の言語での状態遷移記述は | |
| 186 \begin{itemize} | |
| 187 \item 表を使った状態遷移インタプリタ | |
| 188 \item 巨大なswitch文 | |
| 189 \end{itemize} | |
| 190 などが用いられてきた。しかしこれらは記述性が悪く、効率も良くない。 | |
| 191 | |
| 192 表を使った状態遷移インタプリタはコンパイラ言語とは考えられない。また、 | |
| 193 それをハードウェア記述に落とすことは難しい。 | |
| 194 | |
| 195 巨大なswitch文は、コンパイルが複雑になり、適切な最適化を行うことが難し | |
| 196 い。また、人間が読む場合にも読みやすいとは言えない。 | |
| 197 | |
| 198 CbCは元々状態遷移を直接記述することを目的として設計されており、 | |
| 199 手続きの様に環境の保持を伴わないため、その時々に実行中のコードセグメン | |
| 200 トとその引数を直接プログラムの状態とみなす事ができる。 | |
| 201 | |
| 202 特にゲームやGUIを用いたプログラムなどでは状態遷移記述が多用されており | |
| 203 、そのようなプログラムでは CbCを状態記述言語として使うことにより、直接 | |
| 204 実行による実行の高速化と既存の言語と状態遷移記述の整合性の向上をはかる | |
| 205 ことができる。 | |
| 206 | |
| 207 | |
| 208 \section{C with Continuation} | |
| 2 | 209 数学的検証や組み込み用途を目的として提案されたCbCであるが、既存のソフ |
| 210 トウェアやシステムは膨大な数にのぼり、これらをCbCに置き換えるのは無理 | |
| 211 がある。そのため、少なくともソースコードのレベルでCとの互換性を持つこ | |
| 212 とが望ましい。 | |
| 213 Continuation based Cの名のとおり、CbCからCの関数の呼び出しは問題なく行 | |
| 214 える。しかしCbCをCと相互に利用するためには、Cの関数から継続を行った場 | |
| 215 合に元の環境に戻るための、特殊な継続を導入する必要がある。これを環境付 | |
| 216 き継続と呼ぶ。 | |
| 0 | 217 |
| 218 この環境付き継続を導入した言語はC with Continuation(CwC)と呼ばれ、Cと | |
| 219 CbCの両方の機能をもつ言語となる。また、 C、CbCはCwCのサブセットと考え | |
| 220 られるので（図 \ref{fig:cwc}）、CwCのコンパイラをCbCに使用する事ができ | |
| 3 | 221 る。 |
| 222 これまでに実装されてきたCbCのコンパイラは実際にはCwCのコンパイラとして | |
| 223 実装されている。 | |
| 0 | 224 |
| 225 \begin{figure}[htpb] | |
| 226 \begin{center} | |
| 227 \includegraphics[width=.6\textwidth]{figures/CwC.eps} | |
| 228 \end{center} | |
| 229 \caption{C with Continuationとそのサブセット} | |
| 230 \label{fig:cwc} | |
| 231 \end{figure} | |
| 232 | |
| 233 | |
| 2 | 234 \subsection{環境付き継続}\label{ssec:gotowithenv} |
| 0 | 235 環境付き継続を用いる場合、Cの関数からコードセグメントへ継続する際に |
| 4 | 236 \verb|__return|という変数で表される特殊なコードセグメントポインタを渡 |
| 237 す。コード\ref{code:cbcreturn}では関数\verb|funcB|からコードセグメント | |
| 3 | 238 \verb|cs|に継続する際に\verb|__return|を渡している。 |
| 0 | 239 継続先のコードセグメントでは渡されたコードセグメントポインタへ継続する |
| 240 事で元のCの環境に復帰することが可能となる。 | |
| 4 | 241 ただし復帰先は\verb|__return|を参照した関数が終了する位置である。この |
| 242 プログラムの例では、関数\verb|funcA|からは\verb|funcB|が正常に終了した | |
| 243 ように見える。図\ref{fig:cbcreturn}にこの様子を表した。 | |
| 2 | 244 \lstinputlisting |
| 245 [caption=\_\_returnの例, | |
| 246 label=code:cbcreturn, | |
| 247 emph=\_\_return] | |
| 1 | 248 {sources/cbcreturn.cbc} |
| 249 この様な形にすることでcode segment側では関数から呼ばれたか、コードセグ | |
| 250 メントからの継続かを考慮する必要がない。また、\verb|funcA|からもその内 | |
| 251 部でコードセグメントが使われていることを隠蔽できる。 | |
| 252 \begin{figure}[htpb] | |
| 253 \begin{center} | |
| 254 \includegraphics[width=.6\textwidth]{figures/cbcreturn.eps} | |
| 255 \end{center} | |
| 256 \caption{\_\_returnの例} | |
| 257 \label{fig:cbcreturn} | |
| 258 \end{figure}% | |
| 0 | 259 |
| 7 | 260 環境付きは実際にはCにおける\verb|setjmp()/longjmp()|とほぼ同じ処理であ |
| 261 る。この二つの関数はCで継続を実現するために用いられる。例としてコード | |
| 262 \ref{code:setjmp}を挙げる。このコードでは\verb|setfunc|内で | |
| 263 \verb|setjmp|を使用している。\verb|setjmp|は通常は0を返すため、if文の | |
| 264 内部は実行されないが、その後\verb|longjmp|が実行されると、関連する | |
| 265 \verb|setjmp|が呼び出された環境に``継続''し、非零を返すためif文の中が | |
| 266 実行されることになる。この時、\verb|longjmp|の呼出側（この例では | |
| 267 \verb|jmpfunc|）の環境は失われる。 | |
| 0 | 268 |
| 7 | 269 環境付き継続もこの動作によく似ており、if文内でreturnのみを記述すること |
| 270 に相当する。 | |
| 271 | |
| 272 \lstset{morecomment=[is]{/*}{*/}} % /*コメント内を非表示にする*/ | |
| 273 \lstinputlisting | |
| 274 [caption=setjmp/longjmpの例, | |
| 275 basicstyle=\footnotesize\ttfamily,% | |
| 276 commentstyle=\footnotesize\itshape\rmfamily,% | |
| 277 label=code:setjmp, | |
| 278 emph={setjmp,longjmp}] | |
| 279 {sources/setjmp.c} | |
| 280 \lstset{morecomment=[s]{/*}{*/}} % /*元に戻す*/ | |
| 0 | 281 |
| 282 | |
| 2 | 283 |
| 284 \section{CbCの用途・先行研究} | |
| 285 CbCによるプログラム記述の例として本研究室における研究例を紹介する。 | |
| 286 | |
| 287 \subsection{プログラムの検証} | |
| 288 計算機科学の進歩により、ソフトウェアは大規模かつ複雑なものになっている | |
| 289 。しかしそれに応じて、設計段階において誤りが生じる可能性も高くなってき | |
| 290 ており、設計されたシステムに誤りがないことを保証するための論理設計や検 | |
| 291 証手法及びデバッグ手法の確立が重要な課題となっている。 | |
| 292 | |
| 293 どんなプログラムでも状態と状態遷移が存在し、その全てを網羅的に探索する | |
| 294 ことでデッドロックなどの望ましくない状態を検出することができる。探索に | |
| 295 はさまざまな手法が考えられるが、プログラムを直接状態遷移として記述でき | |
| 296 ればこの探索に有利となる。 | |
| 297 | |
| 298 本研究室の下地らはこの特徴を持つCbCを用いて線形時相論理による検証を提 | |
| 4 | 299 案し、その有用性を示した。\cite{bib:shimoji-2006}, |
| 300 \cite{bib:shimoji-2007} | |
| 2 | 301 |
| 302 | |
| 303 \subsection{ゲームプログラミングにおけるデモンストレーション} | |
| 304 我々は家庭用ゲーム機で動作するゲームプログラムのオープンな開発フレーム | |
| 305 ワークに関する研究も行ってきた。家庭用ゲーム機の多くは特殊なアーキテク | |
| 306 チャをもち、そのためゲームプログラムには汎用性や冗長性が極めて小さく、 | |
| 307 移植が困難という問題がある。 | |
| 308 | |
| 309 その問題の解決に、ゲームプログラム全体を小規模なプログラムの集合である | |
| 6 | 310 ``デモンストレーション''に分割することで移植性を向上する手法を本研究室 |
| 311 の金城らが提案した。\cite{bib:kinjo-master-2005},\cite{bib:akira-2008} | |
| 2 | 312 |
| 313 このデモンストレーション手法はプログラムを細かく分割するため、ゲーム機 | |
| 314 や組み込みなどの資源が制約された環境ではサブルーチンによるスタック操作 | |
| 315 がネックとなる。そのためこの手法ではプログラム分割の実現にCbCを用いて | |
| 316 おり、CからCbCへの機械的な変換方法について述べている。 | |
| 317 | |
| 318 | |
|
5
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
319 %\subsection{CbCによる分散プログラミング} |
|
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
320 %現在の分散プログラミングには様々な手法がある。ネットワークAPIを直接使 |
|
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
321 %う方法、SOAPやMPIなどのライブラリ、Telescripに見られる言語仕様への埋め |
|
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
322 %込みなどがあった。これらは通信に関する複雑なセマンティクスを実現する手 |
|
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
323 %段といえる。 |
| 7 | 324 % TODO 分散プログラミング |
| 2 | 325 |
| 0 | 326 |
| 7 | 327 \section{CbCコンパイラの現状と本研究における目標} |
| 1 | 328 \label{sec:cbc-problem} |
| 0 | 329 |
| 3 | 330 \subsection{micro-cとGCC} |
| 331 | |
| 4 | 332 CbCのコンパイラには二つの実装が用意されている。一つは2000年に当研究室 |
| 333 の河野らにより開発された、micro-cというCのコンパイラをベースとしたもの | |
| 334 である。こちらは現在安定して動作しており、アーキテクチャは PowerPC, | |
| 335 x86, MIPS, ARMなどに対応している。もう一つは2008年に開発された、GCCを | |
| 336 ベースとしたコンパイラである。 \cite{bib:kent-2008} | |
| 3 | 337 |
| 4 | 338 GCCは元より多数のアーキテクチャに対応しており、高機能な最適化も備えて |
| 339 いる。これらをCbCでも活用したいという要望からコンパイラ環境の移植が行 | |
| 340 われた。 | |
| 341 | |
| 7 | 342 \subsection{本研究における目標}\label{sec:gcc-problems} |
| 3 | 343 |
| 344 この時の実装でコードセグメント、継続制御構造などは実装され、一通りの | |
| 345 CbCプログラムのコンパイルが可能となった。 | |
| 0 | 346 |
| 7 | 347 本研究ではこのGCCベースのコンパイラをより実用的なCbCコンパイラとすべく |
| 348 以下の項目を目標とする。 | |
| 0 | 349 |
| 350 \begin{itemize} | |
| 351 \item 環境付き継続 | |
| 352 | |
| 7 | 353 Cとの互換性のための制御構造である環境付き継続を実装する。 |
| 0 | 354 |
| 355 \item 並列代入 | |
| 356 | |
| 7 | 357 これまでGCCベースのコンパイラでは、実装方法の影響から継続制御に一 |
| 358 部制限が存在した。これは実行中のコードセグメントの引数と継続制御に | |
| 359 渡す引数の順序が入れ替わる場合等に継続が行えないという制限である。 | |
| 360 | |
| 361 並列代入を行うことで引数順序の影響はなくなり、この制限を排除できる。 | |
| 0 | 362 |
| 363 \item PowerPCにおける間接継続(indirect goto) | |
| 364 | |
| 7 | 365 Cでの関数ポインタを用いた間接呼び出し(indirect call)の様に、CbCで |
| 366 用いる継続制御においても、コードセグメントポインタを用いたメモリ参 | |
| 367 照による間接的な継続が可能である。これを間接継続と呼んでいる。 | |
| 368 コード\ref{code:indirect-example}のcodepointerへの継続が間接継続に | |
| 369 当たる。 | |
| 0 | 370 \lstinputlisting[ |
| 1 | 371 caption=間接継続の例（2つめのgoto文）, |
| 0 | 372 label=code:indirect-example] |
| 373 {sources/indirect-example.cbc} | |
| 7 | 374 しかしPowerPCアーキテクチャでは最適化の問題からこの間接継続がこれ |
| 375 まで制限されていた。 | |
| 0 | 376 |
| 1 | 377 間接継続はCbCでのプログラミングには必須であり、また本研究室の主要 |
| 7 | 378 プロジェクトであるCeriumはPS3（PowerPCをもつ）をメインターゲットと |
| 379 しているため、この対応は必須のものである。 | |
| 1 | 380 |
| 7 | 381 \item プロトタイプ宣言の自動化 |
| 0 | 382 |
| 7 | 383 Cのプロトタイプ宣言はコンパイル時のエラー検出に役立っているが、 |
| 384 CbCでは返り値が存在しないなど、あまり重要な意味をなさない。 | |
| 385 また、micro-cではこれを極力排除するよう設計されているため、ソース | |
| 386 コードの互換性が薄れてしまう。 | |
| 387 | |
| 388 プロトタイプを自動生成することにより、この互換性を向上させる。 | |
| 389 | |
| 390 \item x86での継続制御の最適化 | |
| 0 | 391 |
| 7 | 392 x86では、Cの関数呼び出し全ての引数をメモリに格納する。コードセグメ |
| 393 ントは関数をベースに作られているため、このABIに引きずられ実効速度 | |
| 394 に影響をもたらしている。引数の一部をレジスタに格納することで、x86 | |
| 395 における継続処理の高速化を行う。 | |
| 0 | 396 |
| 7 | 397 \item メンテナンス性の向上 |
| 0 | 398 |
| 7 | 399 GCCのソースコードは200万行にものぼる。CbCコンパイラで修正するソー |
| 400 スコードはそのごく一部であるが、GCCのアップデートによる修正はCbC用 | |
| 401 のソースコードにも大きな影響をもたらす。 | |
| 402 GCCの最新リリースに追従するためには、アップデートも考慮し、洗練さ | |
| 403 れたメンテナンス方法が必要になる。 | |
| 0 | 404 |
| 405 \end{itemize} | |
| 406 | |
| 1 | 407 %特にPowerPCで間接継続ができないことで、当研究室が開発するPS3を主な対象としたシステムであるCeriumが実装不能であった。 |
| 7 | 408 \ref{chp:impl}章ではこれらの項目の実装を行う。 |
| 0 | 409 |
| 1 | 410 |
| 411 |