# HG changeset patch
# User Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
# Date 1400085905 -32400
# Node ID cfcf8ccd7eb97a30a0f1aea71578b38ff1df472a
# Parent  f2b3fa53dce336a0665563895c386b16f7235002
fix

diff -r f2b3fa53dce3 -r cfcf8ccd7eb9 presen/slide/s6/presen.html
--- a/presen/slide/s6/presen.html	Thu May 15 00:38:40 2014 +0900
+++ b/presen/slide/s6/presen.html	Thu May 15 01:45:05 2014 +0900
@@ -115,8 +115,8 @@
       <div class='slide'>
         <h2>研究背景</h2>
 	<ul>
-	  <li>OS 等のシステムプログラム, Cerium のようなフレームワークはユーザーからの API コールを受けて処理を行うが, 最終的に戻るのはその API.
-	  <li>処理終了後 API に直接戻るのが望ましい.
+	  <li>OS 等のシステムプログラム, Cerium のようなフレームワークはユーザーからの API コールを受けて処理を行う.
+	  <li>処理終了後 API 呼び出し元に直接戻るのが望ましい.
 	  <li>インライン展開の場合は全てのファイルを一度にコンパイルしなければならない.
 	  <li>Tail Call Elimination は必ず行われるとは限らない.
 	  <li>Tail Call Elimination を保証する言語が求められる.
@@ -129,7 +129,7 @@
 	  <li>当研究室では プログラミング言語 CbC を開発している.
 	    <ul>
 	      <li>CbC は Tail Call Elimination を保証する状態遷移ベースの言語.
-	      <li>code segment, data segment という単位を用いて書く.
+	      <li>処理の単位 code segment, データの単位 data segment を用いて書く.
 	      <li>メタプログラミングも可能にする.
 	    </ul>
 	  <li>広く使われるようになってきた LLVM 上で CbC コンパイラを実装する.
@@ -155,9 +155,9 @@
 	  <caption><p>CbC プログラムの例</p></caption>
 	  <tr><td width='50%'>
 	      <pre class='small_code'>
-<div class="highlight">__code code1(int n,__code(*exit_code)(int,void *),void *exit_env){
+<div class="highlight"><font color='red'>__code</font> code1(int n,__code(*exit_code)(int,void *),void *exit_env){
   printf("code1 : code entry1\n");
-  goto exit_code(n,exit_env);
+  <font color='red'>goto exit_code(n,exit_env);</font>
 }</div>
 
 int caller(){
@@ -284,6 +284,7 @@
 
       <div class='slide'>
 	<h2>__code 型の追加</h2>
+	<p>__code 型の追加はパーサーを編集して行う.</p>
 	<div align='center'><img src="fig/clang_llvm_slide_parse.svg" width="70%"></div>
       </div>
 
@@ -293,6 +294,7 @@
 	  <tr><td>
 	<ul>
 	  <li>clang/LLVM 内部では code segment は __code 型の関数として扱う.
+	  <li>code segment は戻り値を持たないので void 型と同じように扱う.
 	  <li>clang と LLVM で型を扱うクラスは別々なので両方に手を加える必要がある. 
 	  <li>clang 側では keyword, ID そして型情報を管理するクラスである Type を作成する.
 	  <li>LLVM 側では 型情報を管理するクラスである Type と ID の作成が必要. 
@@ -306,7 +308,7 @@
     LangOptions* LOP;
     LOP = const_cast<LangOptions*>(&getLangOpts());
     LOP->HasCodeSegment = 1;
-    isInvalid = DS.SetTypeSpecType(DeclSpec::TST___code, Loc, PrevSpec, DiagID);
+    isInvalid = <font color='red'>DS.SetTypeSpecType(DeclSpec::TST___code, Loc, PrevSpec, DiagID);</font>
     break;
   }</pre>
 	  </tr>
@@ -315,6 +317,7 @@
 
       <div class='slide'>
 	<h2>goto syntax の追加</h2>
+	<p>goto syntax の追加もパーサーを編集して行う.</p>
 	<div align='center'><img src="fig/clang_llvm_slide_parse.svg" width="70%"></div>
       </div>
 
@@ -380,6 +383,7 @@
 
       <div class='slide'>
 	<h2>clang/LLVM 間の __code 型の変換</h2>
+	<p>clang の Type が LLVM のものに変わるのは CodeGen の段階.</p>
 	<div align='center'><img src="fig/clang_llvm_slide_cg.svg" width="70%"></div>
       </div>
 
@@ -388,8 +392,8 @@
 	<table width='100%'>
 	  <tr><td>
 	<ul>
-	  <li>clang の Type が LLVM のものに変わるのは CodeGen の段階.
 	  <li>以下が実際に変換を行っている箇所. ABIArgInfo の種類に応じて型の変換をしている.
+	  <li>code segment は戻り値を持たないので void 型と同様に扱う.
 	  <li>Ignore の時 void 型であるので, この時に __code 型かどうかのチェックを加えた.
 	</ul>
 	</tr>
@@ -421,6 +425,8 @@
 
       <div class='slide'>
 	<h2>Tail Call Elimination の強制</h2>
+	<p>最適化の有効化は CodeGen で行う.</p>
+	<p>TCE pass は SelectionDAGISel で行われる最適化.</p>
 	<div align='center'><img src="fig/clang_llvm_slide_cg_DAG.svg" width="70%"></div>
       </div>
 
@@ -444,6 +450,7 @@
 
       <div class='slide'>
 	<h2>環境付き継続</h2>
+	<p>環境付き継続の実装はパーサーを編集する.</p>
 	<div align='center'><img src="fig/clang_llvm_slide_parse.svg" width="70%"></div>
       </div>
 
@@ -452,8 +459,8 @@
 	<table width='100%'>
 	  <tr><td valign='top'>
 	<ul>
+	  <li>C の関数から code segment に継続した後, 継続元の関数を呼び出した関数に戻るための機能.
 	  <li>__return, __environment という二つのキーワードを利用して実現.
-	  <li>C の関数から code segment に継続した後, C 元の関数を呼び出した関数に戻るための機能.
 	  <li>以下のコードの場合, caller から継続した code1 は環境付き継続を用いて caller の呼び出し元である main に戻る.
 	  <li>GCC 上に実装した CbC コンパイラは nested function を使用していたが clang はこの構文を受け付けない.
 	  <li>setjmp/longjmp を用いて実装.
@@ -551,6 +558,7 @@
 
       <div class='slide'>
 	<h2>アセンブリコードの確認</h2>
+	<p>Tail Call Elimination が強制されているかどうかをアセンブリコードから判断する.</p>
 	<table width='100%' align='center' border='1'>
 	  <tr>
 	    <td>コンパイル前
@@ -598,9 +606,7 @@
 	      <li>通常の関数呼び出しを行うコードを継続で実装したプログラム. 
 	    </ul>
 	  <li>引数に応じて純粋に変換した場合とスタックを削り最適化を行った場合のコードどちらを実行するかを選択. 
-	    <ul>
-	      <li>引数 1 の時には CbC の継続を使用, 引数 2, 3 の時には Micro-C のための最適化が手動で施されたコードを使用する.
-	    </ul>
+	  <li>インライン展開は無効化している.
 	</ul>
 	<table width='80%' align='center' border='1'>
 	  <tr>
@@ -634,11 +640,13 @@
 	    <td>2.5087
 	  </tr>
 	</table>
+	<table width='80%' align='center' border='0'>
+	  <tr><td align='right'>単位 : 秒</tr>
+	</table>
 	<ul>
-	  <li>インライン展開は無効化している.
 	  <li>最適化の有無で比較すると, 最適化有りのほうが二倍以上速い.
-	  <li>Micro-C と比較すると, 最適化無しでは劣ることもあるが最適化を有効化すると全ての場合で LLVM/clang の方が速くなる.
-	  <li>GCC と比較すると, 速度面では劣るが, 最適化を無効化してもプログラムが正常に動作するという点で優位.
+	  <li>Micro-C と比較すると, 最適化無しでは劣ることもあるが<font color='red'>最適化を有効化すると全ての場合で LLVM/clang の方が速くなる</font>.
+	  <li>GCC と比較すると, 速度面では劣るが, <font color='red'>最適化を無効化してもプログラムが正常に動作する</font>という点で優位.
 	</ul>
       </div>
 
@@ -672,7 +680,7 @@
 	    </ul>
 	  <li>CbC によるプログラムの作成
 	    <ul>
-	      <li>並列プログラミングフレーム Cerium.
+	      <li>並列プログラミングフレームワーク Cerium.
 	    </ul>
 	</ul>
       </div>