--- a/paper/resume.tex	Wed Feb 22 02:29:12 2012 +0900
+++ b/paper/resume.tex	Wed Feb 22 03:26:39 2012 +0900
@@ -53,7 +53,7 @@
 
 \section{GCC-4.6 への実装}
 GCC における軽量継続は Tail Call Ellimination (末尾除去)を強制することで実装する.
-これにより, コードセグメント間の移動を, call ではなく jmp 命令行う.
+これにより, コードセグメント間の移動を, call ではなく jmp 命令で行う.
 コードセグメント自体には戻値はない.
 
 図\ref{fig:continue}は Tail Call Elimination によるプログラムの処理の流れを表す.
@@ -65,36 +65,26 @@
   \label{fig:continue}
 \end{figure}
 
-\subsection{末尾除去の矯正付与}
-関数が末尾除去にかかる為には, ``呼び出し先関数と呼び出し元関数の方が一致している''
-といったいくつかの条件をクリアしなければならない.
-%といったいくつかの条件をクリアしなければならない.
+\subsection{Tail Call Elimination の矯正付与}
+関数が Tail Call Elimination にかかる為には, ``呼び出し先関数と呼び出し元関数の方が一致している''
+等といった幾つかの条件をクリアしなければならない.
 これまでの実装ではコードセグメントに条件をクリアさせる為, 専用の関数を用意していた.
 しかし今回の実装ではその関数を撤廃し, 末尾除去にかかるフラグを落とさせない
-コードを追加することで末尾除去の条件をクリアさせるようになった.
+コードを追加することで Tail Call Elimination の条件をクリアさせるようになった.
 これにより GCC のアップデート時に伴う専用関数の修正が不要となり, 楽な管理が行えるようになった.
 
 \subsection{環境付き継続}
 CbC には通常の C の関数からコードセグメントに継続する際,
  その関数から値を戻す処理への継続を得ることができる.
 これを環境付き継続という.
-これらは, 以下の二種類の CbC で定義した特殊変数である.
-\_\_environment は, 環境を表す情報である.
-\_\_return は,  これを環境付き継続の行き先であり, 関数の戻値と \_\_environment の二つの引数を持つ
-コードセグメントである. 例えば, 以下のように使うと, \verb+main()+ は 1 を返す.
-
-\begin{verbatim}
-__code c1(__code ret(int,void *),void *env) {
-    goto ret(1,env);
-}
-
-int main() {
-    goto c1(__return, __environment);
-}
-\end{verbatim}
-
-GCC内部では, \verb+__return+ は, 関数内で定義された \verb+_cbc_internal_return+関数へのポインタを返す.
-戻値は, \verb+cbc_internal_return+ 関数内で定義された変数\verb+retval+を通して返される(Listing\ref{code:retval}) .
+環境付き継続は, \verb+__environment+ と \verb+__return+ キーワードを
+引数に渡しコードセグメントとして扱うことで使用できる.
+%\verb+environment+ は 環境を表す情報を持つ.
+%\verb+__return+ は環境付き継続の行き先であり, 関数の戻り値と\verb+__environment+ の二つの引数を
+%持つコードセグメントになる.
+%GCC内部では, \verb+__return+ は, 関数内で定義された \verb+_cbc_internal_return+関数へのポインタを返す.
+%戻値は, \verb+cbc_internal_return+ 関数内で定義された変数\verb+retval+を通して返される(Listing\ref{code:retval}) .
+実際には \verb+__return+ キーワードにより GCC 内部でlisting\ref{code:retval}のコードが生成される.
 \begin{figure}[h]
   \begin{minipage}[b]{.45\textwidth}
     \begin{lstlisting}[caption=環境付き継続を行うコード,label=code:retval]
@@ -134,7 +124,7 @@
 この時\verb+__rectype+は funcPtr を指し, selftype は struct node を指す.
 \begin{figure}[h]
   \begin{minipage}[b]{.45\textwidth}
-    \begin{lstlisting}[caption=\_\_rectype 構文使用例,label=code:rectype]
+    \begin{lstlisting}[caption=\_\_rectype\, selftype 構文の使用例,label=code:rectype]
 typedef __code (*funcPtr)(int,__rectype*);
 struct node {
  int num;
@@ -148,9 +138,9 @@
 \section{評価}
 今回実装を行った GCC-4.6 ベース と安定版である GCC-4.4 ベース,
  それと Micro-C の CbC コンパイラでベンチマークを行った.
-プログラムは Micro-C のベンチマークを使用した. 
-引数 1 は C で書かれたプログラムをただ CbC へと変換したプログラムである.
-引数 2 と 3 は Micro-C 用に手動で最適化を行ったプログラムになる.
+プログラムは Micro-C のベンチマークにも使用されるものである.
+引数 1 は C で書かれたプログラムをただ CbC へと変換したプログラムになる.
+引数 2 と 3 は Micro-C 用に手動で最適化を行ったプログラムである.
 Linux 上で 32bit と 64bit それぞれに最適化オプション(-O2)をつけての評価を行った.
 結果を図\ref{fig:linux_conv}に示す.
 \begin{figure}[htpb]
@@ -165,7 +155,7 @@
 まず, Micro-C 版より GCC 版コンパイラの方が結果が良いことが確認できる.
 GCC-4.5 と GCC-4.6 版を比較してみると手動で最適化を行なっている引数 2 と 3 の結果に余り差はみられない.
 しかし CbC へと変換しただけの引数 1 の場合には GCC-4.6 版が 32bit 版は 2.43倍, 64bit 版は 1.68 倍と優っている.
-これは GCC-4.5 に比べ GCC-4.6 の最適化が修正されている為である. 
+つまり GCC-4.5 に比べ GCC-4.6 の最適化が修正されよりよくなっているのが確認できる.
 
 \section{今後の課題}
 今回, CbC コンパイラを GCC-4.6 へとアップデートを行った.