--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/memos/memo.txt	Tue Feb 16 14:35:36 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によって直接記述する
+
+
+
+