--- a/nobu-midthesis.tex	Fri Nov 18 18:01:10 2011 +0900
+++ b/nobu-midthesis.tex	Fri Nov 18 18:48:55 2011 +0900
@@ -20,9 +20,9 @@
 \pagestyle{empty}
 
 \begin{document}
-\title{Continuation based C コンパイラのGCC-4.6による実装}
+\title{Continuation based C コンパイラのGCC-4.6における実装}
 \author{学籍番号:085711E 氏名:大城信康 {}{} 指導教員 : 河野真治}
-\date{H23 11/18 fri}
+%\date{H23 11/18 fri}
 \maketitle
 \thispagestyle{fancy}
 
@@ -75,6 +75,7 @@
 
 軽量継続によりループ制御、関数コールとスタックの操作を意識し最適化がソースコードレベルで行えるようになる。
 
+
 %だが、返り値を持たないコードセグメントではスタックに積まれる値は1つのコードセグメントの引数の分だけですむ。
 
 \section{GCC-4.6 への実装}
@@ -99,9 +100,29 @@
 
 CbC における軽量継続の実装はこの Tail Call Elimination を用いて行われている。
 コードセグメントは全てこの Tail Call Elimination にかからなければならない。
-だが、CbC-GCC-4.5 において Tail Call Elimination にかからないコードセグメントがあることを確認できた。
+
+\subsubsection{expand\_call}
+ある関数が Tail Call Elimination を行えるかどうかは expand\_call 関数で判断される.
+expand\_call 関数内でチェックされる Tail Call Elimination が行える条件は以下になる.
+
+\begin{itemize}
+  \item caller 側と callee 側の返す値の型が一致している.
+  \item 関数呼び出しがリターンの直前に行われている.
+  \item 呼出先関数の引数に用いられるスタックサイズが呼出元関数のそれより少ない.
+\end{itemize}
+
+CbC の実装では上記の条件を,以下の様にして解決させている.
+
+\begin{itemize}
+  \item 呼び出す関数がコードセグメントの場合返す値の型チェックを行わない.
+  \item コードセグメントへの継続を Generic Tree で表す際に,return の情報も直後に持たせる.
+  \item スタックサイズは決め打ちで行う.
+\end{itemize}
+
+だが、 CbC-GCC-4.5 において Tail Call Elimination にかからないコードセグメントがあることを確認できた。
 この点は GCC-4.6 へのアップデートに合わせ改善する。
 
+
 %\subsubsection{try_tail_call フラグ}
 %Tail Call Elimination が可能である場合、try_tail_call フラグが立てられる。
 %コードセグメントへの jmp は Tail Call Elimination を受けることで実装される。
@@ -111,25 +132,14 @@
 %この問題を解決し、全てのコードセグメントは jmp によって呼びされるようにする必要がある。
 
 
-\subsection{typedefrec の実装}
-C では関数や構造体の宣言の時に自分自身を引数にすることができない。
-そこで“typedefrec” という構文を作り、図\ref{fig:typedefrec}のような宣言を行えるようにしたい。
-
-\begin{figure}[h]
-  \begin{minipage}[b]{.45\textwidth}
-    \begin{lstlisting}[caption=CbCコード例,label=code:CbC-example]
-typedefrec void *funcA(int, funcA);
+%\begin{figure}[htpb]
+%  \begin{center}
+%\scalebox{0.35}{\includegraphics{figure/cs_stack.eps}}
+%  \end{center}
+%  \caption{継続による引数のスタック格納の様子}
+%  \label{fig:cs_stack}
+%\end{figure}
 
-typedefrec struct {
-  node left;
-  node right;
-} *node;
-    \end{lstlisting}
-  \end{minipage}
-  \hfill
-\end{figure}
-
-より柔軟なプログラミングが行えるように typdefrec を実装を行いたい。
 
 %\subsubsection{typedefrec の実装方法}
 %typedefrec 
@@ -144,31 +154,36 @@
 \subsection{環境付き継続}
 CbC では通常の C の関数からコードセグメントに継続する際、
 元の C の関数に処理を戻すことがように環境付き継続を実装してある。
-環境付き継続は \_\_return 変数を参照することで用いることができる。
-\_\_return 変数は参照されると、参照した関数のアドレスを覚えておく。
-コードセグメントの継続の際に引数に \_\_return 変数を渡すことで、
-関数の呼び出し元のアドレスも渡すことができる。
-後は引数として渡されたきたアドレスへ飛ぶことでいつでも C の関数に戻ることができる。
-
-\subsubsection{\_\_return 変数の問題}
-しかし現在この \_\_return の値は static で実装されている。
-これではスレッドセーフであるとは言えない。
-マルチスレッドで\_\_returnを扱うと、元の関数に戻る前に \_\_return の値が書き換えられる可能性があるからである。
-そこで、\_\_return をスレッドセーフにする必要がある。
+環境付き継続は \_\_return, \_\_environment という CbC で定義した変数を参照することで用いることができる。
+この2つの変数は参照されると、参照した関数のアドレスを覚えておく。
+具体的には変数を参照した関数にコード\ref{code:_ret_val}の生成を行なっている。
+コードセグメントから戻るときには関数内で定義された \_cbc\_internal\_return 関数に飛び、
+リターンを行うのである。
+\begin{figure}[h]
+  \begin{minipage}[b]{.45\textwidth}
+    \begin{lstlisting}[caption=環境付き継続を行うコード,label=code:_ret_val]
+__label__ _cbc_exit0;
+int retval; // should be thread local                                                                                                                                                   
+void _cbc_internal_return(int retval_, void *_envp){
+  retval = retval_;
+  goto _cbc_exit0;
+}
+if (0) {
+ _cbc_exit0:
+  return retval;
+ }
+_cbc_internal_return;
+    \end{lstlisting}
+  \end{minipage}
+  \hfill
+\end{figure}
 
-\subsection{x86\_64 での fastcall}
-GCC では関数の呼び出しの際に引数はスタックに積まれて渡されるが、
-レジスタを使って渡すようにする fastcall という拡張機能がある。
-CbC-GCC ではコードセグメントとして宣言された場合 fastcall が自動で付くようにしていた。
-しかし、x86\_64 においてこの fastcall は標準の機能となっており、コンパイルの際に warning が吐かれた。
-そこで、x86\_64 の場合は fastcall を付与させないようにした。
+\subsubsection{環境付き継続の問題}
+しかし現在環境付き継続はスレッドセーフな実装でない。
+その為,マルチスレッドで環境付き継続を扱うと、元の関数に戻る前に別スレッド
+が記憶したアドレスの値を書き換えられる可能性があるからである。
+そこで、環境付き継続をスレッドセーフで実装する必要がある。
 
-\section{CbC の今後}
-現在 CbC は C をベースとして設計されている。
-しかし、C ではプロトタイプ宣言や継続の際に型推論が扱えないなど不便な点があることがわかっている。
-そこで、Go や D 言語と言った言語へ実装を行いたいという要求がでてきた。
-
-また、LLVM ベースの CbC コンパイラについても検討している。
 
 \section{現状と今後の課題}
 %アセンブラ出力を見ることができ、gdb を使ってのデバッグが可能になったことである。
@@ -180,8 +195,6 @@
 また、実装後は、32ビット,64ビットそれぞれでコンパイルしたプログラムの比較、
 それと Micro-C との性能比較も行う予定である。
 
-Go 言語や D 言語への CbC の移植,
-LLVM ベースの CbC コンパイラについては実装の方法から考えていくことになる。
 
 %今後は本稿で述べた CbC-GCC の問題点を改善していく必要がある。
 %また、CbC を GCC だけでなく LLVM での実装や、C 言語以外の言語への変更も検討していく。
@@ -204,10 +217,10 @@
 \bibitem{5}{下地篤樹,河野真治}:
 “線形時相論理を用いたContinuation based C プログラムの検証”. 琉球大学大学院　理工学研究科 情報工学専攻 学位論文(修士), 2008
 
-%\bibitem{6}{楊挺,河野真治}:
-%“Continuation based C の実装”. 琉球大学大学院　理工学研究科 情報工学専攻 学位論文(修士), 2002
+\bibitem{6}{楊挺,河野真治}:
+“Continuation based C の実装”. 琉球大学大学院　理工学研究科 情報工学専攻 学位論文(修士), 2002
 
-\bibitem{6}{GNU Compiler Collection (GCC) Internals}:
+\bibitem{7}{GNU Compiler Collection (GCC) Internals}:
 “http://gcc.gnu.org/onlinedocs/gccint/”