Mercurial > hg > Papers > 2010 > kent-master
annotate memo.txt @ 5:dfb89e32eea1
added gcc.tex, conclusion.tex
and some sources.
writed abstraction.
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 08 Feb 2010 00:35:58 +0900 |
parents | 30c102343b37 |
children |
rev | line source |
---|---|
0 | 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 | |
2 | 182 quicksort 100万要素 x86 |
183 oldGCC: 2.849 | |
184 GCC: 2.401 | |
0 | 185 |
186 | |
1 | 187 TODO: |
188 o 用語の統一 | |
189 - gcc, GCC | |
190 - ppc, PowerPC | |
4 | 191 - mc, micro-c, Micro-C |
1 | 192 - 末尾呼び出し最適化, tailcall |
193 - 継続制御, 軽量継続 | |
4 | 194 - 当研究室、本論文 |
195 o 要旨 | |
5
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
196 o 今後の課題 |
4 | 197 o 先行研究、分散プログラミング |
2 | 198 |
199 | |
200 | |
201 | |
5
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
202 分散プログラミング |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
203 o 分散プログラミングには様々な手法がある |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
204 - APIを呼び出す原始的な手法 |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
205 - SOAPなどのライブラリ |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
206 - 言語仕様への埋め込み |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
207 - Objectメソッド呼び出しの規格化 |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
208 o それぞれの手法は複雑なセマンティクスを定義する |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
209 o 通信の複雑なセマンティクスをCbCによって直接記述する |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
210 |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
211 |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
212 |
dfb89e32eea1
added gcc.tex, conclusion.tex
kent <kent@cr.ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
213 |