Mercurial > hg > Papers > 2010 > kent-master

comparison memos/memo.txt @ 10:3d9addf62d0b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
organized repository.
author kent <kent@cr.ie.u-ryukyu.ac.jp>
date Tue, 16 Feb 2010 14:35:36 +0900
parents
children
comparison
equal deleted inserted replaced
9:ae0a3666f7f9 10:3d9addf62d0b
1
2 [研究目的]
3 o 検証に適する言語
4 o Demonstration,分割
5 o ハードウェア記述
6 o → それらを実現するためには継続をベースとした言語が良い
7 o 先行研究
8 - micro-c (mc実装)
9 - gcc (卒論時点での)
10
11 [Continuation based C]
12 o CbCの要求仕様
13 o コードセグメントと継続制御
14 - call-returnから継続へ
15 - コードセグメント
16 - 継続制御 (light-weight continuation)
17 o 状態遷移記述 (河野先生の論文から拝借)
18 o return
19
20 [実装]
21 o tail callを使ったgoto文の実装を簡単に説明(卒論の範囲)
22 o 並列代入
23 o _CbC_returnの実装方法
24
25 [CbCベースTaskManager]
26
27 [評価]
28 o mcとの速度比較
29 - 最適化を行った場合、-fomit-framepointer, noreturn, fastcall
30 - i386,ppc,x86_64,spu
31 # i386なら-O2, omit,fastcallでmcとほぼ同等
32 # レジスタベースのアーキテクチャならさらにいい結果がでる？
33 # ppcはmcの倍早くなる
34 o CbC言語のソースコードの評価
35 - プログラミングの手法などについて
36 # ゲームのようなループベースのソフトウェア記述に有利
37 - スタック操作 ← キンタク先輩の修論を参考に
38 - オブジェクト指向との関係
39 - スパゲティコードとメソッドベース
40
41
42
43
44 CbCの目的
45 多言語 -> CbC -> アセンブラ、ハードウェア
46 Cとの互換性
47 関数の分割としてのコードセグメント
48 コードセグメント単位でのタブロー方を用いた検証
49 最適化
50
51 背景
52 o Demonstration
53 - 継続が重要 キンタク先輩の修論を参考に
54 o タブロー法による検証
55 - アツキ先輩のが詳しい？
56
57
58 やったこと
59 code segmentの追加
60 gotoの実装
61 CbC_return
62
63 評価 quicksortでいいか？
64 cbc-gcc <-> c-gcc
65 cbc-gcc <-> cbc-mc
66
67 environment -> method call ?
68
69 プログラム
70 o 状態遷移ですべてを考える
71 o ある状態を保ってループ
72 o 別の状態に移ってループこの繰り返しがプログラム
73 o これはCbCで記述しやすい
74 o 状態をオブジェクト、ループ構造をメソッドとする
75 o 第一引数を状態を表すオブジェクトとする
76
77
78
79
80
81
82 o micro-cとgccがあった
83 o しかし新しい機能の追加
84 o また、gccにはバグや当初の期待よりも高速化されないという問題が
85 o 本論文では実装手法を説明する
86 o また、micro-cと対比した性能比較をおこなった
87
88
89
90
91
92
93 企業システムの多様化、IT導入の加速により、ソフトウェアは大規模化・複雑
94 化する傾向にある。また家電製品のデジタル化も進み、組み込みシステムの需
95 要も増大している。
96
97 それにともないハードウェアはムーアの法則よろしく驚異的な進歩を遂げ、近
98 年はCPUのマルチコア化が進み、また新たな段階を築こうとしている。
99
100 このハードウェアの進歩に対し、ソフトウェアの開発に用いられる記述言語は
101 オブジェクト指向プログラミングの発明・導入やデザインパターンに見られる
102 技術の集約などが行われ、注目されてきた。
103
104 %しかしながら90年代以降、言語その物に対する大きな変化は見られない。
105
106 オブジェクト指向を主としたJavaはその有用性が認められ多くのシステム開発
107 に取り入られてきたが、その反面 Cなどの低レベルな言語による記述に比べて
108 余分な条件判断やメモリアクセスを増やしてしまう。そのため軽量かつ高速な
109 応答が要求されるReal-time処理や組み込み用途には適さない。
110
111 またCellに見られるような複雑なアーキテクチャをもつマシンではプログラミ
112 ング自体も複雑になる。Cのプログラムから直接アーキテクチャに関わる命令
113 (DMAやシグナル)を使用するのでは、高級言語の設計思想と矛盾すると言わざ
114 るを得ない。
115
116 大規模システムにおけるバグの存在も深刻な問題である。
117 テストファーストな開発スタイルなどで工学的なアプローチからバグの抑制が
118 試みられているが、完全な排除は難しい。数学的なアプローチから無矛盾を証
119 明する技術の研究も進んでいるが、現在のスタックベースのプログラミングは
120 状態数が膨大になり、実用化された例は少ない。さらにマルチコアの台頭によ
121 り検証もより必要性を増すと考えられる。
122
123 ハードウェアの進化、数学的検証にソフトウェアが対応するためにはこれまで
124 とは違う新たな視点を持ったプログラミング言語が望ましい。
125 しかし既存のソフトウェアやシステムは膨大な数に上り、これらを新しい言語
126 に書き換えるのは無理がある。新しいプログラミング言語は古い言語との互換
127 性が必須である。
128
129
130
131 しかし現在
132
133
134 現在の互換性
135
136
137 ソフトウェア開発における種々のテクニックでバグの発生を減らし
138
139
140
141 %オブジェクト指向やリフレクション等の動的変更技術は動的な適合性をもとに
142 %設計されており、Cなどの低レベルな言語による記述に比べて余分な条件判断
143 %を増やしてしまう。この様な言語は
144
145
146
147 システムのソフトウェアを開発する記述言語の方は
148 大規模シス
149 テムの開発に主に使われているコンパイル言語は
150
151
152
153
154
155 [修士期間での作業]
156 o goto のシンタクス
157 ,envの除去
158 return
159 o fastcall
160 o 並列代入
161 expand_call -> parser
162 o PPCのmd
163 - md作成
164 - tailcall制限解除
165 o gimple?
166 o prototypeの自動生成
167 o mercurial管理
168 [成果]
169 o GCCにおけるポータビリティ
170 o GCCの変更についていきやすい
171 o 速度向上!
172
173 卒論時のgccとの比較は可能か？
174 多分quicksortは動かない…
175
176 [評価]
177 o gccで
178 o できれば卒論時のgccと比較
179 o mcとgcc
180
181
182 quicksort 100万要素 x86
183 oldGCC: 2.849
184 GCC: 2.401
185
186
187 TODO:
188 o 用語の統一
189 - gcc, GCC
190 - ppc, PowerPC
191 - mc, micro-c, Micro-C
192 - 末尾呼び出し最適化, tailcall
193 - 継続制御, 軽量継続
194 - 当研究室、本論文
195 o 要旨
196 o 今後の課題
197 o 先行研究、分散プログラミング
198
199
200
201
202 分散プログラミング
203 o 分散プログラミングには様々な手法がある
204 - APIを呼び出す原始的な手法
205 - SOAPなどのライブラリ
206 - 言語仕様への埋め込み
207 - Objectメソッド呼び出しの規格化
208 o それぞれの手法は複雑なセマンティクスを定義する
209 o 通信の複雑なセマンティクスをCbCによって直接記述する
210
211
212
213