--- a/memos/memo.txt	Tue Feb 16 14:40:12 2010 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,213 +0,0 @@
-
-[研究目的]
-  o 検証に適する言語
-  o Demonstration,分割
-  o ハードウェア記述
-  o → それらを実現するためには継続をベースとした言語が良い
-  o 先行研究
-    - micro-c (mc実装)
-    - gcc (卒論時点での)
-
-[Continuation based C]
-  o CbCの要求仕様
-  o コードセグメントと継続制御
-    - call-returnから継続へ
-    - コードセグメント
-    - 継続制御 (light-weight continuation)
-  o 状態遷移記述 (河野先生の論文から拝借)
-  o return
-
-[実装]
-  o tail callを使ったgoto文の実装を簡単に説明(卒論の範囲)
-  o 並列代入
-  o _CbC_returnの実装方法
-
-[CbCベースTaskManager]
-
-[評価]
-  o mcとの速度比較
-    - 最適化を行った場合、-fomit-framepointer, noreturn, fastcall
-    - i386,ppc,x86_64,spu
-      # i386なら-O2, omit,fastcallでmcとほぼ同等
-      # レジスタベースのアーキテクチャならさらにいい結果がでる？
-      # ppcはmcの倍早くなる
-  o CbC言語のソースコードの評価
-    - プログラミングの手法などについて
-      # ゲームのようなループベースのソフトウェア記述に有利
-    - スタック操作 ← キンタク先輩の修論を参考に
-    - オブジェクト指向との関係
-    - スパゲティコードとメソッドベース
-
-
-
-
-CbCの目的
-  多言語 -> CbC -> アセンブラ、ハードウェア
-  Cとの互換性
-  関数の分割としてのコードセグメント
-  コードセグメント単位でのタブロー方を用いた検証
-  最適化
-
-背景
-  o Demonstration
-    - 継続が重要 キンタク先輩の修論を参考に
-  o タブロー法による検証
-    - アツキ先輩のが詳しい？
-
-
-やったこと
-  code segmentの追加
-  gotoの実装
-  CbC_return
-
-評価 quicksortでいいか？
-  cbc-gcc <-> c-gcc
-  cbc-gcc <-> cbc-mc
-
-environment -> method call ?
-
-プログラム
-  o 状態遷移ですべてを考える
-  o ある状態を保ってループ
-  o 別の状態に移ってループこの繰り返しがプログラム
-  o これはCbCで記述しやすい
-  o 状態をオブジェクト、ループ構造をメソッドとする
-  o 第一引数を状態を表すオブジェクトとする
-
-
-
-
-
-
- o micro-cとgccがあった
- o しかし新しい機能の追加
- o また、gccにはバグや当初の期待よりも高速化されないという問題が
- o 本論文では実装手法を説明する
- o また、micro-cと対比した性能比較をおこなった
-
-
-
-
-
-
-企業システムの多様化、IT導入の加速により、ソフトウェアは大規模化・複雑
-化する傾向にある。また家電製品のデジタル化も進み、組み込みシステムの需
-要も増大している。
-
-それにともないハードウェアはムーアの法則よろしく驚異的な進歩を遂げ、近
-年はCPUのマルチコア化が進み、また新たな段階を築こうとしている。
-
-このハードウェアの進歩に対し、ソフトウェアの開発に用いられる記述言語は
-オブジェクト指向プログラミングの発明・導入やデザインパターンに見られる
-技術の集約などが行われ、注目されてきた。
-
-%しかしながら90年代以降、言語その物に対する大きな変化は見られない。
-
-オブジェクト指向を主としたJavaはその有用性が認められ多くのシステム開発
-に取り入られてきたが、その反面 Cなどの低レベルな言語による記述に比べて
-余分な条件判断やメモリアクセスを増やしてしまう。そのため軽量かつ高速な
-応答が要求されるReal-time処理や組み込み用途には適さない。
-
-またCellに見られるような複雑なアーキテクチャをもつマシンではプログラミ
-ング自体も複雑になる。Cのプログラムから直接アーキテクチャに関わる命令
-(DMAやシグナル)を使用するのでは、高級言語の設計思想と矛盾すると言わざ
-るを得ない。
-
-大規模システムにおけるバグの存在も深刻な問題である。
-テストファーストな開発スタイルなどで工学的なアプローチからバグの抑制が
-試みられているが、完全な排除は難しい。数学的なアプローチから無矛盾を証
-明する技術の研究も進んでいるが、現在のスタックベースのプログラミングは
-状態数が膨大になり、実用化された例は少ない。さらにマルチコアの台頭によ
-り検証もより必要性を増すと考えられる。
-
-ハードウェアの進化、数学的検証にソフトウェアが対応するためにはこれまで
-とは違う新たな視点を持ったプログラミング言語が望ましい。
-しかし既存のソフトウェアやシステムは膨大な数に上り、これらを新しい言語
-に書き換えるのは無理がある。新しいプログラミング言語は古い言語との互換
-性が必須である。
-
-
-
-しかし現在
-
-
-現在の互換性
-
-
-ソフトウェア開発における種々のテクニックでバグの発生を減らし
-
-
-
-%オブジェクト指向やリフレクション等の動的変更技術は動的な適合性をもとに
-%設計されており、Cなどの低レベルな言語による記述に比べて余分な条件判断
-%を増やしてしまう。この様な言語は
-
-
-
-システムのソフトウェアを開発する記述言語の方は
-大規模シス
-テムの開発に主に使われているコンパイル言語は
-
-
-
-
-
-[修士期間での作業]
- o goto のシンタクス
-   ,envの除去
-   return
- o fastcall
- o 並列代入
-   expand_call -> parser
- o PPCのmd
-   - md作成
-   - tailcall制限解除
- o gimple?
- o prototypeの自動生成
- o mercurial管理
-[成果]
- o GCCにおけるポータビリティ
- o GCCの変更についていきやすい
- o 速度向上!
- 
-卒論時のgccとの比較は可能か？
-多分quicksortは動かない…
-
-[評価]
- o gccで
- o できれば卒論時のgccと比較
- o mcとgcc
-
-
-quicksort  100万要素 x86
-oldGCC: 2.849
-GCC: 2.401
-
-
-TODO: 
- o 用語の統一
-   - gcc, GCC
-   - ppc, PowerPC
-   - mc, micro-c, Micro-C
-   - 末尾呼び出し最適化, tailcall
-   - 継続制御, 軽量継続
-   - 当研究室、本論文
- o 要旨
- o 今後の課題
- o 先行研究、分散プログラミング
-
-
-
-
-分散プログラミング
- o 分散プログラミングには様々な手法がある
-   - APIを呼び出す原始的な手法
-   - SOAPなどのライブラリ
-   - 言語仕様への埋め込み
-   - Objectメソッド呼び出しの規格化
- o それぞれの手法は複雑なセマンティクスを定義する
- o 通信の複雑なセマンティクスをCbCによって直接記述する
-
-
-
-

--- a/memos/アツキ先輩の修士論文要旨.txt	Tue Feb 16 14:40:12 2010 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,70 +0,0 @@
-
-論文構成
-  o 序論
-    - 背景と目的
-    - 論文構成
-  o Continuation based C と検証
-    - CbCとは
-    - タブロー方によるプログラムの状態の展開
-    - ソフトウェアの検証
-    - 並列プログラムにおける検証
-    - 線形時相論理による検証
-    - 他のモデル検証ツール
-  o 線形時相論理によるCbCプログラムの検証手法
-    - CbCによる並列プログラミング
-    - CbCプログラムのタブロー展開
-    - 線形時相論理による仕様の検証手法
-  o 評価と考察
-    - 実行環境と評価方法
-    - DPPのタブロー展開
-    - 線形時相論理を用いた検証
-  o 結論
-
-
-
-[序論]
-  研究の背景と目的
-    並列プログラムのデバグは困難、デバグ手法や検証手法の確立が課題
-    CbCでの検証手法を提案
-    CbCは状態遷移記述 → 状態をタブロー方で展開して時相論理で検証
-  論文構成
-    2章: CbCの概要、タブロー法、線形時相論理の説明
-    3章: CbCのタブロー展開の手法、線形時相論理によるCbCの検証手法
-    4章: プログラム評価・考察、他の検査ツールとの比較
-    5章: まとめ
-
-[Continuation based Cと検証]
-  CbCとは
-    要求仕様(キンタク先輩とおなじ)
-  タブロー方によるプログラムの状態の展開
-    プログラムの大域的な状態をすべて列挙
-    判例は一つ見つければいいが、証明にはすべての状態を生成する
-    現状態から非決定的に生成されるすべての状態を生成することを展開という
-  ソフトウェアの検証
-    「期待された動き」が仕様、自然言語や論理で記述。それにそわないものはバグ
-    テストではある種のバグを発見できるがバグがないことを証明できない
-    検証はソフトウェアが仕様を満たすことを数学的、論理的に確かめること
-  並列プログラムにおける検証
-    各々のスレッドは決定的であってもそれぞれ動けば非決定的になる
-    各スレッドをCbCで記述し、実行制御のスケジューラを用いる
-    その並列実行をタブロー展開する
-  線形時相論理による検証
-    linear temporal logicの紹介。でも使い方はわかんない
-  他のモデル検査ツール
-    SPIN
-    JPF
-[線形時相論理によるCbCプログラムの検証手法]
-  CbCによる並列プログラミング
-    DPPをCbCでプログラム
-    スケジューラ
-  CbCプログラムのタブロー展開
-    実行の組み合わせ全てを調べる
-    状態探索はDFS
-    タブロー展開機の実装
-      メモリ構造、binary tree (binaryでいいのか？)
-      スケジューラを内包、実行順序を制御する
-  線形時相論理による仕様の検証手法
-
-
-
-

--- a/memos/キンタク先輩の修士論文要旨.txt	Tue Feb 16 14:40:12 2010 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,120 +0,0 @@
-
-キンタク先輩の修士論文メモ
-論文構成
-  o 序論
-    - 研究の目的と背景
-    - 論文構成
-  o 新しいリファクタリングの単位
-    - 緒言
-    - Demonstration
-    - Demonstrationと関数型言語
-    - 継続
-  o Continuation based C
-    - CbCの要求仕様
-    - 軽量継続
-    - C with Continuation
-  o 実際のゲームプログラムのCbC変換と変換手順の説明
-    - サンプルの説明
-    - CからCbCへのプログラム変換
-  o 評価
-    - 緒言
-    - 実行時間比較
-    - ソースコードの比較と評価
-    - CbC記述のDemonstrationの結合
-    - 継続の独立性
-    - 結論
-
-[序論]
-  目的
-    o ゲームプログラミングはアーキテクチャ依存が強い
-    o そのためアーキテクチャ間での移植性は低い
-    o しかし小規模なプログラムの移植は難しくない
-    o ゲームプログラム全体を小規模なプログラムの集合に分割
-    o 移植性の向上を目指す
-
-  ゲームプログラムの外観
-    while true:
-	  receive data from input devices
-	  foreach (Game objects):
-	    update the Object.
-		register a command for rendering.
-	  change buffer
-	  do rendering commands.
-	  wait next turn.
-    waitでは画面の垂直同期1/30secをまつ
-    そのためすべての更新はこの間に行われなければならない
-
-  ゲーム機毎のプログラミングの違い
-
-  ゲームの定義
-    ノウハウを得るには1年は必要
-
-  移植の重要性
-  リファクタリング
-    リファクタリングによる分割
-  Design Pattern
-    Adapter Patternの紹介
-
-  過去の移植例 PS ==> PS3
-    1 依存レイヤーと非依存レイヤーへの分割
-    2 依存レイヤーをPS2依存に書き換える
-    3 依存レイヤーと非依存レイヤーの間にAdapterを挿入
-    o そもそも依存と非依存の分割が難しい
-
-  オブジェクト指向の受け入れられない理由
-    o 毎ターンtree構造をたどるのはCPU資源の無駄
-    o ゲームではオブジェクト間の関係が強いので状態がオブジェクトに閉じない
-
-  論文構成
-    2章: 提案
-    3章: 実現するための言語CbCの紹介
-    4章: C2CbCの手法
-    5章: CbCの評価、利点
-    6章: まとめ
-
-[新しいリファクタリングの単位]
-  緒言
-    小規模なプログラムの移植は難しくない
-    以下でゲームプログラムに特化したプログラム分割を提案する
-  Demonstration
-    ゲームプログラムは実行可能なまま分割する必要がある ==> Demonstration
-    自由に複数を結合、分割でき、全体を結合することでゲームプログラムが完成する
-    結合分解を繰り返すことで開発や移植を進めやすくする
-  関数で作成したDemonstrationの結合
-    それぞれのDemonstrationの関数をシーケンシャルに呼び出す
-    しかし、細分化するとネストするので処理効率が悪い、スタックメモリも多すぎる
-  関数にインライン展開するDemonstrationの結合
-    この方が資源の無駄にはならないが、分割が難しくなる
-  継続
-    call-returnはDemonstrationに合わない
-
-[Continuation based C]
-  要求仕様
-    
-[実際のゲームプログラムのCbC変換と変換手順の説明]
-  S-Dandyの紹介、プログラムの概要
-  C to CbC
-  whileの変換
-  forの変換
-  関数の変換
-  スタック 静的な配列を用いたスタックの記述
-
-[評価]
-  Cのままのs-dandyでのgccとmcの比較
-  CbC形式に変更したs-dandyの
-    sample1 大域変数使用
-    sample2 interface使用
-    sample3 スタック使用
-  ソースコードの比較と評価
-    scheduleのCbC変換
-    moveのCbC変換
-  CbC記述のDemonstrationの結合
-  継続の独立性
-    APIによりコードセグメントの独立性がなくなる
-  結論
-    mcはgcc(最適化)に比べて14%ほど遅い
-    最適化なしだとほぼ同程度、実用に充分
-    CbCはDemonstrationの記述に適している
-
-[まとめと今後の課題]
-

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/memos/memo.txt	Tue Feb 16 14:43:52 2010 +0900
@@ -0,0 +1,213 @@
+
+[研究目的]
+  o 検証に適する言語
+  o Demonstration,分割
+  o ハードウェア記述
+  o → それらを実現するためには継続をベースとした言語が良い
+  o 先行研究
+    - micro-c (mc実装)
+    - gcc (卒論時点での)
+
+[Continuation based C]
+  o CbCの要求仕様
+  o コードセグメントと継続制御
+    - call-returnから継続へ
+    - コードセグメント
+    - 継続制御 (light-weight continuation)
+  o 状態遷移記述 (河野先生の論文から拝借)
+  o return
+
+[実装]
+  o tail callを使ったgoto文の実装を簡単に説明(卒論の範囲)
+  o 並列代入
+  o _CbC_returnの実装方法
+
+[CbCベースTaskManager]
+
+[評価]
+  o mcとの速度比較
+    - 最適化を行った場合、-fomit-framepointer, noreturn, fastcall
+    - i386,ppc,x86_64,spu
+      # i386なら-O2, omit,fastcallでmcとほぼ同等
+      # レジスタベースのアーキテクチャならさらにいい結果がでる？
+      # ppcはmcの倍早くなる
+  o CbC言語のソースコードの評価
+    - プログラミングの手法などについて
+      # ゲームのようなループベースのソフトウェア記述に有利
+    - スタック操作 ← キンタク先輩の修論を参考に
+    - オブジェクト指向との関係
+    - スパゲティコードとメソッドベース
+
+
+
+
+CbCの目的
+  多言語 -> CbC -> アセンブラ、ハードウェア
+  Cとの互換性
+  関数の分割としてのコードセグメント
+  コードセグメント単位でのタブロー方を用いた検証
+  最適化
+
+背景
+  o Demonstration
+    - 継続が重要 キンタク先輩の修論を参考に
+  o タブロー法による検証
+    - アツキ先輩のが詳しい？
+
+
+やったこと
+  code segmentの追加
+  gotoの実装
+  CbC_return
+
+評価 quicksortでいいか？
+  cbc-gcc <-> c-gcc
+  cbc-gcc <-> cbc-mc
+
+environment -> method call ?
+
+プログラム
+  o 状態遷移ですべてを考える
+  o ある状態を保ってループ
+  o 別の状態に移ってループこの繰り返しがプログラム
+  o これはCbCで記述しやすい
+  o 状態をオブジェクト、ループ構造をメソッドとする
+  o 第一引数を状態を表すオブジェクトとする
+
+
+
+
+
+
+ o micro-cとgccがあった
+ o しかし新しい機能の追加
+ o また、gccにはバグや当初の期待よりも高速化されないという問題が
+ o 本論文では実装手法を説明する
+ o また、micro-cと対比した性能比較をおこなった
+
+
+
+
+
+
+企業システムの多様化、IT導入の加速により、ソフトウェアは大規模化・複雑
+化する傾向にある。また家電製品のデジタル化も進み、組み込みシステムの需
+要も増大している。
+
+それにともないハードウェアはムーアの法則よろしく驚異的な進歩を遂げ、近
+年はCPUのマルチコア化が進み、また新たな段階を築こうとしている。
+
+このハードウェアの進歩に対し、ソフトウェアの開発に用いられる記述言語は
+オブジェクト指向プログラミングの発明・導入やデザインパターンに見られる
+技術の集約などが行われ、注目されてきた。
+
+%しかしながら90年代以降、言語その物に対する大きな変化は見られない。
+
+オブジェクト指向を主としたJavaはその有用性が認められ多くのシステム開発
+に取り入られてきたが、その反面 Cなどの低レベルな言語による記述に比べて
+余分な条件判断やメモリアクセスを増やしてしまう。そのため軽量かつ高速な
+応答が要求されるReal-time処理や組み込み用途には適さない。
+
+またCellに見られるような複雑なアーキテクチャをもつマシンではプログラミ
+ング自体も複雑になる。Cのプログラムから直接アーキテクチャに関わる命令
+(DMAやシグナル)を使用するのでは、高級言語の設計思想と矛盾すると言わざ
+るを得ない。
+
+大規模システムにおけるバグの存在も深刻な問題である。
+テストファーストな開発スタイルなどで工学的なアプローチからバグの抑制が
+試みられているが、完全な排除は難しい。数学的なアプローチから無矛盾を証
+明する技術の研究も進んでいるが、現在のスタックベースのプログラミングは
+状態数が膨大になり、実用化された例は少ない。さらにマルチコアの台頭によ
+り検証もより必要性を増すと考えられる。
+
+ハードウェアの進化、数学的検証にソフトウェアが対応するためにはこれまで
+とは違う新たな視点を持ったプログラミング言語が望ましい。
+しかし既存のソフトウェアやシステムは膨大な数に上り、これらを新しい言語
+に書き換えるのは無理がある。新しいプログラミング言語は古い言語との互換
+性が必須である。
+
+
+
+しかし現在
+
+
+現在の互換性
+
+
+ソフトウェア開発における種々のテクニックでバグの発生を減らし
+
+
+
+%オブジェクト指向やリフレクション等の動的変更技術は動的な適合性をもとに
+%設計されており、Cなどの低レベルな言語による記述に比べて余分な条件判断
+%を増やしてしまう。この様な言語は
+
+
+
+システムのソフトウェアを開発する記述言語の方は
+大規模シス
+テムの開発に主に使われているコンパイル言語は
+
+
+
+
+
+[修士期間での作業]
+ o goto のシンタクス
+   ,envの除去
+   return
+ o fastcall
+ o 並列代入
+   expand_call -> parser
+ o PPCのmd
+   - md作成
+   - tailcall制限解除
+ o gimple?
+ o prototypeの自動生成
+ o mercurial管理
+[成果]
+ o GCCにおけるポータビリティ
+ o GCCの変更についていきやすい
+ o 速度向上!
+ 
+卒論時のgccとの比較は可能か？
+多分quicksortは動かない…
+
+[評価]
+ o gccで
+ o できれば卒論時のgccと比較
+ o mcとgcc
+
+
+quicksort  100万要素 x86
+oldGCC: 2.849
+GCC: 2.401
+
+
+TODO: 
+ o 用語の統一
+   - gcc, GCC
+   - ppc, PowerPC
+   - mc, micro-c, Micro-C
+   - 末尾呼び出し最適化, tailcall
+   - 継続制御, 軽量継続
+   - 当研究室、本論文
+ o 要旨
+ o 今後の課題
+ o 先行研究、分散プログラミング
+
+
+
+
+分散プログラミング
+ o 分散プログラミングには様々な手法がある
+   - APIを呼び出す原始的な手法
+   - SOAPなどのライブラリ
+   - 言語仕様への埋め込み
+   - Objectメソッド呼び出しの規格化
+ o それぞれの手法は複雑なセマンティクスを定義する
+ o 通信の複雑なセマンティクスをCbCによって直接記述する
+
+
+
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/memos/アツキ先輩の修士論文要旨.txt	Tue Feb 16 14:43:52 2010 +0900
@@ -0,0 +1,70 @@
+
+論文構成
+  o 序論
+    - 背景と目的
+    - 論文構成
+  o Continuation based C と検証
+    - CbCとは
+    - タブロー方によるプログラムの状態の展開
+    - ソフトウェアの検証
+    - 並列プログラムにおける検証
+    - 線形時相論理による検証
+    - 他のモデル検証ツール
+  o 線形時相論理によるCbCプログラムの検証手法
+    - CbCによる並列プログラミング
+    - CbCプログラムのタブロー展開
+    - 線形時相論理による仕様の検証手法
+  o 評価と考察
+    - 実行環境と評価方法
+    - DPPのタブロー展開
+    - 線形時相論理を用いた検証
+  o 結論
+
+
+
+[序論]
+  研究の背景と目的
+    並列プログラムのデバグは困難、デバグ手法や検証手法の確立が課題
+    CbCでの検証手法を提案
+    CbCは状態遷移記述 → 状態をタブロー方で展開して時相論理で検証
+  論文構成
+    2章: CbCの概要、タブロー法、線形時相論理の説明
+    3章: CbCのタブロー展開の手法、線形時相論理によるCbCの検証手法
+    4章: プログラム評価・考察、他の検査ツールとの比較
+    5章: まとめ
+
+[Continuation based Cと検証]
+  CbCとは
+    要求仕様(キンタク先輩とおなじ)
+  タブロー方によるプログラムの状態の展開
+    プログラムの大域的な状態をすべて列挙
+    判例は一つ見つければいいが、証明にはすべての状態を生成する
+    現状態から非決定的に生成されるすべての状態を生成することを展開という
+  ソフトウェアの検証
+    「期待された動き」が仕様、自然言語や論理で記述。それにそわないものはバグ
+    テストではある種のバグを発見できるがバグがないことを証明できない
+    検証はソフトウェアが仕様を満たすことを数学的、論理的に確かめること
+  並列プログラムにおける検証
+    各々のスレッドは決定的であってもそれぞれ動けば非決定的になる
+    各スレッドをCbCで記述し、実行制御のスケジューラを用いる
+    その並列実行をタブロー展開する
+  線形時相論理による検証
+    linear temporal logicの紹介。でも使い方はわかんない
+  他のモデル検査ツール
+    SPIN
+    JPF
+[線形時相論理によるCbCプログラムの検証手法]
+  CbCによる並列プログラミング
+    DPPをCbCでプログラム
+    スケジューラ
+  CbCプログラムのタブロー展開
+    実行の組み合わせ全てを調べる
+    状態探索はDFS
+    タブロー展開機の実装
+      メモリ構造、binary tree (binaryでいいのか？)
+      スケジューラを内包、実行順序を制御する
+  線形時相論理による仕様の検証手法
+
+
+
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paper/memos/キンタク先輩の修士論文要旨.txt	Tue Feb 16 14:43:52 2010 +0900
@@ -0,0 +1,120 @@
+
+キンタク先輩の修士論文メモ
+論文構成
+  o 序論
+    - 研究の目的と背景
+    - 論文構成
+  o 新しいリファクタリングの単位
+    - 緒言
+    - Demonstration
+    - Demonstrationと関数型言語
+    - 継続
+  o Continuation based C
+    - CbCの要求仕様
+    - 軽量継続
+    - C with Continuation
+  o 実際のゲームプログラムのCbC変換と変換手順の説明
+    - サンプルの説明
+    - CからCbCへのプログラム変換
+  o 評価
+    - 緒言
+    - 実行時間比較
+    - ソースコードの比較と評価
+    - CbC記述のDemonstrationの結合
+    - 継続の独立性
+    - 結論
+
+[序論]
+  目的
+    o ゲームプログラミングはアーキテクチャ依存が強い
+    o そのためアーキテクチャ間での移植性は低い
+    o しかし小規模なプログラムの移植は難しくない
+    o ゲームプログラム全体を小規模なプログラムの集合に分割
+    o 移植性の向上を目指す
+
+  ゲームプログラムの外観
+    while true:
+	  receive data from input devices
+	  foreach (Game objects):
+	    update the Object.
+		register a command for rendering.
+	  change buffer
+	  do rendering commands.
+	  wait next turn.
+    waitでは画面の垂直同期1/30secをまつ
+    そのためすべての更新はこの間に行われなければならない
+
+  ゲーム機毎のプログラミングの違い
+
+  ゲームの定義
+    ノウハウを得るには1年は必要
+
+  移植の重要性
+  リファクタリング
+    リファクタリングによる分割
+  Design Pattern
+    Adapter Patternの紹介
+
+  過去の移植例 PS ==> PS3
+    1 依存レイヤーと非依存レイヤーへの分割
+    2 依存レイヤーをPS2依存に書き換える
+    3 依存レイヤーと非依存レイヤーの間にAdapterを挿入
+    o そもそも依存と非依存の分割が難しい
+
+  オブジェクト指向の受け入れられない理由
+    o 毎ターンtree構造をたどるのはCPU資源の無駄
+    o ゲームではオブジェクト間の関係が強いので状態がオブジェクトに閉じない
+
+  論文構成
+    2章: 提案
+    3章: 実現するための言語CbCの紹介
+    4章: C2CbCの手法
+    5章: CbCの評価、利点
+    6章: まとめ
+
+[新しいリファクタリングの単位]
+  緒言
+    小規模なプログラムの移植は難しくない
+    以下でゲームプログラムに特化したプログラム分割を提案する
+  Demonstration
+    ゲームプログラムは実行可能なまま分割する必要がある ==> Demonstration
+    自由に複数を結合、分割でき、全体を結合することでゲームプログラムが完成する
+    結合分解を繰り返すことで開発や移植を進めやすくする
+  関数で作成したDemonstrationの結合
+    それぞれのDemonstrationの関数をシーケンシャルに呼び出す
+    しかし、細分化するとネストするので処理効率が悪い、スタックメモリも多すぎる
+  関数にインライン展開するDemonstrationの結合
+    この方が資源の無駄にはならないが、分割が難しくなる
+  継続
+    call-returnはDemonstrationに合わない
+
+[Continuation based C]
+  要求仕様
+    
+[実際のゲームプログラムのCbC変換と変換手順の説明]
+  S-Dandyの紹介、プログラムの概要
+  C to CbC
+  whileの変換
+  forの変換
+  関数の変換
+  スタック 静的な配列を用いたスタックの記述
+
+[評価]
+  Cのままのs-dandyでのgccとmcの比較
+  CbC形式に変更したs-dandyの
+    sample1 大域変数使用
+    sample2 interface使用
+    sample3 スタック使用
+  ソースコードの比較と評価
+    scheduleのCbC変換
+    moveのCbC変換
+  CbC記述のDemonstrationの結合
+  継続の独立性
+    APIによりコードセグメントの独立性がなくなる
+  結論
+    mcはgcc(最適化)に比べて14%ほど遅い
+    最適化なしだとほぼ同程度、実用に充分
+    CbCはDemonstrationの記述に適している
+
+[まとめと今後の課題]
+

--- a/quicksort/Makefile	Tue Feb 16 14:40:12 2010 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,26 +0,0 @@
-
-CbCC=cbc-gcc
-
-#CC=gcc
-CC=cbc-gcc
-
-# fastcall版では-O0,-O2は動作確認、-O3以上はだめ
-#CFLAGS=-O2 -fomit-frame-pointer -fno-optimize-sibling-calls
-#CFLAGS=-g -O2
-#CFLAGS=-g -O1
-CFLAGS=-g -O0
-#CFLAGS=-Os # an error occurred.
-
-.SUFFIXES: .cbc .o
-
-all: quicksort_cbc 
-
-.cbc.o:
-	$(CbCC) $(CFLAGS) -c -o $@ $<
-
-
-quicksort_cbc: quicksort_cbc.o quicksort_test.o
-	$(CC) $(CFLAGS) -o $@ $^
-
-clean: 
-	rm -rf *.o *.s quicksort_c quicksort_cbc quicksort_cbc2