Mercurial > hg > CbC > old > device
annotate Changes @ 165:6409ff6bc219 short-support-first
short
| author | kono |
|---|---|
| date | Mon, 24 Nov 2003 10:42:03 +0900 |
| parents | 1c2a9232ea93 |
| children | 9e55cc5551fb |
| rev | line source |
|---|---|
| 59 | 1 |
| 2 Thu Nov 25 17:27:12 JST 1999 | |
| 3 | |
| 4 subroutine call がない | |
| 5 局所変数もない | |
| 6 その代わり、大域変数を多用する | |
| 7 大域変数のスコープは局所的 | |
| 8 Fortran の用に局所変数は静的に取る | |
| 9 recursion する時には、自分で保存する | |
| 10 subroutine call時のレジスタのセーブも局所的に行う | |
| 11 それは、ちょっと変じゃない? | |
| 12 やっぱりデフォルトのフレームは持ち歩くか? | |
| 13 | |
| 14 recursive call とそうでないのを区別するか? | |
| 15 | |
| 16 fp は用意する方が良い | |
| 17 | |
| 18 関数定義と同時に、それ専用のfpの構造体を用意する | |
| 19 | |
| 20 C をcompileする時には、stackを持ち歩く | |
| 21 fp = (struct func_state *)stack | |
| 22 えっと、どこに代入するの? そういう問題もあるわけね。 | |
| 23 じゃあ、fpは特別? それは気に入らないな。static | |
| 24 なfpにすれば良いわけね。 | |
| 25 | |
| 26 func(void *stack) { | |
| 27 static struct func_state { | |
| 28 static struct func_state *fp; | |
| 29 int local1; | |
| 30 brahbrah... | |
| 31 } func_state; // ここまで hidden | |
| 32 func_state.fp = (stack -= sizeof(struct func_state)); | |
| 33 } | |
| 34 | |
| 35 func_state をとってくる演算子があった方が良い? そうね。 | |
| 36 func.state | |
| 37 ぐらい? | |
| 38 | |
| 39 fp->local1 みたいなことだけするなら、C と同じになる。 | |
| 40 | |
| 41 call する時のarguemnt も、 | |
| 42 static な func_state に置く | |
| 43 stack 上の func_state に置く | |
| 44 という二通りの選択肢がある。Cと互換なら、当然、後者。 | |
| 45 | |
| 46 Recursive なら後者だが、この言語は状態遷移を記述するから、static | |
| 47 なものでも良いはず。 | |
| 48 | |
| 49 Internal function は? あってもいいんだけど... | |
| 50 | |
| 51 Recursive call する時には、 fp をsaveする必要があるね。 | |
| 52 (--(struct func_state *)stack) = fp; | |
| 53 call callee(&fp->arg,continuation,stack); | |
| 54 call しても、戻って来ないから... continuation は一般的にはcode | |
| 55 だから... それは Internal function にするか。 | |
| 56 | |
| 57 continuation に一般的にcompileする方法を考えないといけないか。 | |
| 58 self は必要なわけね? | |
| 59 | |
| 60 言語の名前も考えないといかんなぁ。 | |
| 61 | |
| 62 C からのコンパイラも書かないといけないのか... | |
| 63 | |
| 64 Mon Dec 13 18:53:04 JST 1999 | |
| 65 | |
| 66 compiler based で、内部で partial evaluation できる? | |
| 67 | |
| 68 func をdatabaseとして扱えないなら、それはできない。 | |
| 69 | |
| 70 しかし、状態遷移としては取り扱える。 | |
| 71 | |
| 72 func.state | |
| 73 func.code | |
| 74 | |
| 75 みたいな形にしてpartial evaluationすれば良い | |
| 76 | |
| 77 でも止まるのか? | |
| 78 | |
| 79 textual でない、中間的なコード表現があった方が良い? <-> interpreter? | |
| 80 | |
| 81 Prolog ではなんでいけないの? --> Unification が重いから | |
| 82 | |
| 83 Sat Nov 27 13:50:41 JST 1999 | |
| 84 | |
| 85 func.state とか作るのだったら、 | |
| 86 struct { | |
| 87 struct { | |
| 88 int i; | |
| 89 } state; | |
| 90 state *code = { | |
| 91 i = i+1; | |
| 92 }; | |
| 93 } name; | |
| 94 みたいな形で、それ自体を構造化すれば? で、代入すると部分評価される。 | |
| 95 代入も可能。なるほど。 | |
| 96 *name.code; | |
| 97 値はあるわけ? 値は &state でしょうね。 | |
| 98 self があれば、 | |
| 99 struct { | |
| 100 struct { | |
| 101 int i; | |
| 102 } state, | |
| 103 *code = { | |
| 104 self->i = self->i+1; | |
| 105 }; | |
| 106 } name; | |
| 107 かな。self = state だよね。 | |
| 108 | |
| 109 union の拡張もあわせて議論すると... | |
| 110 | |
| 111 Partial evalutator をセマンティクスや実行系にいれておくことは可能か? | |
| 112 | |
| 113 byte code とか仮想マシンだったら可能。そうでない場合は? | |
| 114 | |
| 115 いずれにせよ、構造体のタグのunique性を修正しないとだめだな。 | |
| 116 | |
| 117 ヘッダファイルはどうするの? | |
| 118 | |
| 119 Mon Dec 13 18:53:18 JST 1999 | |
| 120 | |
| 121 library との整合性は? | |
| 122 | |
| 123 exec sequence では、 | |
| 124 (--(struct func_state *)stack) = fp; | |
| 125 call callee(&fp->arg); | |
| 126 という形でpointerだけ渡すの? それは変だよね。 | |
| 127 | |
| 128 値渡しにするとすれば、複数の値を渡せたほうが良い。 | |
| 129 | |
| 130 func(void *stack) { | |
| 131 static struct func_state { | |
| 132 static struct func_state *fp; | |
| 133 int local1; | |
| 134 brahbrah... | |
| 135 } func_state; // ここまで hidden | |
| 136 func_state.fp = (stack -= sizeof(struct func_state)); | |
| 137 } | |
| 138 | |
| 139 の引数自体が、構造体であるべき。 | |
| 140 | |
| 141 func( | |
| 142 struct void *stack | |
| 143 ) { | |
| 144 static struct func_state { | |
| 145 static struct func_state *fp; | |
| 146 int local1; | |
| 147 brahbrah... | |
| 148 } func_state; // ここまで hidden | |
| 149 func_state.fp = (stack -= sizeof(struct func_state)); | |
| 150 } | |
| 151 | |
| 152 で、構造体に register storage を許す。 | |
| 153 | |
| 154 func( | |
| 155 static struct argment { | |
| 156 register void *stack; | |
| 157 register void *continuation; | |
| 158 } | |
| 159 ) { | |
| 160 static struct func_state { | |
| 161 static struct func_state *fp; | |
| 162 int local1; | |
| 163 brahbrah... | |
| 164 } func_state; // ここまで hidden | |
| 165 func_state.fp = (stack -= sizeof(struct func_state)); | |
| 166 } | |
| 167 | |
| 168 すると、caller の方も、構造体を引数とするのが自然。 | |
| 169 | |
| 170 call caller( | |
| 171 static struct argment { | |
| 172 register void *stack; | |
| 173 register void *continuation; | |
| 174 } arg = {a,b}; | |
| 175 ) | |
| 176 | |
| 177 みたいな。もちろん、この構造体はインタフェースと呼ばれる。 | |
| 178 | |
| 179 argument は、callee にあった方が良いけど、caller 側にあっても | |
| 180 良い。register なんかは、そう。 | |
| 181 | |
| 182 caller(interface caller_arg = {a,b,c}) | |
| 183 みたいなsyntax かな。 | |
| 184 caller->interface = {a,b,c}; | |
| 185 *caller->code; | |
| 186 を、 | |
| 187 caller(a,b,c); | |
| 188 と称する。 | |
| 189 | |
| 190 function には、interface と code と state があることになる。 | |
| 191 | |
| 192 state にアクセスする時のlockは? protected state? synchonized state かな? | |
| 193 もちろん、sequential implementatoinでは、そんなものはいらない。 | |
| 194 | |
| 195 function { | |
| 196 interface: | |
| 197 register int a; | |
| 198 register struct self self; | |
| 199 state: | |
| 200 int b; | |
| 201 serialized int c; | |
| 202 code: | |
| 203 b = a; | |
| 204 } | |
| 205 | |
| 206 int にvoid value を定義する。実装は重くなるけど... | |
| 207 | |
| 208 serialzed の semantics は? | |
| 209 | |
| 210 もう少しmicro-Cに近く! | |
| 211 | |
| 212 carring state と static state。 | |
| 213 | |
| 214 Mon Dec 13 19:42:41 JST 1999 | |
| 215 | |
| 216 interface に regsiter keyword を使うのは、あまりに | |
| 217 実装よりすぎる。でも、でないと状態にできない? | |
| 218 そんなことはないか。やっぱりcaller側のstatic 領域に | |
| 219 直接書き込む? | |
| 220 | |
| 221 だとCより遅そう。でも、引数に40個とかかかれたら... | |
| 222 | |
| 223 Wed Dec 15 14:09:49 JST 1999 | |
| 224 | |
| 225 C と互換にする? | |
| 226 goto function(argments); | |
| 227 goto *continuation(argments); | |
| 228 みたいな感じで。 | |
| 229 | |
| 230 stackの管理は? どうせ、library との互換はとらないと | |
| 231 いけないんだから... | |
| 232 | |
| 233 local 変数がある場合は stack を動かす。でも、戻す奴がいない。 | |
| 234 closure 化するか? | |
| 235 | |
| 236 return した時の挙動が複雑になる。大域returnするわけだら。 | |
| 237 | |
| 238 argments をstatic 領域にかきこむ方式だと互換性がとれない。 | |
| 239 stack 上の frmae pointer 上にないとダメだから。 | |
| 240 | |
| 241 両立させるのは無理か? つまり、これだと、呼び出された方の | |
| 242 frame semantics は、C と互換になる。だから、stackの直後に | |
| 243 frame pointer があると思っている (そうか? ) frame pointer | |
| 244 stack pointer に沿って移動した直後に、そこからのoffset | |
| 245 で引数を操作することになる。 | |
| 246 | |
| 247 つまり、それはだめだったことじゃない? つまり、goto だと、 | |
| 248 frame pointer は、stack の直後とは限らないから。前の | |
| 249 frmae pointer 相対に引数にアクセスしてくれれば別だけどね。 | |
| 250 | |
| 251 stack に引数を積むのは容認して、goto の場合は、向こう側で | |
| 252 stack を畳むってのは? ということは、普通の関数と定義の | |
| 253 方法を変えるってことか。ま、悪くはないか。 | |
| 254 | |
| 255 すると、goto のsemantics は、C と互換になる。それを受ける | |
| 256 方が異なることをする。それは、なんかおかしいな。それに、 | |
| 257 それだと関数呼び出しが軽くならない... | |
| 258 | |
| 259 ということは、やはり、C のcall は、call funciton で | |
| 260 実現して、その他の呼び出しは、すべて、goto 扱いに | |
| 261 する方が正しいだろう。 | |
| 262 | |
| 263 問題は、この言語の関数をcallされた時だな。dual entry にして、 | |
| 264 call の時と、goto の時を区別するか。 | |
| 265 func: stack processing | |
| 266 func_goto: normal processing | |
| 267 ... | |
| 268 みたいな感じ。でも、return はないから... | |
| 269 | |
| 270 このあたりも自分で記述できる言語であるべきだよね。その通り。 | |
| 271 つまり、C とのstub も自分で記述すると言うことか。 | |
| 272 | |
| 273 protocol function { | |
| 274 interface c { | |
| 275 register "%esp" struct { | |
| 276 entry code ret(int); | |
| 277 void *fp; | |
| 278 } *sp; | |
| 279 register "%ebp" void *fp; | |
| 280 }; | |
| 281 code function_code { | |
| 282 fp = sp; | |
| 283 sp += sizeof(struct local); | |
| 284 struct local *local = sp; | |
| 285 | |
| 286 local->i = 1; | |
| 287 goto *fp->ret(local->i),sp=fp; // return(local->i); | |
| 288 }; | |
| 289 } | |
| 290 | |
| 291 みたいな感じでさ。さっすが、アセンブラ。いまいちreturnが汚いけど。 | |
| 292 まぁ、return はそのままreturnでもいいけどさ。 | |
| 293 | |
| 294 あ、これは良いかも知れない。code が複数かけるから。 | |
| 295 | |
| 296 state 以外は、consitent state であることを保証しない。ってのは? | |
| 297 local 変数は使っても良いけど、call/goto の前後で、値を保証しないか... | |
| 298 | |
| 299 うーん、だんだん炸裂してるなぁ。 | |
| 300 | |
| 301 だから、レジスタに対するマッピングの記述と、そうでない部分の | |
| 302 記述は分離するべきでしょうね。 | |
| 303 | |
| 304 | |
| 305 全部一辺に実装するわけにはいかないからぁ... | |
| 306 | |
| 307 Thu Dec 16 13:44:21 JST 1999 | |
| 308 | |
| 309 lock は状態遷移レベルで実現するのだから、self などを | |
| 310 使ってlockする必要はないはず。 | |
| 311 | |
| 312 全体の直列化は、状態遷移レベルで、 | |
| 313 lock(storage) -> transition | |
| 314 みたいな形で記述すれば良い。この当たりを、どのように記述するかは | |
| 315 もう少し先送りしよう。 | |
| 316 | |
| 317 | |
| 318 引数はレジスタ渡しにしよう。長い引数は、呼び出し側の領域への | |
| 319 ポインタとする。実装を規定しても良い。そうすれば、varargs | |
| 320 みたいなものはなくなる。だいたい、なんで、そんなものがいるんだろう? | |
| 321 配列を渡せばいいじゃん。 | |
| 322 | |
| 323 なので、引数は一つ(or 二つ)に限るという方法もある。 | |
| 324 | |
| 325 とすると、やはり、前もって静的領域や動的領域を確保することは | |
| 326 できない。 | |
| 327 | |
| 328 この言語では動的領域は自分で確保するわけだから、その点は問題ない。 | |
| 329 | |
| 330 Thu Dec 16 20:24:55 JST 1999 | |
| 331 | |
| 332 とすると関数呼び出しは、 | |
| 333 # register save | |
| 334 # set 1st argument in register %eax | |
| 335 # set 2nd argument in register %ecx | |
| 336 # set extra aguments in save area | |
| 337 # set extra argument pointer in %edx | |
| 338 jmp function | |
| 339 という形式になるわけね。second を処理するのはめんどくさいから一つ | |
| 340 にしよう。 | |
| 341 | |
| 342 えーと、frame pointer はないけど、コンパイルの手順からすると | |
| 343 あった方が良い。しかし、frame pointer そのものをstatic | |
| 344 にとるのはまずい。だから、frame pointer がfirst argment | |
| 345 ということにする方が正しい。とすると引数は、さらに、その | |
| 346 後と言うわけか。 | |
| 347 f(fp,argment) | |
| 348 fp を渡すのにさらにargment をレジスタで渡すのはおかしい。おかしいけど、 | |
| 349 ま、良いか。 | |
| 350 | |
| 351 return しないなら、return type の定義をとるのは変だな。 | |
| 352 | |
| 353 f(fp,arg1,arg2,arg3) とすると、それぞれが決まったレジスタに入って、 | |
| 354 多い分は配列にあると思われる。ふむふむ... | |
| 355 fp->xx | |
| 356 でアクセスすれば、そのまま局所変数になる。全部、配列で | |
| 357 送っても良い。 | |
| 358 | |
| 359 .set label,value | |
| 360 | |
| 361 で as は値をセットするようですね。 | |
| 362 | |
| 363 関数コールの後は戻って来ないから後始末の心配はしなくてよい。 | |
| 364 frame pointer を使ったら自分で面倒を見ること。 | |
| 365 | |
| 366 だと | |
| 367 a = atoi(s); | |
| 368 みたいなことはできない... | |
| 369 | |
| 370 普通のCの定義と交じると間違いやすい。 | |
| 371 | |
| 372 とすると、struct と同様に、 | |
| 373 protocol | |
| 374 code | |
| 375 interface | |
| 376 state | |
| 377 を用意するわけね。時間あるのかぁ? | |
| 378 | |
| 379 とりあえず、register 渡しのfunction 定義とgoto文を実装する。 | |
| 380 | |
| 381 code name(register "%ebp" void *arg) { | |
| 382 goto name(arg); | |
| 383 } | |
| 384 | |
| 385 ぐらいかな? で、first argment が必ずregisterにのるようにしないと | |
| 386 いけない。register storage class を入れて、 | |
| 387 register "%ebp" void *arg | |
| 388 とかするわけね。 | |
| 389 | |
| 390 ってことは、まず、レジスタを実装しないといけないわけね。 | |
| 391 | |
| 392 で、stack を使った演算は、一応、そのままにする? それでも動くはず。 | |
| 393 式の途中でgotoは使えないんだから、それでいいはず。 | |
| 394 | |
| 395 で、それから、これを拡張していく。 | |
| 396 | |
| 397 interface c { | |
| 398 register "%ebp" void *arg; | |
| 399 } | |
| 400 code name(interface c) { | |
| 401 goto name(c.arg); // c. は省略可能 | |
| 402 } | |
| 403 | |
| 404 とかね。さらに、 | |
| 405 | |
| 406 protocol name { | |
| 407 interface c { | |
| 408 register "%ebp" void *arg; | |
| 409 } | |
| 410 code name(interface c) { | |
| 411 goto name(arg); | |
| 412 } | |
| 413 code name1(interface c) { | |
| 414 goto name(arg); | |
| 415 } | |
| 416 } | |
| 417 | |
| 418 などとするわけか。なんと、これが C と共存するわけね。うーん。 | |
| 419 | |
| 420 Fri Dec 31 11:44:03 JST 1999 | |
| 421 | |
| 422 code でなくて、別な名前のほうが良くない? segment? action? | |
| 423 | |
| 424 レジスタ名が入るのは、やっぱりいや。optionalには許す。 | |
| 425 | |
| 426 interface は構造体のようなものだから... 構造体でいいんじゃない? | |
| 427 構造体の場合は... malloc する? う、うーん。malloc するとして、 | |
| 428 いつfree するの? | |
| 429 | |
| 430 再入するときには、壊れてていいんじゃない? multi-thread でなければね。 | |
| 431 multi thread では、状態は、レジスタ経由または、thread local に持つ | |
| 432 必要がある。static は、だから thread local に持たなくてはならない。 | |
| 433 大域変数に割り振っちゃだめ。でも、いまは、やめて | |
| 434 | |
| 435 interface は、とりあえず、二つまでの値渡しにしよう。 | |
| 436 self と arg | |
| 437 ですね。 | |
| 438 | |
| 439 もう少し拡張しやすいコンパイラがいいなぁ。 | |
| 440 | |
| 441 code name (c,a) | |
| 442 struct state *c; struct arg *a; | |
| 443 { | |
| 444 goto name(arg); | |
| 445 } | |
| 446 | |
| 447 local 変数は? この互換性の問題かぁ。 | |
| 448 | |
| 449 KL/1 を意識して、interface は heap に置くことにしても良い。 | |
| 450 GC は言語に入れておくべきだが、interfaceは machine independent | |
| 451 であるべき。だとすれば use/forget みたいものはいるだろう。 | |
| 452 でも今のところは考える必要はない。 | |
| 453 | |
| 454 えーと、 | |
| 455 code name (c,a) | |
| 456 struct state *c; struct arg *a; | |
| 457 { | |
| 458 int i; | |
| 459 goto name(arg); | |
| 460 } | |
| 461 の時の一時変数iはどうするの? 基本的にはレジスタ割り当てだけど... | |
| 462 使用させない? んー、大胆な御意見。まぁ、やっぱりheapに割り当てちゃう | |
| 463 のが簡単か。でも、どうせ抜ける時にはいらなくなるわけだから... | |
| 464 | |
| 465 ほんらい、この変数は、次のcallでは必要無くなるのが普通。 | |
| 466 | |
| 467 とにかく、レジスタ変数は必要なんでしょう? | |
| 468 | |
| 469 だから、GC と合わせて言語を設計すべきだよね。API を規定して、 | |
| 470 異なるGCを選択できるようにする。 | |
| 471 | |
| 472 Sat Jan 1 22:40:22 JST 2000 | |
| 473 | |
| 474 とーにかく、 storage class regisgter を実装しよう。 | |
| 475 | |
| 476 stmode=REGISTER | |
| 477 | |
| 478 で、local storage とおなじ扱いとする | |
| 479 static register? は、ない。 | |
| 480 | |
| 481 symbol table に storage class をたせば? dsp==EXTRN で判定しているから、 | |
| 482 local 変数が36以上あるとおかしくなるぞ? | |
| 483 | |
| 484 sc は GVAR/LVAR だけど、regsiter は LVAR の特殊な奴だから、 | |
| 485 sc に入れるほうが正しいか... | |
| 486 | |
| 487 Sun Jan 2 01:47:17 JST 2000 | |
| 488 | |
| 489 register 変数はできました。けど、regsiter を二つ使うと、 | |
| 490 一杯になってしまうので、REGISTER6 でコンパイルしないと | |
| 491 結構ひどい。が、register 変数を%esi,%edi に割り当てれば | |
| 492 いいか。 | |
| 493 | |
| 494 Sun Jan 2 04:43:04 JST 2000 | |
| 495 | |
| 496 で、 | |
| 497 code name (c,a) | |
| 498 struct state *c; struct arg *a; | |
| 499 { | |
| 500 goto name(c); | |
| 501 } | |
| 502 の一時変数無しは実装できます。引数は二つまでね。 | |
| 503 | |
| 504 .file "tmp.c" | |
| 505 .version "01.01" | |
| 506 gcc2_compiled.: | |
| 507 .text | |
| 508 # | |
| 509 # code name(c,a) | |
| 510 .align 2 | |
| 511 .globl code | |
| 512 code: | |
| 513 .type code,@function | |
| 514 # struct state *c; struct arg *a; | |
| 515 # { | |
| 516 # goto name(c); | |
| 517 movl %esi,%esi | |
| 518 jmp name | |
| 519 _5: | |
| 520 .size code,_5-code | |
| 521 .ident "Micro-C compiled" | |
| 522 | |
| 523 う、すごい。 | |
| 524 | |
| 525 goto 文がめんどくさい。stack をたたんで、jmp すれば | |
| 526 よいだけだが.. | |
| 527 | |
| 528 Sun Jan 2 11:17:50 JST 2000 | |
| 529 | |
| 530 普通のcallをcontinuation baseにすることができる? | |
| 531 | |
| 532 Sun Jan 2 20:28:45 JST 2000 | |
| 533 | |
| 534 goto 文だけど、やはり、一度、expr で生成してから、top level | |
| 535 で jump code を生成しよう。 | |
| 536 | |
| 537 Tue Jan 4 03:32:55 JST 2000 | |
| 538 | |
| 539 code をtypeにしないと、 | |
| 540 code *p; | |
| 541 とか書けないね。 | |
| 542 int *p(); | |
| 543 と同じだけどさ。 | |
| 544 | |
| 545 | |
| 546 main(ac,av) | |
| 547 int ac; | |
| 548 char *av[]; | |
| 549 { | |
| 550 goto code1(ac,av); | |
| 551 } | |
| 552 | |
| 553 code code1(ac,av) | |
| 554 int ac; | |
| 555 char *av[]; | |
| 556 { | |
| 557 if (ac) | |
| 558 goto code1(ac,av); | |
| 559 else | |
| 560 goto ac(ac,av); | |
| 561 } | |
| 562 | |
| 563 Tue Jan 4 04:56:56 JST 2000 | |
| 564 | |
| 565 うーん、なんかレジスタにつむ順序が違う | |
| 566 これは、adecl がreverseにつむから。 | |
| 567 | |
| 568 code のretrun | |
| 569 | |
| 570 やはりcodeはtypeにしないとだめ。 | |
| 571 | |
| 572 main() | |
| 573 { | |
| 574 goto code1(); | |
| 575 } | |
| 576 | |
| 577 とかだと、main に戻って来れない。もちろん、code1() 以降で、 | |
| 578 return するわけにはいかない。(main の disp をcode1 は知り得ない) | |
| 579 goto label をcode1の引数に送れば? | |
| 580 | |
| 581 main() | |
| 582 { | |
| 583 goto code1(ret); | |
| 584 ret: | |
| 585 } | |
| 586 | |
| 587 これだと、ret がforward labelかどうか分からないけど? | |
| 588 | |
| 589 code1 中で使う中間変数を stack 上にとるのは悪くない。しかし、それを | |
| 590 %ebp 経由でアクセスするということは、main の中間変数を壊すということ。 | |
| 591 それを防ぐには、main 中のgoto codeで、%ebp を修正してやれば良い。 | |
| 592 (今は戻って来ないので問題ない) | |
| 593 | |
| 594 code1 のgoto では、戻って来ないから、その必要はない。しかし、 | |
| 595 label をcode1 中で渡されると、ちょっと気まずい。 | |
| 596 | |
| 597 とすると、それは禁止して、main() 中でstackをたたんでからgotoするか? | |
| 598 そうすると、無限後退して、結局、帰れないことになる... うーん。 | |
| 599 | |
| 600 main() 中のlocal code を許せば、それは解決するが.. | |
| 601 | |
| 602 main() | |
| 603 { | |
| 604 goto code1(code2); | |
| 605 code code2() { | |
| 606 return; | |
| 607 } | |
| 608 } | |
| 609 | |
| 610 みたいな感じ。でも、そうするとscope rule を変える必要があるので厳しい。 | |
| 611 ま、悪くはないけどね。 | |
| 612 | |
| 613 continuation を明示する方法もある。 | |
| 614 | |
| 615 main() | |
| 616 { | |
| 617 goto code1(continuation); | |
| 618 } | |
| 619 code code1(ret) | |
| 620 code (*ret)(); | |
| 621 { | |
| 622 goto *ret; | |
| 623 } | |
| 624 | |
| 625 かな? call/cc ? | |
| 626 | |
| 627 label へのgotoを許すのもいいけど、 | |
| 628 でも、label を許すと、すごくspagettyにならない? | |
| 629 | |
| 630 | |
| 631 Tue Jan 4 11:47:24 JST 2000 | |
| 632 | |
| 633 contiunation じゃなくて、return keyword を使おう。 | |
| 634 (実際、continuation と少し違うし) | |
| 635 type が少し変になるけど、まあ良い。 | |
| 636 | |
| 637 int | |
| 638 main() | |
| 639 { | |
| 640 goto code1(return); | |
| 641 } | |
| 642 code code1(ret) | |
| 643 code (*ret)(int); | |
| 644 { | |
| 645 goto *ret(3); | |
| 646 } | |
| 647 | |
| 648 だな。prototype も付けないといけないか。 | |
| 649 | |
| 650 Tue Jan 4 12:21:44 JST 2000 | |
| 651 | |
| 652 これだとmethodがすべてstatic になってしまう。dynamic なmethod | |
| 653 呼び出しにするには? dipatcher を自分で作ることになる。かなり | |
| 654 めんどくさいが... | |
| 655 | |
| 656 code method(obj,arg) | |
| 657 { | |
| 658 } | |
| 659 | |
| 660 か、あるいは、inline にするか... #define のかわりに inline ねぇ。 | |
| 661 これはあとで考えて良い。 | |
| 662 | |
| 663 Tue Jan 4 14:22:19 JST 2000 | |
| 664 | |
| 665 main の変数を書き潰すのと、gotgo (*reg)(123) での値は、 | |
| 666 register 渡しで、current register にのらないので、 | |
| 667 結局、return label は専用に作る必要がある。 | |
| 668 | |
| 669 Tue Jan 4 18:14:07 JST 2000 | |
| 670 | |
| 671 stack を継ぎ足して、呼び出す方式を取れば、call by value | |
| 672 のregister 渡しを制限する必要は無くなる。 | |
| 673 | |
| 674 複数の値を返すことも容易だ。 | |
| 675 | |
| 676 .file "tmp.c" | |
| 677 .version "01.01" | |
| 678 gcc2_compiled.: | |
| 679 .text | |
| 680 # | |
| 681 # code name(a,b,c,d,e,f) | |
| 682 .align 2 | |
| 683 .globl code | |
| 684 code: | |
| 685 .type code,@function | |
| 686 # struct arg *a,*b,*c,*d,*e,*f; | |
| 687 # { | |
| 688 # int g; | |
| 689 # goto name(a,b,d,e,f); | |
| 690 jmp name | |
| 691 _5: | |
| 692 .size code,_5-code | |
| 693 .ident "Micro-C compiled" | |
| 694 | |
| 695 おお?! | |
| 696 %esp new %esp = old %esp - 12 -4 | |
| 697 %ebp-4 = g | |
| 698 %esi = a | |
| 699 %edi = b | |
| 700 %ebp = old %esp 0 | |
| 701 %ebp+4 = c code_arg_offset=0 | |
| 702 %ebp+8 = d | |
| 703 %ebp+12 = e | |
| 704 %ebp+16 = f | |
| 705 | |
| 706 interface は付けよう! というか、 | |
| 707 goto name(struct {xxxx}) | |
| 708 みたいな感じで良いわけね。どれをregisterにいれるかと言う問題はあるが。 | |
| 709 | |
| 710 で、どうやってcallすればいいわけ? emit_pushするかわりにpush | |
| 711 する? | |
| 712 | |
| 713 うう、これでは、だめか。code argument の数が変わると、 | |
| 714 ebp をいちいち動かすことになる。そこにはold sp があるから | |
| 715 そいつもコピーする必要がある。 | |
| 716 | |
| 717 %esp new %esp = old %esp - 20 | |
| 718 %ebp-20 = g | |
| 719 %esi = a | |
| 720 %edi = b | |
| 721 %ebp-16 = c code_arg_offset= -16 ((nargs-max_reg)*int_size) | |
| 722 %ebp-12 = d | |
| 723 %ebp-8 = e | |
| 724 %ebp-4 = f | |
| 725 %ebp = old %esp 0 | |
| 726 | |
| 727 そうか、function からcallする時には、local 変数を書き潰して良い。 | |
| 728 | |
| 729 # goto name(a,b,d,e,f); | |
| 730 | |
| 731 %esp new %esp = old %esp - 20 | |
| 732 %ebp-20 = g | |
| 733 %esi = a | |
| 734 %edi = b | |
| 735 %ebp-16 = c code_arg_offset= -16 ((nargs-max_reg)*int_size) | |
| 736 %ebp-12 = d | |
| 737 %ebp-8 = e | |
| 738 %ebp-4 = f | |
| 739 %ebp = old %esp 0 disp=0 (*) | |
| 740 local1 <----16 local variable | |
| 741 %edx -12 <- disp_offset | |
| 742 %ecx -8 | |
| 743 %ebx -4 | |
| 744 %ebp = %esp 0 | |
| 745 %eip 4 <- arg_offset | |
| 746 | |
| 747 となる。ということは、pushl %ebp は、間違い。 | |
| 748 | |
| 749 だけど、%ebp をそのまま使うのは良くない。disp_offset がかかっているから。 | |
| 750 だから、もう一度 pushl %ebp したほうがよい。しかし、push する先は、 | |
| 751 上の、(*)。 | |
| 752 leave movl %ebp,%esp | |
| 753 popl %ebp | |
| 754 じゃなかったか? | |
| 755 | |
| 756 Thu Jan 6 13:00:33 JST 2000 | |
| 757 | |
| 758 できたね。これでとりあえず動くはず。速度は問題だが... | |
| 759 あとは、 | |
| 760 ANSI-C prototype | |
| 761 ANSI-C prototype check | |
| 762 Interface Definietion | |
| 763 GC support | |
| 764 Direct handling of Frame | |
| 765 だね。簡単に出来そう? たぶん... | |
| 766 | |
| 767 Fri Jan 7 09:42:53 JST 2000 | |
| 768 | |
| 769 goto 文が動いてなかった。あと peep hole optimization version も | |
| 770 作るか? | |
| 771 | |
| 772 continuation として label を送れるようにするべきか? | |
| 773 そうすると便利なんだけど、ちょっと、汚いプログラムが | |
| 774 出来るようになる。あと、送り側の環境(frame)を維持する | |
| 775 必要がある。ま、できなくはないか... | |
| 776 | |
| 777 そうすると、label が値を持つようになる。 | |
| 778 a = label:; | |
| 779 とか。うーん。label:(a,b,c) {}; みたいな形で、parallel 代入を許すと言う | |
| 780 手もあるね。 | |
| 781 | |
| 782 こちらの方がCとの相性は良いが... main() { label:(){ ... } } | |
| 783 みたいなnestを許すかどうかと言う問題がある。 | |
| 784 変数の参照を許さなければ、特に問題はない。 | |
| 785 | |
| 786 a = label: は、二重の意味があるなぁ。 | |
| 787 | |
| 788 言語の名前。DinnerBell II とか? join も入れる? | |
| 789 code entry_a().entry_b() {} | |
| 790 ですか? parallel call も? | |
| 791 | |
| 792 Fri Jan 7 19:53:53 JST 2000 | |
| 793 | |
| 794 いまのままだと return が環境を持ってないから、大域脱出できない。 | |
| 795 まぁ、環境を入れてもいいんだけど、どこに置くかと言う問題が | |
| 796 あるね。 | |
| 797 | |
| 798 そうじゃなくて、return 側で判断するか? | |
| 799 retrun(ID) | |
| 800 みたいな形でIDで判断する。そうすれば、return 側でID | |
| 801 を見て判断できる。けど... | |
| 802 | |
| 803 まぁ、はやり、環境を持って歩く方がいいかなぁ。でも、 | |
| 804 引き渡しているから、二つ引き渡して、片方を使われたときに、 | |
| 805 反対側が消えてしまうのはいたいよね。今のままならば、 | |
| 806 そういうことは起こらない。 | |
| 807 | |
| 808 continuation 特有の問題を避けるなら、このままでもいいんだが... | |
| 809 contrinuation や環境は、このシステムでは自分で作ることが | |
| 810 できるからね。 | |
| 811 | |
| 812 そうなんだけど.... retlabel や retcont は実はオブジェクト | |
| 813 全体に一つあれば良い。 | |
| 814 | |
| 815 引数を渡すときに、そこに環境へのポインタをいれてやれば良いので、 | |
| 816 解決は割と簡単だが、そうすると、例の構造体を引数で渡すと言う | |
| 817 問題を解決する必要がある。 | |
| 818 | |
| 819 でも、今の実装ならば、まったく同じ変数の構成ならばコピーは | |
| 820 実際には起こらないわけだから問題ないはず。特に、それを保証するために、 | |
| 821 interface を実装する必要がある。 | |
| 822 | |
| 823 return -> | |
| 824 (void *)old bp | |
| 825 return address | |
| 826 | |
| 827 bp を直接操作できるようにするといいんだけど.... | |
| 828 | |
| 829 Sat Jan 8 08:49:59 JST 2000 | |
| 830 | |
| 831 今は、code 内ではreturnできないわけだけど。実は、return って、 | |
| 832 code return0(i) int i; { return(i); } | |
| 833 か? 今は禁止してないから書けちゃうよね。どういうcodeが出るんだろう? | |
| 834 | |
| 835 doreturn() では retpending をセットしているだけだから、control=1 | |
| 836 のまま。で、code の終りにくるのでエラーになる。checkret は、 | |
| 837 statement の引数で判断するようにしたほうが合理的だろう。 | |
| 838 | |
| 839 大域脱出は結構根が深いよね。途中をスキップされてうれしいか? | |
| 840 destructor と同じで、途中のcodeは全部呼びたいのが普通だろう。 | |
| 841 | |
| 842 bp が同じになるまで return すれば良いわけだよね。 | |
| 843 return と同じで、明示的に環境を引き渡すようにするか。 | |
| 844 type は void * で良い? | |
| 845 | |
| 846 return する時にstackの上限を越えているかどうかを自分でチェックする | |
| 847 必要があるね。誰にreturnするかをcodeで明示すれば良いわけだけど。 | |
| 848 | |
| 849 code return0(i) int i; { return(i); } | |
| 850 | |
| 851 を許して、そこで、frame pointer を大域あるいは渡した引数と | |
| 852 比較して処理する? | |
| 853 code return0(i,env) int i; env *env; { | |
| 854 if (env==self) return(i); | |
| 855 } | |
| 856 あれ? これはおかしいよね。 | |
| 857 code return0(i,env) int i; env *env; { | |
| 858 if (env!=self) { | |
| 859 env->return(); | |
| 860 return(i); | |
| 861 } | |
| 862 } | |
| 863 も、なんか変だよなぁ。呼び出しと逆順に帰りたいわけだが... | |
| 864 実際、逆順には帰っているわけだよね。 | |
| 865 | |
| 866 return の中でこそこそ比較するという技もあるけど。 | |
| 867 | |
| 868 問題は、destructor に渡す情報だよね。もちろん、self で良いわけだが、 | |
| 869 このあたりは、言語外の問題で、それを明示的にしたいから、この言語を | |
| 870 作っているわけなのだから、これを内部で処理するのはおかしい。 | |
| 871 | |
| 872 code return0(i) int i; { return(i); } | |
| 873 | |
| 874 これだと、return の型が合わないと言う問題が生じるな。簡単には | |
| 875 チェックできない。 | |
| 876 int | |
| 877 main() { | |
| 878 code a() { | |
| 879 } | |
| 880 code b() { | |
| 881 return(i); | |
| 882 } | |
| 883 } | |
| 884 にすれば、check はできるようになる。でも、これだと、 | |
| 885 int | |
| 886 main() { | |
| 887 a: { | |
| 888 } | |
| 889 b: { | |
| 890 return(i); | |
| 891 } | |
| 892 } | |
| 893 と差がない。module 化を言語外でやるというのが主旨なのだから、これでは | |
| 894 まずい。これは高級アセンブラなのだから。 | |
| 895 | |
| 896 あそうか、return と、大域脱出時のabortとは、状況が違う。だから、 | |
| 897 別なcode を呼び出さないとだめ。あるいは、値で区別するか。これは、 | |
| 898 logic programming のfail/success と似ている。 | |
| 899 main() { } abort { ... } | |
| 900 でもいいけど? | |
| 901 main() { code abort { ... }; code return { ... }} | |
| 902 かな? | |
| 903 | |
| 904 本来、subroutine call自体が、かなりの省略形なわけだから、これは | |
| 905 仕方がない。今のままで通常のsubroutine callをシミュレートできるのか? | |
| 906 code (struct arg {...},void *sp) { | |
| 907 struct env; | |
| 908 push(sp,arg); | |
| 909 push(env,arg); | |
| 910 } | |
| 911 できるけど、ちょっと重い。やはり、frame pointer を直接操作しないと | |
| 912 だめ。 | |
| 913 | |
| 914 goto 文のほうに、env を一緒に送るものを作ったほうがいいのかも。 | |
| 915 goto (*ret)(),environment; | |
| 916 かな。type は? (void *)? | |
| 917 goto ret(),environment; | |
| 918 にはならないの? そうすれば、自分でthreadを制御できる。environment | |
| 919 の正当性を評価しなくて良いの? まぁ、ねぇ。 | |
| 920 | |
| 921 これは実装は容易だが... goto といちいち書くのが本当にいいのか? | |
| 922 env に対するoperationがあった方がいいなぁ。push とか? | |
| 923 | |
| 924 code return0(i) int i; { return(i); } | |
| 925 | |
| 926 を認めれば、return 擬変数はいらなくなる。 | |
| 927 | |
| 928 でも、実は、return は、caller の引数の数と一致してないといけない | |
| 929 わけだから、 code return0(i) int i; { return(i); } はだめ。env | |
| 930 と一致してないといけない。ということは分離するとまずいんじゃない? | |
| 931 あれ? そんなはずないな。 | |
| 932 | |
| 933 Sun Jan 9 01:15:56 JST 2000 | |
| 934 | |
| 935 やはり、分離してはまずい。もともと、 | |
| 936 goto func(arg); | |
| 937 自体が、 | |
| 938 goto func(arg) with current.env | |
| 939 みたいなものだ。つまり、これは、DinnerBell の、 | |
| 940 self message: arg | |
| 941 と同じ。self->func(arg); でも良い。が、function callと区別が付かないのは | |
| 942 良くない。 | |
| 943 | |
| 944 そうすると、type code はsize int でなくなる。 | |
| 945 code *p = func; | |
| 946 ではいけなくて、 | |
| 947 code p = {func,env}; | |
| 948 でないといけない。実際、 | |
| 949 goto func(arg) | |
| 950 では、current environment を pushl %ebp でstack = current env | |
| 951 に積んでいるわけだから。 | |
| 952 | |
| 953 いずれにせよ、 | |
| 954 struct p = q; | |
| 955 は実装する必要がある。localな、 | |
| 956 code p = {func,env}; | |
| 957 も動くはずだが... | |
| 958 | |
| 959 code (*p)(); | |
| 960 goto (*p)(arg); | |
| 961 | |
| 962 はだから少しおかしい。これは、goto がenv を補っていると考えるべき。 | |
| 963 | |
| 964 このようにすると、常に、 | |
| 965 func,env | |
| 966 の組をcodeとみなすことになる。これは、object と呼ぶべきだ。 | |
| 967 ただ、既存のobjectとは別だよな。actor の方が良い? | |
| 968 | |
| 969 うーん、これでjoinを入れれば、完璧なDinnerBellだな。並列送信はないけど。 | |
| 970 | |
| 971 Sun Jan 9 01:40:05 JST 2000 | |
| 972 | |
| 973 local 変数の初期化はallocation の後に遅らせる必要がある。 | |
| 974 nptr に入れられるはずだよね? nptr に初期化フラグを足すか? | |
| 975 | |
| 976 文途中で出現するlocal変数の初期化。ちゃんと動いているの? | |
| 977 | |
| 978 構造体のcopyは、lcheck を修正すべきでない。 | |
| 979 | |
| 980 Sun Jan 9 08:49:43 JST 2000 | |
| 981 | |
| 982 うーん、なんか修正が多いなぁ。あと、関数呼び出し、goto 文の | |
| 983 構造体への対応か。 | |
| 984 | |
| 985 goto (*code)(); | |
| 986 | |
| 987 が、self env を使うのか、code の先の値を使うのかを区別する | |
| 988 必要がある。もし*を使わないとするとlabel(FNAME)との区別が | |
| 989 つかないぞ。あ、でも、環境を持ち歩くことにしたから、label | |
| 990 へもjumpしようと思えばできるね。 | |
| 991 | |
| 992 並列送信はなくても、この構成ならばstatement単位の並列性を検出するのは | |
| 993 容易だろう。 | |
| 994 | |
| 995 やればできるけど、この修正の量だと1日じゃ終らないかなぁ。 | |
| 996 不動小数点も入れるのでしょう? | |
| 997 | |
| 998 Mon Jan 10 09:00:12 JST 2000 | |
| 999 | |
| 1000 引数に構造体を許すには、必ずANSI-Cにする必要がある。難しくは | |
| 1001 ないが... | |
| 1002 | |
| 1003 goto 文には label, code, continuation の3つが来る。 | |
| 1004 continuation = code + env | |
| 1005 | label +env | |
| 1006 なのだが、code/label では、env の内容が異なる。できれば面白いが、 | |
| 1007 その価値はあるのか? | |
| 1008 | |
| 1009 しかし、code , env を分離するとあまりに危険すぎる。どうせgoto | |
| 1010 が危険なんだからいいか? その方が簡単。簡単なら、そっちの方法を | |
| 1011 とるべきじゃない? うーん。 | |
| 1012 | |
| 1013 return の関数依存性はなくした方が良い。 | |
| 1014 一つにするのは、pop の問題があるので良くないが... | |
| 1015 | |
| 1016 そうか、ret をenvを指定して戻るようにしたから、leave する必要は | |
| 1017 なくなった。そして、push %ebp に相当する部分は、lea -disp(%ebp),%sp | |
| 1018 で消去されている。ということは、jump のfunction依存部分はいらない | |
| 1019 ということだね。 | |
| 1020 | |
| 1021 でも、汚いなぁ。read only属性をhardware supportできればなあ。 | |
| 1022 | |
| 1023 sched_yeilds() 相当を書けるかな? lock は? | |
| 1024 | |
| 1025 一応、できたけど、やっぱり汚い。 | |
| 1026 | |
| 1027 Wed Jan 12 16:12:27 JST 2000 | |
| 1028 | |
| 1029 あは。ANSI prototype はめんどい。 | |
| 1030 bexpr() | |
| 1031 で、関数での引数の順序と、そのあとの宣言の順序が変わることがある。 | |
| 1032 そうすると、うしろの方が優先されてしまう。これは、こまる。 | |
| 1033 | |
| 1034 そうか、code_arg_offset のような方法だと、ANSI style では、 | |
| 1035 困ってしまう。 | |
| 1036 | |
| 1037 Thu Jan 13 04:46:12 JST 2000 | |
| 1038 | |
| 1039 # goto name(a,b,d,e,f); | |
| 1040 code name { int g; ... | |
| 1041 | |
| 1042 %esp new %esp = old %esp - 20 | |
| 1043 %ebp-20 = g code's local variable | |
| 1044 %ebp-12 = f <- new_disp | |
| 1045 %ebp-8 = d | |
| 1046 %ebp-4 = d | |
| 1047 %ebp-0 = c | |
| 1048 %edi = b | |
| 1049 %esi = a | |
| 1050 %ebp = old %esp 0 disp=0 new env | |
| 1051 local1 <----16 old local variable ( to be erased ) | |
| 1052 %edx -12 <- disp_offset | |
| 1053 %ecx -8 | |
| 1054 %ebx -4 | |
| 1055 %ebp = %esp 0 <- old env | |
| 1056 %eip 4 <- arg_offset | |
| 1057 | |
| 1058 | |
| 1059 Thu Jan 13 13:38:24 JST 2000 | |
| 1060 | |
| 1061 だいたいできたけど、test/tmp7.c のprintf のtype mismatch は | |
| 1062 なんなんだろう? ASNI の副作用だろうなぁ。 | |
| 1063 | |
| 1064 これだと、プロセスの切替えのときには、結構な量のデータを | |
| 1065 コピーすることになる。それでもいいんだけど... | |
| 1066 | |
| 1067 それごと、どっかにとって置く。continuationへの参照みたいなもの | |
| 1068 ができないかな。 | |
| 1069 | |
| 1070 コピーができれば、environment/return の組は動くわけだから、 | |
| 1071 それへの参照と切替えがあっても良いよね。 | |
| 1072 | |
| 1073 Fri Jan 14 12:03:35 JST 2000 | |
| 1074 | |
| 1075 Libretto のkeyboardが壊れた... control key が効かない... | |
| 1076 | |
| 1077 printf の参照の問題は解決しました。list2 がlocalなheap | |
| 1078 に割り当てているのがいけなかったね。 | |
| 1079 | |
| 1080 return の処理は、goto 文で処理するより、environment に | |
| 1081 returnto する方が良くはないか? | |
| 1082 | |
| 1083 environment は実は送り先でそれなりの準備が必要。 | |
| 1084 new-environment() みたいなlibrary があれば、thread にできる。 | |
| 1085 | |
| 1086 join は? | |
| 1087 | |
| 1088 funcall を用意すると良いね。 | |
| 1089 | |
| 1090 Mon Jan 17 15:23:34 JST 2000 | |
| 1091 | |
| 1092 struct aa f1() { | |
| 1093 return bb; | |
| 1094 } | |
| 1095 | |
| 1096 みたいなのは? 関数の型か代入の型を見て、crn にpointerを渡して、 | |
| 1097 あとでcopyしてから stack を畳む。 | |
| 1098 | |
| 1099 # bb=f1(aaa); | |
| 1100 movl $bb,%eax | |
| 1101 pushl %eax | |
| 1102 movl $aaa,%eax | |
| 1103 pushl %eax | |
| 1104 call main2 | |
| 1105 popl %edx | |
| 1106 copy %eax,%edx,$400 | |
| 1107 addl $400,%esp | |
| 1108 # return a1; | |
| 1109 | |
| 1110 あ、でも、それだと、local変数を返したときに困るね。leave; ret; | |
| 1111 してはいけなくて... | |
| 1112 | |
| 1113 あ、やっぱり、こういう場合はコピー先をmain2に引き渡しているみたいね。 | |
| 1114 void f1(struct aa *ret) { | |
| 1115 *ret = bb ; | |
| 1116 return; | |
| 1117 } | |
| 1118 と同じか。これは簡単。 | |
| 1119 f1().a[55] | |
| 1120 みたいな場合は、局所変数に強制的に取ってしまうみたいね。それはそうだ... | |
| 1121 が、うちの実装だとちょっと厳しいか。 | |
| 1122 leal $-sizeof(struct),%esp | |
| 1123 pushl %esp | |
| 1124 なんだけど、関数呼び出しの途中ではできないから.... | |
| 1125 | |
| 1126 # main(ac,av) | |
| 1127 # int ac; | |
| 1128 .align 2 | |
| 1129 .globl main | |
| 1130 main: | |
| 1131 .type main,@function | |
| 1132 pushl %ebp | |
| 1133 movl %esp,%ebp | |
| 1134 pushl %ebx | |
| 1135 pushl %ecx | |
| 1136 pushl %edx | |
| 1137 # char *av[]; | |
| 1138 # { | |
| 1139 # register int i; | |
| 1140 # register char *p; | |
| 1141 # int j = 3; | |
| 1142 # struct { int b; void (*c)(struct aa); } q = {3,main1},r; | |
| 1143 # | |
| 1144 # j = 3; | |
| 1145 subl $20,%esp | |
| 1146 | |
| 1147 このsublを後から指定してやればOk。 | |
| 1148 | |
| 1149 でも、それだと jump の時にずれない? ずれるか? ずれるね。うーん。 | |
| 1150 実行時にチェックしてやるのも変だし。 | |
| 1151 | |
| 1152 まぁ、それほど必要な機能ではないんだけど。 | |
| 1153 | |
| 1154 これもcontinuationを渡してやると言う手法が使えないことはないんだが... | |
| 1155 | |
| 1156 関数呼び出しの最初にやってやればいいか。それでできるかな? | |
| 1157 | |
| 1158 | |
| 1159 Sun Feb 20 23:59:16 JST 2000 | |
| 1160 | |
| 1161 MIPS のcall frame | |
| 1162 | |
| 1163 $sp = $fp | |
| 1164 local variables | |
| 1165 saved register (including $31 = return address) | |
| 1166 | |
| 1167 mask は使用したレジスタのbit pattern | |
| 1168 -4 は何? | |
| 1169 | |
| 1170 18 .mask 0xc0000000,-4 | |
| 1171 19 .fmask 0x00000000,0 | |
| 1172 20 0000 D0FFBD27 subu $sp,$sp,48 | |
| 1173 21 0004 2C00BFAF sw $31,44($sp) | |
| 1174 22 0008 2800BEAF sw $fp,40($sp) | |
| 1175 23 000c 0000000C move $fp,$sp | |
| 1176 24 0010 21F0A003 jal __main | |
| 1177 25 0014 03000224 li $2,0x00000003 # 3 | |
| 1178 26 0018 000082AF sw $2,a | |
| 1179 27 001c 04000224 li $2,0x00000004 # 4 | |
| 1180 28 0020 00C082AF sw $2,b | |
| 1181 29 0024 05000224 li $2,0x00000005 # 5 | |
| 1182 30 0028 000082A3 sb $2,c | |
| 1183 31 002c 06000224 li $2,0x00000006 # 6 | |
| 1184 32 0030 08C082A3 sb $2,d | |
| 1185 33 $L1: | |
| 1186 34 0034 21E8C003 move $sp,$fp # sp not trusted | |
| 1187 here | |
| 1188 35 0038 2C00BF8F lw $31,44($sp) | |
| 1189 36 003c 2800BE8F lw $fp,40($sp) | |
| 1190 37 0040 0800E003 addu $sp,$sp,48 | |
| 1191 38 0044 3000BD27 j $31 | |
| 1192 39 .end main | |
| 1193 | |
| 1194 これと同じようにするならば、regiterの使用数を最初に調べる必要が | |
| 1195 あるのだけど、one path compiler である micro-C では、それは | |
| 1196 できない。したがって、enter は後ろでする方が良い。 | |
| 67 | 1197 |
| 59 | 1198 Mon Jan 20 18:25:27 JST 2003 |
| 1199 | |
| 1200 3年間さわってないのかよ。何やってんだ? | |
| 1201 | |
| 1202 goto 文のバグをとらないといけない。 | |
| 1203 | |
| 1204 まず、関数引数の構造体の展開。これは、どうってことないはず。 | |
| 1205 | |
| 1206 goto (*code)(i+1,j,...) | |
| 1207 | |
| 1208 まず、いじらなくてすむ変数を摘出する。 | |
| 1209 | |
| 1210 foreach arg | |
| 1211 compare | |
| 1212 | |
| 1213 単純演算 ( op+const , pointer , const assign ) などは、ここで検出する。 | |
| 1214 大半は、そのようになるはず。 | |
| 1215 レジスタに乗せる分があるから... それには触らないとして... | |
| 1216 | |
| 1217 複雑なものは、前もって計算しておく。(get_register する) | |
| 1218 スタック上かレジスタ上に作る。 | |
| 1219 | |
| 1220 残りは並列代入となる。再帰的に計算する。 | |
| 1221 | |
| 1222 えーと、大きな順にやるんだっけ? 小さな順にやるんだっけ? | |
| 1223 code f( int a, int b, int c ) { | |
| 1224 goto g(b,c,a); | |
| 1225 } | |
| 1226 みたいなやつだよね。 | |
| 1227 | |
| 1228 移動するものを一つ検出する。 | |
| 1229 そのために移動が必要なものを移動しておく(再帰) | |
| 1230 代入する | |
| 1231 | |
| 1232 こんなんでいいのか? ループしない? するよね。ループしたら | |
| 1233 get_register する。 | |
| 1234 | |
| 1235 前の例だと、 | |
| 1236 | |
| 1237 g(b,c,a) のbに着目する。 | |
| 1238 bに代入するコードを出すと、a が壊れる。 | |
| 1239 a が必要かどうかを調べる。それは、引数のリストを見ればわかる。 | |
| 1240 その前に、a を移動する。a の移動先を見て、 | |
| 1241 空いていれば、移動してOk。しかし、c | |
| 1242 なので、 c を見る。と b になるので、ループするのがわかるので、 | |
| 1243 b を get_register する。 | |
| 1244 で、c が移動できる。で、aを移動して、とっておいたbを代入。 | |
| 1245 | |
| 1246 Tue Jan 21 22:45:09 JST 2003 | |
| 1247 | |
| 1248 とりあえず、jump は複雑すぎる。もっと簡単にすることを考える。 | |
| 1249 parser 側である程度処理できない? | |
| 1250 | |
| 1251 goto f(a+3,b(),c); | |
| 1252 | |
| 1253 などを、 | |
| 1254 | |
| 1255 a = a+3; | |
| 1256 b = b(); | |
| 1257 goto f(a,b,c); | |
| 1258 | |
| 1259 程度に簡略化する。この時、f(a,b,c) は(できるだけ)、元の | |
| 1260 関数の引数リストに近付ける。のは無理なので、単純変数 | |
| 1261 まで落す。 | |
| 1262 | |
| 1263 あまり関係ないか。一時変数はどうせいるわけだし。ってこと | |
| 1264 みたいね。 | |
| 1265 | |
| 1266 だとすると、元のコードと、そう変わらんね。前のも、そんなに | |
| 1267 悪くないってことか。 | |
| 1268 | |
| 1269 Wed Jan 22 14:33:12 JST 2003 | |
| 1270 | |
| 1271 やっぱり、途中で局所変数を増やしたいよね。 | |
| 1272 | |
| 1273 Fri Jan 31 20:30:36 JST 2003 | |
| 1274 | |
| 1275 なんか #ifdef / #if がないとだめだな。実装する? | |
| 1276 しました。 | |
| 1277 | |
| 1278 Tue Feb 4 01:04:12 JST 2003 | |
| 1279 | |
| 1280 ## while ((*chptr++ = c = getc(filep->fcb)) != '\n') { | |
| 1281 _1120: | |
| 1282 movl $10,%eax | |
| 1283 movl $8,%ecx | |
| 1284 movl filep,%edx | |
| 1285 addl %ecx,%edx | |
| 1286 movl (%edx),%edx | |
| 1287 pushl %edx | |
| 1288 xchg %edx,%eax .... edx に$10が入る (なんでxchg?) | |
| 1289 call getc | |
| 1290 addl $4,%esp | |
| 1291 movl %eax,-20(%ebp) c に代入 | |
| 1292 movl $chptr,%ecx | |
| 1293 pushl %ecx | |
| 1294 popl %ebx | |
| 1295 movl (%ebx),%ecx ecx にchptrの中身 | |
| 1296 addl $1,(%ebx) | |
| 1297 movb %al,(%ecx) | |
| 1298 subl %edx,%eax eax-edx ($10) | |
| 1299 je _1119 | |
| 1300 | |
| 1301 が壊れる理由なんだけど... | |
| 1302 | |
| 1303 edx,ecx が破壊されちゃうみたいね。 | |
| 1304 | |
| 1305 Tue Feb 4 12:17:07 JST 2003 | |
| 1306 | |
| 1307 ようやっと直したよ... | |
| 1308 | |
| 1309 use_pointer って、なにもしなくていいんだよね? eax,ebx を避ける | |
| 1310 ってことらしいけど。 | |
| 1311 | |
| 1312 inline/引数付き #define 欲しくない? 置き換えは、local name stack に積んじゃう。 | |
| 1313 展開は function で行う。 | |
| 1314 | |
| 1315 getch を工夫する必要はあるが。置き換えスタックが必要。 | |
| 1316 | |
| 1317 | |
| 1318 Wed Feb 5 01:16:00 JST 2003 | |
| 1319 | |
| 1320 大域で定義された struct field が大域変数と重なっていると落ちる。 | |
| 1321 そりゃそうだけど。どうするの? (直した記憶があるんだけどなぁ...) | |
| 1322 struct 毎に field 名とoffset/type の組を持てばい良いんだよね。 | |
| 1323 | |
| 1324 なんだけど、タグ無しの構造体もあるから、型名の方に付ける必要 | |
| 1325 もある。というのは、型名のない構造体もあるから。タグ名には、 | |
| 1326 一応、リストがついている。なんかに使う必要があったんでしょう | |
| 1327 ね。あ、めんどう。無条件にやっても大域変数名を汚すのを直すの | |
| 1328 が難しい。 | |
| 1329 | |
| 1330 ちょっと、あれだけど、「型名.フィールド名」で登録してしまうのはどう? | |
| 1331 型名が後で出て来るところが気まずいが... | |
| 1332 | |
| 1333 def で登録するときに、nptrにdispを代入せずに、struct field list | |
| 1334 (大域変数) に入れて、type の方に、field list (list3(nptr,offset, | |
| 1335 type)) を入れれば良い。 | |
| 1336 | |
| 1337 あとは、strop の方でtypeのlistを見るようにすれば良いわけだ。 | |
| 1338 | |
| 1339 これなら、簡単に直せるはず。LUSTR/GUSTRなどの区別もなくなるし。 | |
| 1340 | |
| 1341 Wed Feb 5 02:10:14 JST 2003 | |
| 1342 | |
| 1343 浮動小数点ねぇ。完全なANSI Cにするのは大変。でも、 | |
| 1344 浮動小数点ぐらいないと。 | |
| 1345 | |
| 1346 code generation part を、さらに分割して、 | |
| 1347 複数のコード対応にしやすいようにする。 | |
| 1348 おそらく、それほど共有する部分はないけどね。 | |
| 1349 | |
| 1350 Sample C code をコンパイルして、その結果から(半分手動で) | |
| 1351 Micro CbC code generation part を生成する方法を用意する。 | |
| 1352 | |
| 1353 | |
| 1354 | |
| 1355 Thu Feb 6 11:47:03 JST 2003 | |
| 1356 | |
| 1357 Code Segement を単位として使うときに、大域変数はどういう | |
| 1358 ように分けるの? static なんかは意味ないよね。 | |
| 1359 | |
| 1360 もちろん、自然にグループ分けされるわけだけど。 | |
| 1361 | |
| 1362 あとデータフローだよね。データフローに関しては、 | |
| 1363 あんまりやってないなぁ | |
| 1364 | |
| 1365 Fri Feb 7 14:36:15 JST 2003 | |
| 1366 | |
| 1367 inline では、必らず、局所変数の増加がある。また、inline | |
| 1368 は普通の関数として展開しておく必要もあるらしい。(何故?) | |
| 1369 | |
| 1370 #define ねぇ。 | |
| 1371 | |
| 1372 #define c(a,b) g(a+1,b+1) | |
| 1373 #define g(a,b) printf("%d %d\n",a+1,b+1); | |
| 1374 | |
| 1375 main() { | |
| 1376 int a,b; | |
| 1377 a =1; b = 3; | |
| 1378 c(a,b); | |
| 1379 } | |
| 1380 | |
| 1381 local #define がいるんだよね。g の中で a が出て来た時には、 | |
| 1382 c のa の置き換えは起こってはいけない。ということは、c | |
| 1383 の置き換えはg が始まる前に終っている必要がある。dynamic | |
| 1384 scope なんだから、assoc の上乗せで良いはず。 | |
| 1385 macro のlevelを定義して、あるレベルでは、それ以前の展開 | |
| 1386 を行わないという手法が良いかな。 | |
| 1387 | |
| 1388 c(a,b) => a=>"a+1", b=>"b+1" | |
| 1389 g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") | |
| 1390 | |
| 1391 みたいな感じ? | |
| 1392 | |
| 1393 やっぱり関数解析でマクロ処理をやらせるのは無理かな? 先読みされちゃうし。 | |
| 1394 | |
| 1395 Sat Feb 8 00:53:52 JST 2003 | |
| 1396 | |
| 1397 macro は途中まで書きました。置き換えをマクロが呼び出された | |
| 1398 時点で cheap に置くと、それを解消するタイミングがない。 | |
| 1399 ここだけmallocしても良いが.. | |
| 1400 | |
| 1401 chptrsave はlistにする必要がある。list で良い。 | |
| 1402 | |
| 1403 やっぱりmacro levelを見て、自分と一致したassoc valueまで | |
| 1404 手繰って置換するんでしょう。そうすれば、置き換える必要は無い。 | |
| 1405 ということは、local_define にmflagsを格納する必要がある。 | |
| 1406 | |
| 1407 c(a,b) => a=>"a", b=>"b" | |
| 1408 a=>"a" .. mflag == 1 | |
| 1409 g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") | |
| 1410 a=>"a+1" .. mflag == 2 | |
| 1411 | |
| 1412 macro のもとのnptr が残ってないと、オリジナルを返せない。オ | |
| 1413 リジナルは、sc などが破壊されてしまう。ってことは、local macro | |
| 1414 は、local table を汚してはいけないってことだよね。ってことは、 | |
| 1415 macro table は、もとのとは別に用意する必要がある。 | |
| 1416 | |
| 1417 #define c(a,b) g(a+1,b+1) | |
| 1418 #define g(a,b) printf("%d %d\n",a+2,b+2); | |
| 1419 | |
| 1420 main() { | |
| 1421 int a,b; a ... local | |
| 1422 a =1; b = 3; | |
| 1423 #ifndef a | |
| 1424 c(a, a = "a".. macro mflag==1 | |
| 1425 g(a, | |
| 1426 a="a+1" mflag==2 | |
| 1427 ^ a = "a" mflag==1 | |
| 1428 While replacing a in g's body, a should not | |
| 1429 be replaced to (original) "a", should be c's a. | |
| 1430 b); | |
| 1431 /* 3,5 expected */ | |
| 1432 #endif | |
| 1433 } | |
| 1434 | |
| 1435 うーむ。ややこしい。 | |
| 1436 | |
| 1437 main() | |
| 1438 c(a,b) mflag++ | |
| 1439 a=>"a" mflag ==1 | |
| 1440 g(a,b) mflag++; | |
| 1441 a=>"a+1" mflag ==2 | |
| 1442 ^ is replaced by c's "a" not g's a; | |
| 1443 いったん mflag level n で展開したら、それは mflag level n-1 となる。 | |
| 1444 | |
| 1445 Sat Feb 8 18:13:43 JST 2003 | |
| 1446 | |
| 1447 いちおう、mflag まではデバッグしたが.... mflag を戻してないんじゃないの? | |
| 1448 | |
| 1449 ---c(a,b)----------------------- mflag ==1 | |
| 1450 a=>hoge, b=>hoga (mflag==1) | |
| 1451 ----g(ac,bc)----------------- mflag ==2 | |
| 1452 ac=>goge, bc=>goga(mflag==2) | |
| 1453 ----printf(a,b)---------- mflag ==3 | |
| 1454 a=>poge, b=>poga(mflag==3) | |
| 1455 | |
| 1456 g が呼び出されると、ac,bc は mflag==1 でのみ置換される。 | |
| 1457 | |
| 1458 あるテキストを置き換えると、それは置き換えたマクロのmflag level | |
| 1459 (つまり一つ少ないレベル)になる。 | |
| 1460 置き換え終ったら、元のlevelに戻す。 | |
| 1461 | |
| 1462 mflag==2のlevel では、mflag==2のlocal macroの展開しかしない。 | |
| 1463 | |
| 1464 置き換えると、mflag level 1 になるので、そこで mflag==1 のlocal | |
| 1465 macro を展開する。mflag==0 は常に展開を行う。 | |
| 1466 | |
| 1467 Sun Feb 9 11:35:23 JST 2003 | |
| 1468 | |
| 1469 うーん、なんかtypeが、list とCHARなどと入混じっているじゃん。 | |
| 1470 int save = chptrsave; | |
| 1471 で、chptrsave が、$chptrsave になってしまう。 | |
| 1472 | |
| 1473 Sun Feb 9 22:33:36 JST 2003 | |
| 1474 | |
| 1475 | |
| 1476 #define car(e) (heap[(int)(e)]) | |
| 1477 #define cadr(e) (heap[((int)(e))+1]) | |
| 1478 car(cadr(e)) | |
| 1479 | |
| 1480 だろ。 | |
| 1481 car -> | |
| 1482 #define e cadr(e) (mleve=1) | |
| 1483 cadr -> | |
| 1484 #define e e (mleve=2) | |
| 1485 | |
| 1486 むぅ。これ、うまくいかないんじゃん。こまったなぁ。 | |
| 1487 | |
| 1488 #define c(a,b) g(a+1,b+1) | |
| 1489 #define g(a,b) printf("%d %d\n",a+1,b+1); | |
| 1490 c(a, b); | |
| 1491 | |
| 1492 こっちもだめじゃん。ふーむ。lisp interpreter のように | |
| 1493 作ればいいはずなんだけど。 | |
| 1494 | |
| 1495 Mon Feb 10 08:10:25 JST 2003 | |
| 1496 | |
| 1497 結局、list base のinterpreter を実装しました。きちゃないが。 | |
| 1498 前の方法でも、頑張ればできるんでしょうけどね。 | |
| 1499 | |
| 1500 Tue Feb 11 13:50:03 JST 2003 | |
| 1501 | |
| 1502 struct copy だけど... 関数がstructを返すときに、引数に前もって | |
| 1503 積んでおくのでは、そこに値がコピーされてしまうし、あとで、 | |
| 1504 スタックをたたんで置くときにきまずい。 | |
| 1505 | |
| 1506 function call の時に、引数の型のチェックをしてない | |
| 1507 | |
| 1508 type に -1 とheapの引数が混在しているやつだけど.. | |
| 1509 やっぱまずいんじゃないか? | |
| 1510 | |
| 1511 temproal struct は再利用できるんだけど、dispの変更ができないので | |
| 1512 新しく作るしかない。大きいときだけ新しく作るなんていうセコイ | |
| 1513 技はあるけど。(そうすると、帰って来た値へのポインタを使えなく | |
| 1514 なるが.... 別にいいよね。戻り値それ自身を直接 return する | |
| 1515 時もだいじょうぶなはず) | |
| 1516 | |
| 1517 結局、呼出側で、領域を確保して引き渡すことにしました。この方法だと、 | |
| 1518 代入のときに二度コピーする必要もない。 | |
| 1519 | |
| 1520 register を使用しているかだけじゃなくて、実際にcreg/dregに | |
| 1521 値があるかどうかを記憶する必要がある。 | |
| 1522 | |
| 1523 Wed Feb 12 11:09:22 JST 2003 | |
| 1524 | |
| 1525 それだけどさ... やっぱりアドホックに実現するのは難しいんじゃないの? | |
| 1526 | |
| 1527 まぁねぇ。register の場所の確保と、寿命は別だから、それで | |
| 1528 いいんだけど、regs flag だけでなんとかならないのかな。 | |
| 1529 こういう変更ははまるが虚しい。 | |
| 1530 | |
| 1531 Thu Feb 13 18:37:36 JST 2003 | |
| 1532 | |
| 1533 さて、そろそろ jump にとりかかりますか。 | |
| 1534 | |
| 1535 構造体の引き渡しのシークエンスに使う局所変数の位置がgccと違う... | |
| 1536 | |
| 1537 そろそろ register は構造体にすべきだね。 | |
| 1538 struct register { | |
| 1539 int used; | |
| 1540 int valued; | |
| 1541 char *name; | |
| 1542 char *wname; | |
| 1543 char *bname; | |
| 1544 int type; /* register variable or not */ | |
| 1545 int number; | |
| 1546 } | |
| 1547 virtual/real は、どうする。 | |
| 1548 | |
| 1549 Sat Feb 15 14:00:03 JST 2003 | |
| 1550 | |
| 1551 fdecl_struct を構文的に引数が出現するときに行うと、int *f(int | |
| 1552 a) などで、* の評価が終る前に、int aが評価されしまう。*obj | |
| 1553 のobj を評価し終らないとfのタイプが確定しない。int*f()[] み | |
| 1554 たいな場合があるから。(?) なので、gcc と、そろえるためには、 | |
| 1555 arg の先頭で fdecl_struct を行う方法ではだめで、fdecl 中であ | |
| 1556 とから修正する方が良い。 | |
| 1557 | |
| 1558 fix しようにも引数リストなんて、存在しないじゃん! | |
| 1559 | |
| 1560 varargs を実装するのはめんどくさかろう... | |
| 1561 | |
| 1562 rvalue(expr(),type) では、expr() のtypeをrvalueに引き渡せな | |
| 1563 い。でも、type を大域変数にすると、rvalueを異なるタイプで呼 | |
| 1564 び出すときにtypeを変更する必要がある。このrvalueのtype の扱 | |
| 1565 いは、かなりはまったことがあるので、rvalue(int e,int type)の | |
| 1566 方が良いことは確かなんだが... | |
| 1567 | |
| 1568 struct_push のregisterの扱いが複雑すぎ。なんか、もっと | |
| 1569 簡単にならないの? | |
| 1570 | |
| 1571 Sun Feb 16 07:58:23 JST 2003 | |
| 1572 | |
| 1573 代入しなくて良いからと言って、ソース | |
| 1574 のリストから除いては、上書きを防げない。 | |
| 1575 | |
| 1576 Sun Feb 16 22:55:58 JST 2003 | |
| 1577 | |
| 1578 vdisp ってなんだったんだ? | |
| 1579 | |
| 1580 Mon Feb 17 12:35:39 JST 2003 | |
| 1581 | |
| 1582 並列代入は出来たみたい。代入は小さいものを先にすべきなのか? | |
| 1583 まぁ、できりゃいいんだけど、横に避けるものが大きいのはいや | |
| 1584 だよね。 | |
| 1585 | |
| 1586 Tue Feb 18 11:56:10 JST 2003 | |
| 1587 | |
| 1588 overraped 用の emit_copy | |
| 1589 float/double | |
| 1590 long long | |
| 1591 | |
| 1592 Tue Feb 18 19:34:31 JST 2003 | |
| 1593 | |
| 1594 code argument の符号を反転させると、list2(LVAR,offset) | |
| 1595 のoffsetがアドレスの方向と一致しているという前提が | |
| 1596 崩れる。それで、構造体の格納順序がずれてしまう... | |
| 1597 | |
| 1598 ということは... def(n) でcodeの時はargumentは、局所変数と同じ | |
| 1599 扱いでマイナス符号で処理した方が良い。 | |
| 1600 | |
| 1601 できたみたい。でもさ、 | |
| 1602 | |
| 1603 int main( int ac, char *av[]) | |
| 1604 { | |
| 1605 int n; | |
| 1606 goto arg1(0,1,2,3,4,return,environment); | |
| 1607 } | |
| 1608 | |
| 1609 って、きっと return 文がないと、文句を | |
| 1610 言われるよね。むむむ。 | |
| 1611 | |
| 1612 post processing する時にoverrapしてないという保証がない。 | |
| 1613 | |
| 1614 Wed Feb 19 15:38:55 JST 2003 | |
| 1615 | |
| 1616 自分自身とのoverrrapを見てないので、 | |
| 1617 struct a a,int i | |
| 1618 int i,struct a a | |
| 1619 みたいな時に自分自身を壊してしまう。なので、emit_copy | |
| 1620 が、ちゃんと方向を見て壊さないように処理する必要がある。 | |
| 1621 | |
| 75 | 1622 call bcopy でいいじゃん。まね。 |
| 64 | 1623 |
| 1624 Wed Feb 19 20:42:07 JST 2003 | |
| 1625 | |
| 1626 楊さんの C2CbC と CbC2C を、micro C に取り込む。各所に、 | |
| 1627 conv->func(); を埋め込む。conv は、構造体。 | |
| 1628 | |
| 1629 conv: original | |
| 1630 c2cbc | |
| 1631 cbc2c | |
| 1632 | |
| 1633 とする。なるほど。 | |
| 1634 | |
| 1635 Thu Feb 20 05:34:58 JST 2003 | |
| 1636 | |
| 1637 むぅ。code-ia32 で結構はまった。あと、stack のアライメントが | |
| 1638 ずれるみたい。6809では問題にならなかったんだけどね。 | |
| 1639 leave で調整するべき。 | |
| 1640 | |
| 66 | 1641 |
| 1642 Thu Feb 20 14:42:46 JST 2003 | |
| 1643 | |
| 1644 c2cbc,cbc2c なんだけど、いったん、構文木にしてから変換すると、 | |
| 1645 結構失われる情報があるけど、いいの? 特に局所変数の名前とか型 | |
| 1646 の情報とか。macro もそうだけど。 indent ぐらい保存できないか | |
| 1647 なぁ。式の途中でfunction callする場合も取り扱う必要があるの | |
| 1648 で、構文木にしてから計算するしかないかな。gexpr の代わりに生 | |
| 1649 成するようにするか。そうすると、修正するのは、statement と、 | |
| 1650 gexpr になる。でも、結局、構文木で型を持ち歩くしかないんじゃ | |
| 1651 ないの? やっぱり変だよ。型の情報がないのは。 | |
| 1652 | |
| 1653 そうではなくて、exprN() で変換していく方法もある。この方が | |
| 1654 情報が欠落しないので楽だろう。そうすると、修正するのは、 | |
| 1655 exprN(),doXXXX() | |
| 1656 となる。これは、量は多い。けど、まぁ、それだけ。この方が | |
| 1657 オリジナルを保存しやすい。 | |
| 1658 | |
| 1659 中間変数を途中で追加すると、宣言部を前もって出力できなく | |
| 1660 なる。{int a;...} を認めれば良いわけだど。実装は難しくない。 | |
| 1661 じゃ、やれば? でも、汚くなるなあ。出力をいったんバッファ | |
| 1662 に貯めれば? どこに? cheapp ですか? 中間変数はいらないん | |
| 1663 じゃないの? | |
| 1664 a = g(i)+a; | |
| 1665 でしょ。 | |
| 1666 goto g_1(i,f_1,save_a); } | |
| 1667 code g_1(i,f_1,save_a) { .... goto f_1(ret_value,save_a); } | |
| 1668 code f_1(ret_value,save_a) { a = ret_value+a; ...} | |
| 1669 じゃん。いらないじゃん。。 | |
| 1670 | |
| 1671 | |
| 1672 型を表示するルーチンが必要だね。 | |
| 1673 | |
| 1674 めんどくさいなぁ。CbCのProlog version とかほしいなぁ。そうすれば、 | |
| 1675 変換は簡単。でも、やろうとしてできなかったことでもあるな。 | |
| 1676 | |
| 1677 | |
| 1678 Thu Feb 20 21:13:23 JST 2003 | |
| 1679 | |
| 1680 MC6809 の mc-codegen.c version は? (ちょっと虚しすぎる?) | |
| 1681 X と D で、use_data_register, use_pointer してやる。 | |
| 1682 tosop で、X と D の間の足し算を特別扱いする。 | |
| 1683 (なるほど...) MAX_MAX=0でうまく動くのか? やっぱり、1は | |
| 1684 いるよね。できれば、2だよね。 | |
| 1685 | |
| 1686 結構、浮動小数点も簡単かも。 | |
| 1687 | |
| 1688 汎用の書き換えツールも便利そう。 | |
| 1689 | |
| 1690 でも、Prolog version ってのも面白そう。 | |
| 1691 code(name,interface(....)) :- | |
| 1692 p()....,goto(name,interface(....)). | |
| 1693 みたいな感じ? 結構、簡単にinterpreterを書けるかも知れない。 | |
| 1694 これは、あれだね。thread diagram interpreter と似ている。 | |
| 1695 | |
| 1696 Fri Feb 21 13:34:17 JST 2003 | |
| 1697 | |
| 1698 構文要素での書き換えだけど、どれくらいの能力があるの? | |
| 1699 その場での書き換えだけだと、ちょっと低すぎない? それで、 | |
| 1700 cbc2c,c2cbc はできるとは思う。 | |
| 1701 | |
| 1702 まぁいいけど.. chk を無視しているところが結構あるんですけど。 | |
| 1703 jmp,enter,leave ... | |
| 67 | 1704 |
| 1705 Sat Feb 22 13:05:04 JST 2003 | |
| 1706 | |
| 1707 type の印刷かぁ... | |
| 1708 | |
| 1709 conv 系は大半はdefault convが呼ばれる。なので、c.c | |
| 1710 っていうよりは、default.cだよね。必要なところだけ、 | |
| 1711 自分で代入すると言う方法が良いだろう。その方が | |
| 1712 ヘッダも一つで済むし。もちろん、object 指向なら | |
| 1713 簡単なんだが... | |
| 1714 | |
| 1715 | |
| 1716 Sun Feb 23 19:47:41 JST 2003 | |
| 1717 | |
| 1718 struct のtypeを印刷するんだけど、一回印刷したら、あとは印刷 | |
| 1719 しない方が良い。逆に毎回書くなら、tag名type名は、いらないの | |
| 1720 か。 | |
| 1721 | |
| 1722 とするとtypeの解釈はやめてndeclで処理する? 印刷では、それで | |
| 1723 いいわけだけど。 | |
| 1724 | |
| 1725 このタイプの印刷だと再帰型は印刷が終了しないんじゃないか? | |
| 1726 しないね。 | |
| 69 | 1727 |
| 1728 Mon Feb 24 02:31:06 JST 2003 | |
| 1729 | |
| 1730 strings の\nなどを元に戻す必要がある。 | |
| 1731 | |
| 1732 なんか括弧がわやになってるな。 | |
| 70 | 1733 |
| 1734 Mon Feb 24 11:02:07 JST 2003 | |
| 1735 | |
| 73 | 1736 typedef されたタイプは、そちらを使う方が良い。けど、情報が失 |
| 1737 われてしまっているので、どこかにとっておかないとだめだね。dsp | |
| 1738 ? | |
| 70 | 1739 |
| 73 | 1740 うーむ、これはなかなか難しい。全サーチしてもいいんじゃないか |
| 1741 な。遅いけど。少なくともgnptrで定義されたものはサーチすべき | |
| 1742 でしょう。 | |
| 72 | 1743 |
| 1744 indirect function type の表現がなぁ.... | |
| 1745 | |
| 73 | 1746 sdecl ではconv を行うので、type_print ではsdeclを経由した場 |
| 1747 合に表示を行ってはいけない。 | |
| 72 | 1748 |
| 73 | 1749 なんか関数の引数の型の値が微妙に変わるんですけど... やだなぁ... |
| 75 | 1750 |
| 1751 まだ、関数定義のtypedefがstructに変わってしまう。gtypedefed | |
| 1752 がうまく動いていない? | |
| 1753 | |
| 1754 Mon Feb 24 17:24:31 JST 2003 | |
| 1755 | |
| 1756 まぁねぇ。やっぱり完全に構文木から再構成した方が | |
| 1757 便利ではあるよね。特に getsym (空白など)と conv->x_() | |
| 1758 との総合作用はめんどくさい。 | |
| 1759 | |
| 1760 そのためには、局所変数名をtree上で持ち歩く必要がある。 | |
| 1761 まぁ、そうすれば良いだけだけど。 | |
| 1762 | |
| 1763 実際、今のセットで出来るかどうかは、ちょっと怪しい。 | |
| 1764 たぶん、buffer に出力するってのをいれればおそらくは | |
| 1765 変換できるだろう。 | |
| 1766 | |
| 76 | 1767 式の途中での呼び出しとかを考えると、やっぱり |
| 1768 構文式から生成しないとだめだろうね。 | |
| 1769 (ってことは、まだ、かなりの作業があるってこと.... むぅ...) | |
| 1770 tmp2.c は、通らないし... | |
| 78 | 1771 |
| 1772 Fri Feb 28 20:32:46 JST 2003 | |
| 1773 | |
| 1774 で、c2cbc は、途中で float の方を先にやるわけ? | |
| 1775 | |
| 1776 Sat Mar 1 22:05:43 JST 2003 | |
| 1777 | |
| 1778 creg_destroy は、ぜんぜんだめ。これは基本的なアイデアがだめ。 | |
| 1779 | |
| 1780 long long はstructでいいんじゃない? だめ? で struct 演算を別に | |
| 1781 定義してやる。これは、実装にもよるか。 | |
| 1782 | |
| 1783 float,long longなんだけど、 | |
| 1784 FRGVAR DRGVAR LRGVAR | |
| 1785 などを作る。さらに、 | |
| 1786 FMUL DMUL LMUL | |
| 1787 などもいる。型の変換は binop で解釈する。変換も演算になる。 | |
| 1788 D2F, D2I, F2D, F2I, I2D, I2F, U2D, U2F | |
| 1789 ぐらいですか? | |
| 1790 | |
| 1791 emit_pushは、型を必要とするけど? そうだねぇ。emit_fpush, emit_dpush | |
| 1792 かな? | |
| 1793 | |
| 1794 creg にfloat register(or stack) の値を入れればいいんじゃないの? | |
| 1795 それを見て、emit_pushの型を決める。creg は、けっこう、いろんあ | |
| 1796 ものが見ているので、いじらない方がいいじゃないかなぁ。 | |
| 1797 そうね。FMULとかがあるなら、それで判断できそう。 | |
| 1798 | |
| 1799 構文木には型を含めないってのは不便。型を入れれば? そうすれば、 | |
| 1800 RGVAR CRGVAR FRGVAR DRGVAR LRGVAR | |
| 1801 ではなく、 | |
| 1802 RGVAR | |
| 1803 ですむし。その方が変形も楽だしね。型は、 | |
| 1804 CHAR,UNSIGNED, UNSIGNED CHAR, INT, FLOAT, DOUBLE, LONGLONG | |
| 1805 ぐらいですか。 | |
| 1806 | |
| 1807 emit_data | |
| 1808 | |
| 1809 とすると、書き換えが結構あるけど。 | |
| 1810 | |
| 1811 Sun Mar 2 12:58:38 JST 2003 | |
| 1812 | |
| 1813 あとはconstantだね。FCONT,DCONSTかな。binopでは | |
| 1814 変換とかも必要なわけだけど。 | |
| 1815 | |
| 1816 そういえば、shot のload/storeもないね。SRGVAR,SASSとかですか? SASS | |
| 1817 は、すでにあるなぁ。 | |
| 1818 | |
| 1819 Sun Mar 2 22:01:58 JST 2003 | |
| 1820 | |
| 1821 あれ? | |
| 1822 conv->_sm(); | |
| 1823 (*conv->_sm)(); | |
| 1824 の場合は、 | |
| 1825 *conv->_sm の値へcallする | |
| 1826 んだけど、 | |
| 1827 goto exit1(); | |
| 1828 goto (*exit1)(); | |
| 1829 の場合は、 | |
| 1830 exit1 | |
| 1831 の値へjumpするんだよね? およ? なんか勘違いしてる? なんでexit1() | |
| 1832 だとindirectが出て、(*exit1)だと出ないんだろう? | |
| 1833 | |
| 1834 この宣言は、 | |
| 1835 void (*_sm)(); | |
| 1836 であって、 | |
| 1837 void _sm(); | |
| 1838 はできない? なんで? | |
| 1839 | |
| 1840 あぁ、まぁ、いろいろ、めんどくさい。 | |
| 79 | 1841 |
| 1842 やっぱり、arglist の再帰的扱いがちゃんとしてないとだめ。 | |
| 81 | 1843 |
| 1844 うーむ、 enum なんてのもあるのね。やさしいけど、いるのか? | |
| 1845 | |
| 1846 code (code *) * みたいなのがあるので、conv は手直しが必要。 | |
| 1847 | |
| 1848 Mon Mar 3 12:38:08 JST 2003 | |
| 1849 | |
| 1850 float/duble は順調に進んでるけど、3日はかかるでしょう。 | |
| 1851 | |
| 1852 binop を書いちゃうとmc-parse.c は、ほとんど終り?! | |
| 1853 代入と関数呼び出しが残っているか。あと single もあるね。 | |
| 1854 | |
| 1855 emit_push base で書くんだけど、他のCPUではだいぶ様相が | |
| 1856 違うんだろうな。 | |
| 1857 | |
| 1858 dreg/creg のfloating versionが必要です。( です? ) | |
| 82 | 1859 |
| 1860 Tue Mar 4 14:56:28 JST 2003 | |
| 1861 | |
| 1862 double のcurrent register は387のスタックを使う。(?) | |
| 1863 関数呼び出し時に387のスタックが保存されるという | |
| 1864 保証は無いので、emit_dpushでは、%esp に保存する。 | |
| 1865 | |
| 1866 でも、そうすると、代入の後などで387のスタックが | |
| 1867 常に残ることになる。こいつをクリアするコードは | |
| 1868 どこにいれる? free_register でもいいんだけど.... | |
| 1869 ううーむ、つかいずらいやつ。ld じゃなくて、 | |
| 1870 stack top に代入するオペレーションはないの? | |
| 1871 | |
| 1872 (あぁ、でも、なんか、floatは、もうすぐ終っちゃうな... なんか、 | |
| 1873 さびし...) | |
| 1874 | |
| 1875 Tue Mar 4 23:58:07 JST 2003 | |
| 1876 | |
| 1877 fmulp とかでは、fpp のstackのつじつまはあう。fstl とかだと、 | |
| 1878 合わない。fstpl すればいいんだが、そうすると連続代入でまずくなる。 | |
| 1879 値を使うかどうかを代入時に知ることができれば良いんだが。 | |
| 85 | 1880 (use flag で判断することにした) |
| 82 | 1881 |
| 1882 結局、freg は、使わなかったね。0が、入っているので直さないとまずいか。 | |
| 1883 fregを見て、stack を直すってのは、やっぱり、まずいよな... | |
| 1884 | |
| 1885 でも、浮動小数点レジスタを持つCPUの場合はいるんじゃないの? | |
| 1886 | |
| 85 | 1887 Wed Mar 5 11:25:11 JST 2003 |
| 1888 | |
| 1889 printf では 引数はdoubleで統一する必要がある。goto() では、 | |
| 1890 それをするのはまずい。局所変数と同等だから。ってことは、 | |
| 1891 | |
| 1892 関数の引数はdoubleにしないとだめなのね。プロトタイプが | |
| 1893 ある時は、その限りでない。(うーむ...) | |
| 1894 | |
| 87 | 1895 (くそ、こいつの副作用が結構出るな...) |
| 1896 | |
| 85 | 1897 あと、fpp のスタックに頼っているので、overflowした時に |
| 1898 困らないか? ほとんどの場合でだいじょうぶだが、だめだった | |
| 1899 時にerrorぐらい出せば? でも実行時にしかわからないか... | |
| 1900 | |
| 1901 I2D でさ、singned/unsigned の区別がいるね。 | |
| 1902 | |
| 1903 やっぱり FCONST いるんじゃないの? | |
| 87 | 1904 |
| 1905 Wed Mar 5 19:51:59 JST 2003 | |
| 1906 | |
| 1907 副作用以外は終ったけど.... あと、name space が結構重なっている | |
| 1908 んだよね。 | |
| 1909 struct tag, struct field | |
| 1910 が重なっているのは結構うっとうしい。gsearc/lsearch のあたりも | |
| 1911 書き直さないとだめかも。 | |
| 1912 | |
| 1913 あと、list もなぁ。mode の作り方にもよるんでしょうけど。 | |
| 1914 | |
| 1915 あと、結構、汚いよな... | |
| 88 | 1916 |
| 1917 Wed Mar 5 21:15:34 JST 2003 | |
| 1918 | |
| 1919 できたよ。まだ、テストしてない部分はあるけど。局所変数の初期化とか。 | |
| 1920 FCONST とか。3日で出来たね。 | |
| 1921 | |
| 1922 (gcc の方をやった方がいいかなぁ...) | |
| 89 | 1923 goto.c が通らなくなってるな。 |
| 1924 | |
| 1925 Thu Mar 6 14:00:13 JST 2003 | |
| 1926 | |
| 1927 PowerPCのnon-lazy pointerって、テーブルに入っていてそれを読 | |
| 1928 み込む形式なのね。いったん、レジスタに読み込んだら、それを再 | |
| 1929 利用する形が良いらしい。ということは、code_gvar にキャッシュ | |
| 1930 を作らないといけない。しかも RLU ですか? (めんどくさ〜) | |
| 1931 でも、そうしないと、 | |
| 1932 i = i+1; | |
| 1933 なんてのでも、ひどい目にあってしまう。 | |
| 1934 | |
| 1935 local variable も最初に move mutilple register で大半は | |
| 1936 レジスタに読み込んじゃうみたいね。pointer で参照されると | |
| 1937 困るんでしょうけど。まぁ、31個もあれば、そういうことを | |
| 1938 してもあまり問題ないのかも知れないけど。 | |
| 1939 | |
| 1940 creg を破壊しない実装にすれば、少しはましになるんじゃない? | |
| 1941 (IA32では、それは難しいけど) | |
| 1942 | |
| 1943 Thu Mar 6 20:50:24 JST 2003 | |
| 1944 | |
| 1945 やっぱり、使った分だけregisterを保存するようなコードに | |
| 1946 なるみたい。one path で、それをするためには、 | |
| 1947 .align 2 | |
| 1948 _main0__: | |
| 1949 lwz r5,2136(r1) | |
| 1950 addi r1,r1,2128 | |
| 1951 lmw r23,-36(r1) | |
| 1952 mtlr r5 | |
| 1953 blr | |
| 1954 .align 2 | |
| 1955 .globl _main0 | |
| 1956 _main0: | |
| 1957 mflr r2 | |
| 1958 stmw r30,-8(r1) | |
| 1959 stw r2,8(r1) | |
| 1960 li r11,0 | |
| 1961 stwu r1,-480(r1) | |
| 1962 li r2,100 | |
| 1963 mtctr r2 | |
| 1964 mr r30,r3 | |
| 1965 addi r0,r1,64 | |
| 1966 mr r9,r0 | |
| 1967 b _main0__; | |
| 1968 とかいう感じにするしかないね。 | |
| 1969 | |
| 1970 あと引数は、レジスタに積むようになっているみたいだけど... r3 から? | |
| 1971 | |
| 1972 mflr r31 | |
| 1973 li r0,7 | |
| 1974 stw r0,56(r1) | |
| 1975 | |
| 1976 だから8個まではレジスタに積むみたいね。 | |
| 1977 r3-r10 だね。 | |
| 1978 | |
| 1979 構造体もregisterにコピーされるのか。そして、向う側で受取の | |
| 1980 コピーを行うわけだね。先頭にreturn structへのポインタがあるのも | |
| 1981 同じ。 | |
| 1982 | |
| 1983 (うう、memcpyしまくりだ...) | |
| 1984 | |
| 1985 浮動小数点もレジスタ渡し見たい。f1から。(なるほど) | |
| 1986 | |
| 1987 saveFPってのを呼び出して、 f24-f31をsaveするらしい。 | |
| 1988 (31-24)*8 数合わないな? | |
| 1989 | |
| 1990 pointer のことを考えると、レジスタだとまずいものもある | |
| 1991 わけだけど。アドレスを取られてからで間に合うんじゃない? | |
| 1992 配列などは、もともとだめだし。場所と値(?)は確保するとして。 | |
| 1993 | |
| 1994 そうか、逆に、r3-r10 は引数でなければ壊しても良いわけか。 | |
| 1995 (それでr9とか良く使われているわけか...) | |
| 1996 ということは足りなくなったら、引数をセーブすれば良いわけね。 | |
| 1997 (ってことは、LVAR かつ REGISTER っていう状況があるんじゃん... | |
| 1998 まぁ、そうだけどさ...) | |
| 1999 これは get_register がめんどくさそ。 | |
| 2000 | |
| 2001 どうも、r11-r12 あたりは自由に使っているらしい。 | |
| 2002 | |
| 2003 引数を作っている途中で関数呼出しするときは、どうするの? | |
| 2004 r30などに移動するのか? | |
| 2005 | |
| 2006 なんか知らんけど、in file call name と out file call name が | |
| 2007 違うみたいね。(sigh...) こんなのなんとかなるのかなぁ。 | |
| 2008 全部、stub にしておいて、.set で書き換えるという手もあるけど。 | |
| 2009 | |
| 2010 (さすがに一日ではできないか...) | |
| 90 | 2011 |
| 2012 なんか整数から浮動小数点への変換はじぶんでやらないとだめなのね。 | |
| 92 | 2013 これはサブルーチンを呼んだ方がましだ。 |
| 2014 | |
| 2015 get_register は絶対失敗しないようにできるんじゃないか? | |
| 2016 | |
| 2017 label があると、code_base cache はclearしないといけない。 | |
| 2018 それを判断するには fwddef をhookする必要があるけど。 | |
| 93 | 2019 |
| 2020 Fri Mar 7 09:17:10 JST 2003 | |
| 2021 | |
| 2022 問題は、 | |
| 2023 register allocation | |
| 2024 と | |
| 2025 function call/goto call | |
| 2026 の構成だな。goto の方は machine dependentなところは | |
| 2027 ほとんどない。register のsaveさえ必要ないから。 | |
| 2028 | |
| 2029 register allocation だけど。 | |
| 2030 r0 | |
| 2031 r1 frame pointer (or stack pointer ) | |
| 2032 r30 jj | |
| 2033 r31 relocation register | |
| 2034 r0,r1,r2 システムで使う | |
| 2035 r0-r10 引数 | |
| 2036 引数でないところは優先的に使う | |
| 2037 r20-r29 セーブして使う領域 | |
| 2038 | |
| 2039 r10-r19 はどうなんだろう? セーブしないのか? | |
| 2040 | |
| 2041 ia32 の方でもfppのスタックを関数呼び出しのときに吐き出した方が | |
| 2042 良い。 | |
| 2043 | |
| 2044 r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 | |
| 2045 r10 r11 r12 r13 r14 r15 r16 | |
| 2046 r28 r29 r30 r31 | |
| 2047 | |
| 2048 なので、もののみごとに、17-27 までが使われてないね。 | |
| 2049 | |
| 2050 ということは、関す呼出し時には、保存されるレジスタはないと | |
| 2051 思った方が良いってこと? あるいは、r17-r28 は保存されると | |
| 2052 思って良いのかな。 | |
| 2053 | |
| 2054 Sat Mar 8 19:28:42 JST 2003 | |
| 2055 | |
| 2056 関数呼び出し時のレジスタセーブを避けるためには、関数呼び出し | |
| 2057 を優先して実行してやれば良い。関数呼び出しの結果は局所変数に | |
| 2058 セーブする。 | |
| 2059 f(g(h(a)+1)+2) | |
| 2060 は、 | |
| 2061 a1=h(a) | |
| 2062 a2=g(a1+1) | |
| 2063 f(a1+2) | |
| 2064 となる。そうすれば、関数呼び出しのときのスタックはかならず0になる。 | |
| 2065 | |
| 2066 でも、結局、引数は関数呼び出しの前にセーブするのね。だったら、 | |
| 2067 そんなことしないで、セーブすれば良いのか。 | |
| 2068 | |
| 94 | 2069 Mon Mar 10 11:42:40 JST 2003 |
| 2070 | |
| 2071 で、レジスタのセーブなんだけど、mc-codegen.c を変更しない | |
| 2072 とすれば、引数のリストを使って変更していくのが良い。 | |
| 2073 関数呼び出しは基本的には並列代入になる。並列代入でき | |
| 2074 てもできなくても、セーブする必要はある。今の並列代入 | |
| 2075 ルーチンのできは良くないので、「同じかどうか」だけ | |
| 2076 判断するのが良いのではないか? | |
| 2077 | |
| 2078 関数呼び出しの前に式用にレジスタに積まれた値はセーブした | |
| 2079 方が良い。セーブした後はlvarとしてアクセスすることになる。 | |
| 2080 スタックでもいいけど。 | |
| 2081 そうすると、stack 配列には、 | |
| 2082 | |
| 2083 レジスタ レジスタ番号 (>0) | |
| 2084 スタック -1 | |
| 2085 lvar lvar番号 | |
| 2086 | |
| 2087 の三種類が入ることになる。それに合わせてtosop/assopを書き直 | |
| 2088 す必要がある。emit_pop だけでいいかも。スタックを止めちまう | |
| 2089 のも手ではあるが、ia32の方で効率が悪い。やっぱり三種類サポー | |
| 2090 トするのが良いだろう。 | |
| 2091 | |
| 2092 (けっこういろいろあるなぁ... どこから手を付けるか...) | |
| 2093 | |
| 2094 Tue Mar 11 14:23:57 JST 2003 | |
| 2095 | |
| 2096 save_stacks すると、レジスタはほとんど使われなくなって | |
| 2097 しまう。が、コードの見通しは良くなる。 | |
| 2098 | |
| 2099 定数を右辺に持って行くとsave_stacksでsaveする量が減る。が以 | |
| 2100 外にめんどくさいね。反射律が成り立たない演算子に関しては。tosop | |
| 2101 の定数版とか作ることになるので... あとスタックに積む順序が逆 | |
| 2102 になってしまう。まぁ、もとの版では行われていたことだが... | |
| 2103 CMPではrexpr で反転して論理を逆転させる方が簡単か。SUBでは、 | |
| 2104 ADD + (-CONST) にする方が良いね。 | |
| 2105 | |
| 2106 je _xxx | |
| 2107 したあと、current register のregv[]が残ってしまう。これは、 | |
| 2108 変だよね。gexpr_init で regv が残るのは、case 文の比較だけ。 | |
| 2109 あとは全部0にして良い。(まぁ、害は無いんだけど) | |
| 2110 | |
| 2111 (case 文のjumpは、switch 文が終る時に処理すれば、index jump | |
| 2112 にすることができるね) | |
| 2113 | |
| 2114 Wed Mar 12 12:58:47 JST 2003 | |
| 2115 | |
| 2116 比較で入れ換えるとの否定は若干違うよね。 | |
| 96 | 2117 |
| 2118 Thu Mar 13 19:39:48 JST 2003 | |
| 2119 | |
| 2120 そういえば、doif で条件が定数だったときとかの最適化は | |
| 2121 してないんだね。やさしいけど。chk を使えば良いので。 | |
| 2122 | |
| 2123 f(g(1,2,3),g(1,2,3),g(1,2,3)) | |
| 2124 | |
| 2125 とかだと、結局、g の返り値は一旦メモリに入れないとだめじゃん。 | |
| 2126 なんだけど、実際は、r29-r22 を使っているようですね。 | |
| 2127 | |
| 2128 ってことは、function call の時に、r3-r10 が前の引数かどうかを | |
| 2129 チェックして、引数だったらr29-r22に移す作業がいるわけだよね。 | |
| 2130 いったんr3とかに入れてしまった後だと、重複してしまうが... | |
| 2131 前もって関数呼出しがあるかどうかは、調べることができるから、 | |
| 2132 関数呼び出しがあったら、そうするようにする? | |
| 2133 | |
| 2134 いろいろめんどくさいなぁ... (いったい、いつなったらできるんだ?) | |
| 98 | 2135 |
| 2136 Fri Mar 14 10:38:25 JST 2003 | |
| 2137 | |
| 2138 function の dsp が、arglist と extern flag の両方を入れてしまっている。 | |
| 2139 本来は sc で区別するべき物だよね。 | |
| 2140 | |
| 2141 なんか、emit_pop_free のxregがLVARの時のバグを取るのに苦労した... | |
| 2142 gdb は top level でのwhile を受け付けなくて、define してやなんないと | |
| 2143 だめみたいね。 | |
| 99 | 2144 |
| 2145 Fri Mar 14 15:50:28 JST 2003 | |
| 2146 | |
| 2147 なぁ... 書いても書いても書いても、終らん! | |
| 2148 | |
| 2149 Fri Mar 14 19:43:44 JST 2003 | |
| 2150 | |
| 2151 jump の中で input register を割り振るときに floating point register の | |
| 2152 ことを考えてなかった。これは register_var とは異なるので異なる | |
| 2153 仕組みで割り振る必要がある。ってことは、get_input_register_var | |
| 2154 が要るってこと? | |
| 2155 | |
|
100
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2156 |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2157 0x9001a544 <saveFP+4>: stfd f15,-136(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2158 0x9001a548 <saveFP+8>: stfd f16,-128(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2159 0x9001a54c <saveFP+12>: stfd f17,-120(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2160 0x9001a550 <saveFP+16>: stfd f18,-112(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2161 0x9001a554 <saveFP+20>: stfd f19,-104(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2162 0x9001a558 <saveFP+24>: stfd f20,-96(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2163 0x9001a55c <saveFP+28>: stfd f21,-88(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2164 0x9001a560 <saveFP+32>: stfd f22,-80(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2165 0x9001a564 <saveFP+36>: stfd f23,-72(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2166 0x9001a568 <saveFP+40>: stfd f24,-64(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2167 0x9001a56c <saveFP+44>: stfd f25,-56(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2168 0x9001a570 <saveFP+48>: stfd f26,-48(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2169 0x9001a574 <saveFP+52>: stfd f27,-40(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2170 0x9001a578 <saveFP+56>: stfd f28,-32(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2171 0x9001a57c <saveFP+60>: stfd f29,-24(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2172 0x9001a580 <saveFP+64>: stfd f30,-16(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2173 0x9001a584 <saveFP+68>: stfd f31,-8(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2174 0x9001a588 <saveFP+72>: stw r0,8(r1) |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2175 0x9001a58c <saveFP+76>: blr |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2176 |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2177 なのか。ということは、 |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2178 f%d に対して、"saveFP+%d",68-(31-f)*4 |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2179 かな? |
|
a9e6f2a2946f
Wrote all code for PowerPC and no compile error. Let's fix all bugs...
kono
parents:
99
diff
changeset
|
2180 |
| 101 | 2181 うーん、これで、全部書いた気がする。でも、ほとんど全部の |
| 2182 関数にバグがあるだろうなぁ。一つ一つ取っていくしかないか。 | |
| 102 | 2183 |
| 2184 Sat Mar 15 16:04:09 JST 2003 | |
| 2185 | |
| 2186 やぁ... まぁ.... バグだらけだな。 | |
| 103 | 2187 |
| 2188 function call のレジスタの処理がでたらめ。RISCの場合は、parallel_assing | |
| 2189 した方がいいんじゃないか? | |
| 2190 | |
| 2191 Sun Mar 16 20:59:10 JST 2003 | |
| 2192 | |
| 2193 あぁ、まだまだ、かかりそうだ.... | |
| 2194 | |
| 2195 定義されてない関数/定数をextern扱いにする必要がある。(なんで、PICなの?) | |
| 2196 | |
| 2197 function は c0(n->ty)==FUNCTION で識別する。n->sc には、FUNCTION/EXTRN[1] | |
| 2198 が入る。だよね。(CODE)も。だけど、n->ty に戻り型が入っている場合が | |
| 2199 けっこうあるらしい。 | |
| 2200 | |
| 2201 (しかし、これは、結構かかるな...) | |
| 2202 | |
| 2203 Mon Mar 17 12:02:22 JST 2003 | |
| 2204 | |
| 2205 function のnptrだけど、 | |
| 2206 nptr->ty function の return type | |
| 2207 list3(FUNCTION,return_type,arg_type_list); | |
| 2208 nptr->sc 本来はFUNCTION/CODE (EXTRN/EXTRN1) | |
| 2209 nptr->dsp 引数のリスト | |
| 2210 と言う構成なわけだよね。で、引数のリストとtypeは重複している。 | |
| 2211 | |
| 2212 他のnptrとの整合性を考えると、 | |
| 2213 nptr->ty return type | |
| 2214 nptr->sc FUNCTION/CODE | |
| 2215 nptr->dsp 引数のリスト | |
| 2216 が良い。で、引数のリストにEXTRNの情報を入れる方がいいんじゃないか? | |
| 2217 (どっちにするんだよ...) | |
| 2218 | |
| 2219 プロトタイプと実際の引数リストの整合性はチェックしなくちゃ | |
| 2220 いけないわけだから、別な方がいいんじゃないか? とすると、 | |
| 2221 やっぱり前者か... | |
| 2222 | |
| 2223 | |
| 2224 extern と、そうでないものとの呼出しを、呼出しの時点で | |
| 2225 区別しないといけない。しかし、prototype で定義されている | |
| 2226 ものと default extern の区別は、最終の時点でしか判別できない。 | |
| 2227 できないよね。定義されてないものが default extern なんだから。 | |
| 2228 ってことは、最後に、.set で定義するしかないか。(sigh...) | |
| 104 | 2229 |
| 2230 Mon Mar 17 14:34:12 JST 2003 | |
| 2231 | |
| 2232 えーと、input register に regv/regs をセットしないとだめ。 | |
| 2233 関数呼び出しの引数を評価する前に save する必要がある。 | |
| 2234 さらに、引数の評価の後に、save された変数を呼び出す必要が | |
| 2235 ある。(ってことは、いままでのは、まったくのでたらめか..) | |
| 2236 | |
| 2237 register 変数の場合は、問題ない。ってことは、ia32 側も | |
| 2238 変更してしまったので、おかしくなっているね。もっとも、 | |
| 2239 code の場合は、そういうsaveとかは必要ないから良いのか。 | |
| 2240 | |
| 2241 (11日目か...) | |
| 2242 | |
| 2243 mr creg,hoge | |
| 2244 mr hoge2,creg | |
| 2245 | |
| 2246 とかは、g_expr_u で最適化するべし。set_freg/set_creg でレジ | |
| 2247 スタ変数に割り振ると、set_freg でfreeされてしまう。 | |
| 2248 | |
| 2249 浮動小数点定数の共有はやった方が良い? | |
| 2250 | |
| 2251 input register のsaveを忘れている。 | |
| 2252 input register の割当が逆順。 | |
| 105 | 2253 |
| 2254 Mon Mar 17 23:38:14 JST 2003 | |
| 2255 | |
| 2256 あぁ、そうか。input-register のアドレスを取ったときは、 | |
| 2257 それをLVARに変えないとだめ。 | |
| 2258 | |
| 2259 なんだけど、途中で分かっても、loop で前に戻ることがあるので、 | |
| 2260 手遅れです。ということは、one path ではできないね。 | |
| 2261 | |
| 2262 むぅ... function call の save_input_register も同じ「手遅れ」 | |
| 2263 の問題があるのね。function argument は、すでに parse されて | |
| 2264 いて、その引数は、register に固定されてしまっている。 | |
| 2265 save_input_register で、save するコードを出しても、 | |
| 2266 そちらを見るようには出来てない。(どうすればいいんだ?) | |
| 2267 | |
| 2268 function callの先頭で、引数を全部stackにsaveしてしまえば、 | |
| 2269 このあたりの問題は解決する。けど、あんまりな気もするね。 | |
| 2270 でも、stmw も使えるしな... | |
| 2271 | |
| 2272 結局、input_register は、LVAR のまま処理して、可能ならば | |
| 2273 register を使うって方がいいんじゃないかなぁ.... でも、 | |
| 2274 そうすると、今まで書いたコードは、ほとんど無駄かぁ... | |
| 2275 | |
| 2276 いずれにせよ、あんまり簡単な解決はないね。 | |
| 2277 | |
| 106 | 2278 Tue Mar 18 10:46:48 JST 2003 |
| 2279 | |
| 2280 結局、全部 stack にsave しました。そうすれば、変更は1行。 | |
| 2281 | |
| 2282 やっぱり、関数全体を構文木に落してからgexprするべきだよね。 | |
| 2283 それ自体は、そんなに難しくないが。 | |
| 108 | 2284 |
| 2285 Tue Mar 18 12:41:42 JST 2003 | |
| 2286 | |
| 2287 COND(三項演算子)で使うレジスタが関数の引数を破壊してしまう。 | |
| 2288 input register にならない値を使えば良いんだけど。r15 | |
| 2289 を使っているんだけど、それでいいの? | |
| 2290 | |
| 2291 virtual を使っていたときは、use_register で何も破壊されなかった | |
| 2292 んだけど、使わないとすると、結構破壊されてしまう。なので、 | |
| 2293 ちょっと奥の深い問題かもね。三項演算子の型はチェックしてなかったし。 | |
| 2294 | |
| 2295 まぁ、それは、一時レジスタを使えば良いとして... | |
| 2296 | |
| 2297 時々呼び出す、u2d とか bcopy とかで破壊されるinput レジスタ | |
| 2298 はどうする? これは、予測は困難だよね。使う分だけsaveするって | |
| 2299 言う手もあるけど。うー、どうしよう... 検出できるようにするっ | |
| 2300 ていう手もある。(と、思ったら、get_register_var が間違ってい | |
| 2301 るみたいね) 検出はちょっと重いか。二乗のアルゴリズムは、あま | |
| 2302 り使いたくない。といっても、定数乗になるだけか。呼出側でsave | |
| 2303 する? bcopy がどれくらい使うか割りと曖昧。 | |
| 2304 | |
| 2305 もっと積極的にget_register_var するっていう手もあるよね。そ | |
| 2306 うすれば、あまり気にすること無く library call できる。(ちょ | |
| 2307 っと、書き換えが多いが...) その方が筋かな。使うレジスタを減 | |
| 2308 らそうと思うと、それは検出するのと、それほど差はないわけか。 | |
| 2309 | |
| 2310 このあたりも構文木を全部持っていれば解決できるんだよな。 | |
| 2311 | |
| 2312 うーん、まだまだ、だな。 | |
| 2313 | |
| 2314 関数が関数呼び出しで決まる場合の input register の破壊を考えて | |
| 2315 ませんでした。これも、どうすればいいんだ... まぁ、get_register_var | |
| 2316 するのが簡単だよね。 | |
| 2317 | |
| 2318 save register が狂っているようだね。max_register_var あたり? | |
| 110 | 2319 |
| 2320 Wed Mar 19 02:22:51 JST 2003 | |
| 2321 | |
| 2322 なんだか、struct のtag listが、int a,b,c; のようになっているのを | |
| 111 | 2323 一つと数えているらしい。困ったものだ。前に言ったのをちゃんと |
| 2324 実装しよう。 | |
| 2325 | |
| 2326 macro のバグも見つけちゃったよ... むぅ。 | |
| 2327 | |
| 2328 でも、とりあえず、a.out は動きました。 | |
| 2329 | |
| 2330 Wed Mar 19 12:59:01 JST 2003 | |
| 2331 | |
| 2332 なんか、浮動小数点をprintfに引き渡すときは、rnレジスタにも | |
| 2333 値をいれていて、しかも、そっちを見るみたいね。これは、 | |
| 2334 めんどくさい.... | |
| 2335 r4,r5 ... f1 | |
| 2336 r6,r7 ... f2 | |
| 2337 r8,r9 ... f3 | |
| 2338 f4 からは単独 | |
| 2339 (あぁ、なんか、これは異常にめんどくさいぞ... こんなことするなら | |
| 2340 f0 から r0 にコピーさせてよ...) | |
| 2341 | |
| 2342 40(r1)とかをprintfは、派手にぶっこわすようですね。いったい | |
| 2343 どれだけ取れば良いんだろう? | |
| 2344 | |
| 2345 -112 ぐらい? 今は-72程度か。 | |
| 2346 | |
| 2347 (なんか風邪ひいた... 家内がくるというのに...) | |
| 2348 | |
| 2349 浮動小数点のバグも順調に取れています。 | |
| 112 | 2350 |
| 2351 なんか、save_stack が余計なsaveしてない? | |
| 2352 まぁ、一時変数を良く使うのでfree listを作った方が良いかもね。 | |
| 113 | 2353 |
| 2354 その前に整数演算のチェックが必要だな。 | |
| 114 | 2355 |
| 2356 Thu Mar 20 12:06:27 JST 2003 | |
| 2357 | |
| 2358 まだ、save したレジスタを破壊しているな。 | |
| 2359 set L_98,244 | |
| 2360 stw r15,lo16(-44+L_98)(r1) | |
| 2361 ぐらいで、もう壊れちゃうみたい。ってことは、L_98 がもっと | |
| 2362 大きくないとダメなのか。 | |
| 2363 | |
| 2364 | |
| 116 | 2365 Thu Mar 20 23:43:42 JST 2003 |
| 2366 | |
| 2367 ようやっと、self compile が通りそう。register save 系が | |
| 2368 やっぱり難しいみたいだね。dynamic loader を壊したりするし。 | |
| 2369 | |
| 2370 あとmodがおかしいみたいで、hashの値が違うらしい。マイナスの値 | |
| 2371 になるunsignedのかけ算ねぇ。int.c のrecursionが通らない。 | |
| 2372 まだ、offset がおかしいらしい。 | |
| 2373 | |
| 2374 macro のバグもとれたし。 | |
| 2375 | |
| 2376 一応は、self compile は通りました。 | |
| 2377 | |
| 2378 Fri Mar 21 03:18:26 JST 2003 | |
| 2379 | |
| 2380 やっぱり、r1 と x(r30) の計算が合わない。きっと、 | |
| 2381 呼出側で、引数の分のoffset を用意しているのだろう。 | |
| 2382 だから、どれくらいの引数の関数を呼び出したかという | |
| 2383 値がいるのではないか? | |
| 2384 | |
| 2385 | |
| 117 | 2386 Fri Mar 21 12:22:11 JST 2003 |
| 2387 | |
| 2388 <------r1_offset------------------------------> | |
| 2389 <------------lvar_offset-------> | |
| 2390 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2391 caller arg xx register save local callee arg xx | |
| 2392 reg_save disp max_func_args*size_of_int | |
| 2393 | |
| 2394 ということだったみたいね。ようやっと self compile が通りました。 | |
| 2395 | |
| 2396 free_glist を作るか.... | |
| 119 | 2397 |
| 2398 Sat Mar 22 11:17:41 JST 2003 | |
| 2399 | |
| 2400 creg/freg を g_expr の引数にした方が、レジスタマシン系では、素直な | |
| 2401 みたい。そうすれば、 | |
| 2402 ## conv->static_(); | |
| 2403 addis r15,r31,ha16(_conv-L_242) | |
| 2404 la r15,lo16(_conv-L_242)(r15) | |
| 2405 lwz r3,0(r15) | |
| 2406 lwz r3,244(r3) | |
| 2407 mr r29,r3 | |
| 2408 mtctr r29 | |
| 2409 みたいな mr は減るね。もっとも一命令だけどさ。3% もあるみたい。 | |
| 2410 ちょっと多いか... 386 での use_register もなくなるしなぁ。 | |
| 2411 (あぁ、でも大半はポインタキャッシュだな。こっちを直す方が | |
| 2412 簡単か) | |
| 2413 | |
| 2414 まぁ、そういう最適化をしないっていうのが、このコンパイラの立場 | |
| 2415 なわけだけど。 | |
| 2416 | |
| 2417 | |
| 2418 構造体の引数渡しでは、構造体そのものをレジスタに載せて | |
| 2419 引き渡しているみたいだね。まったく... それで、あわてて | |
| 2420 メモリに代入しているわけか。 | |
| 2421 | |
| 2422 なんか mtctr r2; bdn Lxx とかいうのがあるのね。main frame っぽい! | |
| 2423 これはベンチマーク用って感じだね。 | |
| 2424 | |
| 2425 | |
| 2426 Sun Mar 23 16:06:29 JST 2003 | |
| 2427 | |
| 2428 Breakpoint 3, get_register () at mc-code-powerpc.c:235 | |
| 2429 235 for(i=MAX_TMP_REG;i>MIN_TMP_REG;i--) { | |
| 2430 (gdb) c 9999 | |
| 2431 Will ignore next 9998 crossings of breakpoint 3. Continuing. | |
| 2432 test/basic.c:67:Bug of compiler | |
| 2433 | |
| 2434 Breakpoint 2, errmsg () at mc-parse.c:214 | |
| 2435 214 if(lineno==0) return; | |
| 2436 (gdb) info b | |
| 2437 Number Type Disposition Enabled Address WhatStackFrame Condition IgnoreCount Commands | |
| 2438 2 breakpoint keep y 0x0000ca08 in errmsg at mc-parse.c :214 | |
| 2439 breakpoint already hit 1 time | |
| 2440 3 breakpoint keep y 0x000028e4 in get_register at mc-code-powerpc.c :235 | |
| 2441 breakpoint already hit 69 times | |
| 2442 ignore next 9930 hits | |
| 2443 (gdb) run | |
| 2444 The program being debugged has been started already. | |
| 2445 Start it from the beginning? (y or n) y | |
| 2446 Starting program: /Users/kono/src/device/mc -s test/basic.c | |
| 2447 [Switching to process 24650 thread 0x2307] | |
| 2448 test/basic.c:67:Bug of compiler | |
| 2449 | |
| 2450 Breakpoint 2, errmsg () at mc-parse.c:214 | |
| 2451 214 if(lineno==0) return; | |
| 2452 (gdb) c 69 | |
| 2453 | |
| 2454 うまくいかんね。 | |
| 2455 | |
| 2456 a+a+a....a で落ちてしまう。まぁねぇ。 | |
| 124 | 2457 |
| 2458 結局、stack frame の問題か。 | |
| 2459 | |
| 2460 Mon Mar 24 03:06:32 JST 2003 | |
| 2461 | |
| 2462 Intel 側にもだいぶ embug してしまったようだ。 | |
| 2463 | |
| 2464 basicとかfloatの難易度を上げすぎたか? | |
| 125 | 2465 |
| 2466 mc-code-power.c のlvar は、 | |
| 2467 input arg > 0 | |
| 2468 local var < 0 | |
| 2469 output arg > ARG_OFF | |
| 2470 とするべきだね。 | |
| 2471 | |
| 2472 Mon Mar 24 12:08:43 JST 2003 | |
| 2473 | |
| 2474 addi r27,r1,56 | |
| 2475 addi r29,r28,28 | |
| 2476 mr r3,r27 | |
| 2477 mr r4,r29 | |
| 2478 li r5,372 | |
| 2479 bl L_memcpy$stub | |
| 2480 lwz r4,0(r28) | |
| 2481 lwz r5,4(r28) | |
| 2482 lwz r6,8(r28) | |
| 2483 lwz r7,12(r28) | |
| 2484 lwz r8,16(r28) | |
| 2485 lwz r9,20(r28) | |
| 2486 lwz r10,24(r28) | |
| 2487 mr r3,r28 | |
| 2488 bl _main3 | |
| 2489 | |
| 2490 | |
| 2491 うーむ、最低な奴。最初の28byteだけレジスタ渡しなのか。アドレス | |
| 2492 は変わらないんでしょうけど。まぁ、合わせなくても害は無いけどさ。 | |
| 2493 そのうちね。(そんなに難しくは無いが... また、function が複雑 | |
| 2494 怪奇になるな) しかし浮動小数点レジスタも使うとかそんなんじゃなくて | |
| 2495 良かったかも。 | |
| 2496 | |
| 2497 | |
| 126 | 2498 stwu r1,lo16(-L_9)(r1) |
| 2499 とかしているから、局所変数は64k以内ってことだね。haしてもいいんだけどさ。 | |
| 2500 | |
| 2501 Mon Mar 24 17:07:59 JST 2003 | |
| 2502 | |
| 2503 さて、ようやっと fact-a.c に取り掛かれるわけだけど、今のままだと、 | |
| 2504 input register -> メモリへのsave | |
| 2505 ってのがあるんだよね。これはいただけない。sub routine call すると、 | |
| 2506 r0-r10 は破壊されちゃうし。ということは、code segment の引数は、 | |
| 2507 r29-r20 が良いんじゃないか? 浮動小数点f31-f20を含めて。 | |
| 2508 | |
| 2509 問題は、どこでinput register を指定するかだけど、get_input_register_var | |
| 2510 で code 用かどうかを指定するのが良いかな。fnptr ではダメなので明示した | |
| 2511 方が良いだろう。 | |
| 2512 | |
| 2513 r31, r1 の設定があるのはやむを得まい。r1=r30であった方が良いのだろうか? | |
| 2514 その方がfunction calll の時の変更が少ないだろう。 | |
| 2515 | |
| 2516 メモリとinput register (この場合はr29-r20,f21-f20だけど)の対応は | |
| 2517 どうする? 通常だと呼出側が確保するわけだけど、そうはいかないね。 | |
| 2518 レジスタもsaveする必要が無いから、いろいろ簡単でよろしい。 | |
| 2519 | |
| 2520 あとは、return/environment の扱いだけど。ia32 の方でもいろいろ | |
| 2521 動かなくなっているようだな。 | |
| 2522 | |
| 2523 Mon Mar 24 21:56:47 JST 2003 | |
| 2524 | |
| 2525 うーん、別にフレームを変えないで、そのままでいいか。 | |
| 2526 その方が楽だよね。return しようと思うといちいち | |
| 2527 frame をうごかさないといけないけど、return は | |
| 2528 別処理するんだから、いらないか。 | |
| 2529 | |
| 2530 Wed Mar 26 14:29:21 JST 2003 | |
| 2531 | |
| 2532 で、フレームを変えないとすると、 | |
| 2533 | |
| 2534 <------r1_offset------------------------------> | |
| 2535 * <------------lvar_offset-------> | |
| 2536 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2537 callee arg xx register save ! local caller arg xx | |
| 2538 reg_save disp max_func_args*size_of_int | |
| 2539 lvar>0 lvar<0 lvar>0x1000 0000 | |
| 2540 | |
| 2541 なので、r1/r30 を常に移動させる必要がある。前のcode segement/ | |
| 2542 function がどこにr1/r30を持っていたかを知る手段はないので、 | |
| 2543 jump する前に糢とに戻す必要がある。r30が固定ならばr1のみの | |
| 2544 修正で良く、前に戻す必要はない。 | |
| 2545 | |
| 2546 でも、r1_offset 分を戻せば良いだけなんだから、r30を * に固定 | |
| 2547 しても良いんじゃないか? ! でもいいんだけど。こっちの方が簡単 | |
| 2548 かな? code の場合は register_save は 0 (つまり、マイナス)な | |
| 2549 わけだから。(まぁ、穴を開けておいても良いけど) | |
| 2550 | |
| 2551 Intel の場合はどうして、こうしなかったのか? (でも、最後にチェック | |
| 2552 した時にはcore dumpしていたが...) | |
| 2553 | |
| 2554 ebp <-----esp-----------> | |
| 2555 <------r1_offset------------------------------> | |
| 2556 * <------------lvar_offset-------> | |
| 2557 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2558 callee arg xx register save ! local caller arg xx | |
| 2559 reg_save disp max_func_args*size_of_int | |
| 2560 lvar>0 lvar<0 lvar>0x1000 0000 | |
| 2561 | |
| 2562 というわけなので、* にそろえる方が intel 版とも一致する。 | |
| 2563 ってことは、ebp の移動は intel でもやっていたってこと? | |
| 2564 いやfunctionではこうなっているんだけど、code では違う。 | |
| 2565 | |
| 2566 | |
| 2567 ebp <-----esp-----------> | |
| 2568 <------r1_offset------------------------------> | |
| 2569 * <------------lvar_offset-------> | |
| 2570 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2571 callee arg xx register save ! local caller arg xx | |
| 2572 reg_save disp max_func_args*size_of_int | |
| 2573 lvar>0 lvar<0 lvar>0x1000 0000 | |
| 2574 | |
| 2575 ってわけか。とすると powerpc では、 | |
| 2576 | |
| 2577 r30 <------r1_offset------------------------------> r1 | |
| 2578 # * <------------lvar_offset-------> | |
| 2579 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2580 xx callee arg zz register save ! local caller arg zz | |
| 2581 reg_save disp max_func_args*size_of_int | |
| 2582 lvar>0 lvar<0 lvar>0x1000 0000 | |
| 2583 | |
| 2584 の#にr30を固定してr1をずらすことになる。やっぱ、こっちだよね。 | |
| 2585 zz はから。xx に、base となる関数呼び出しが来る。から、 | |
| 2586 calle arg は破壊される。 | |
| 2587 | |
| 2588 どっちも可能だな。両方実装する? やっぱり後者からかな。gcc は | |
| 2589 前者の方が簡単だろう。 | |
| 2590 | |
| 2591 入力変数をレジスタに割り振ってしまうと、その範囲では | |
| 2592 簡単に動いてしまう。(そりゃ、そうだ...) | |
| 2593 | |
| 2594 goto with environment で構造体を返すのには注意が必要。 | |
| 2595 どこでコピーする? goto した場所? return-continuation? | |
| 2596 そうねぇ。return-continuation 側が普通でしょう。あぁ、 | |
| 2597 でも返し先は元の関数呼び出しの引数上だから壊れちゃって | |
| 2598 いるかもね。だから、とっておく実装の方が良いわけね。 | |
| 127 | 2599 |
| 2600 (なんか -O3 にすると、mc1 が落ちるな...) | |
| 2601 | |
| 2602 Sat Mar 29 16:35:18 JST 2003 | |
| 2603 | |
| 2604 r30 <------r1_offset------------------------------> r1 | |
| 2605 # * <------------lvar_offset-------> | |
| 2606 r+ +------------+---+---------------+----------+--------------+----+ - | |
| 2607 xx callee arg zz register save ! local caller arg zz | |
| 2608 reg_save disp max_func_args*size_of_int | |
| 2609 lvar>0 lvar<0 lvar>0x1000 0000 | |
| 2610 | |
| 2611 このままだと、* が previous r1/r30 になるので、function から | |
| 2612 goto する時に戻り番地やzzにあるはずのsaved r31/r30が破壊されて | |
| 2613 しまう。それは、ちょっと困るということは、一旦、dummy subroutine | |
| 2614 (普通はstub っていうか)を呼び出す方が良い? 戻り番地とprevious r1/r30 | |
| 2615 は持ち歩いているわけだけど... また、r20-r29はつぶされてしまう | |
| 2616 ので、前もってsaveする必要もある。f31-f20も。(結構多いな...) | |
| 2617 | |
| 2618 # * r30 <--------------r1_offset-----------> r1 | |
| 2619 r+ +--+----------+----------+-----------+----------+----+ | |
| 2620 xx zz reg save !callee arg!code local caller arg xx | |
| 2621 r20-r29 | |
| 2622 | |
| 2623 これだと environment は持ち運ぶ必要はない? いや、ある? | |
| 2624 逆に戻り番地を持ち運ぶ必要はなくなるわけね。そっちの | |
| 2625 方がきれいかな。goto-cotinuation みたいな感じか。 | |
| 2626 | |
| 2627 返り側は、 | |
| 2628 | |
| 2629 lwz r1,continuation | |
| 2630 lwz r1,0(r1) | |
| 2631 lwz r0,8(r1) | |
| 2632 mtlr r0 | |
| 2633 lmw r30,-8(r1) | |
| 2634 blr | |
| 2635 | |
| 2636 程度で良い? このr30ってのはgoto先では知り得ない。いや、待てよ、 | |
| 2637 この場合は、r20-r29って決まっているわけか。 | |
| 2638 | |
| 2639 lwz r1,continuation | |
| 2640 set r3/f1 as a return value | |
| 2641 lwz r1,0(r1) | |
| 2642 lwz r0,8(r1) | |
| 2643 mtlr r0 | |
| 2644 lmw r20,-148(r1) (?!) | |
| 2645 blr | |
| 2646 | |
| 2647 で良いわけか。構文は同じでreturn addressは無視することにするか。 | |
| 2648 呼出側は、 | |
| 2649 | |
| 2650 通常の関数呼び出し (引数0) (は、手間0だから..) | |
| 2651 bl L_stub_NN | |
| 2652 L_return: (普通のretrunもあるから、必要な場合がある) | |
| 2653 lwz r1,0(r1) | |
| 2654 lwz r0,8(r1) | |
| 2655 mtlr r0 | |
| 2656 lmw r20,-8(r1) | |
| 2657 blr | |
| 2658 L_stub_NN: | |
| 2659 mflr r0 | |
| 2660 bl L_61 | |
| 2661 L_65: | |
| 2662 lwz r1,0(r1) | |
| 2663 lmw r23,-108(r1) | |
| 2664 b restFP+36 ; restore f23-f31 | |
| 2665 L_61: | |
| 2666 stmw r23,-108(r1) | |
| 2667 stw r0,8(r1) | |
| 2668 b saveFP+36 ; save f23-f31 | |
| 2669 | |
| 2670 ちょっと複雑すぎるかな。特に gcc では、こういう操作は難しいかも。 | |
| 2671 | |
| 2672 あ、そうか。register saveは、このy関数が呼び出された時点で | |
| 2673 やってしまえば良い。そうすれば必要ない。戻り番地も既に xx | |
| 2674 に入っている。だよね。 | |
| 2675 | |
| 2676 * gotoを呼び出した関数のr1 ! r1(goto前のr1) | |
| 128 | 2677 # * r30<--r1_offset-------------> r1 |
| 127 | 2678 r+ +----------+--+----------+----------------+-----------+----------+----+ |
| 2679 cousin arg xx reg save !callee arg !code local caller arg xx | |
| 2680 r20-r29 lvar>0 lvar<0 lvar>0x1000 000 | |
| 2681 f20-f31 <-my_func_args--><--disp-----><-max_func_arg-> | |
| 2682 *size_of_int *size_of_int | |
| 2683 | |
| 2684 とすれば stub は必要ない。cousin arg も保存されている。goto の | |
| 2685 引数のみがlocal変数を上書きする形で格納される。これで、original | |
| 2686 のIA32実装と一致することになる。(引数の保存を除いて。いや、 | |
| 2687 元のも保存されているんじゃないの?) | |
| 2688 | |
| 2689 それで、code segment から関数呼出しするときは? (ってことは、 | |
| 2690 それようのテストも必要なわけか...) | |
| 128 | 2691 |
| 2692 Wed Apr 2 17:40:32 JST 2003 | |
| 2693 | |
| 2694 register 変数が既に使われていても、わざわざsaveする必要はない。 | |
| 2695 戻って来ないから。register を使ったことにするには、used_max_register_var | |
| 2696 を設定してやれば良い。 | |
| 2697 | |
| 2698 Interl版で goto が動かなくなったのは、arg_offset が、register 変数分 | |
| 2699 も取るようになったから。save することを考えると、その方が良い。実際、 | |
| 2700 function call があるとsaveされてしまう。ということは、別に r20-r29 | |
| 2701 である必要はないってことか。通常のinput register varで良い。とすると、 | |
| 2702 register変数をsaveする必要もないね。 | |
| 2703 ただ、input regsiter var は、function callの前には saveする必要が | |
| 2704 ある。でも、これは、やっぱり手遅れか。ってことは、やっぱり、 | |
| 2705 r20-r29が良いってことか。 | |
| 2706 | |
| 2707 jump() では、呼出し引数は、-arg_size つまり、局所変数と | |
| 2708 同じ扱いになっている。ってことは、 | |
| 2709 | |
| 2710 * gotoを呼び出した関数のr1 ! r1(goto前のr1) | |
| 2711 # * r30<----r1_offset---------> r1 | |
| 2712 r+ +----------+--+----------+----------------+-----------+----------+----+ | |
| 2713 cousin arg xx reg save !callee arg !code local caller arg xx | |
| 2714 r20-r29 lvar >0 lvar<0 lvar>0x1000 000 | |
| 2715 f20-f31 <-my_func_args--><--disp-----><-max_func_arg-> | |
| 2716 *size_of_int *size_of_int | |
| 2717 | |
| 2718 r1 <----------------------r30 (return continuation) | |
| 2719 | |
| 2720 で、callee arg は保存されたまま、code local だけ変わるってことだね。 | |
| 2721 | |
| 2722 return continuation で、構造体を返そうと思うと難しい。そもそも、 | |
| 2723 浮動小数点が、ちゃんと返るのか? | |
| 130 | 2724 |
| 2725 Thu Apr 3 13:47:23 JST 2003 | |
| 2726 | |
| 2727 r1 は stack top に保存してあるものを、そのままenvironment | |
| 2728 として渡すのが良い。 | |
| 2729 | |
| 2730 stack 上のデータが64kbyteなのは制限だが、やむをえまい。 | |
| 2731 | |
| 2732 というわけで、powerpc 版の CwC はできあがり。 | |
| 2733 | |
| 2734 return continuation での構造体の引渡し | |
| 2735 function のprototypeでの重複した引数の省略 | |
| 2736 | |
| 2737 あたりが、まだ、テストしていない。あと、 | |
| 2738 | |
| 2739 関数単位での構文木の作成 | |
| 2740 従来のフレーム構造の再利用バージョン | |
| 2741 | |
| 2742 も課題ではある。 | |
| 2743 | |
| 2744 | |
| 2745 Fri Apr 4 10:41:22 JST 2003 | |
| 2746 | |
| 2747 おいぉい、-O3 にすると、mc-codegen.c の arg_register は | |
| 2748 r14 まで使うよ。それは、まずいんでないかい? 困ったなぁ。 | |
| 131 | 2749 |
| 2750 Mon Apr 7 14:29:51 JST 2003 | |
| 2751 | |
| 2752 そういえば、unsigned char は処理してんの? crgvar はあるけど、 | |
| 2753 curgvar とかはないみたいだけど。 | |
| 2754 | |
| 2755 あと、-1.0 とかが d2i とかを生成するのを直してないんでないかい? | |
| 2756 | |
| 2757 MIPS の比較命令は、 | |
| 2758 | |
| 2759 beq $2,$3,$L18 | |
| 2760 | |
| 2761 slt $2,$2,$3 | |
| 2762 bne $2,$0,$L17 | |
| 2763 | |
| 2764 という感じなわけね。(signed less than か?) | |
| 2765 | |
| 2766 だとすると今の方法ではうまくないかも。 | |
| 2767 | |
| 2768 PS2Linuxのアセンブラが低能すぎて、forward reference を全然 | |
| 2769 解決してくれない。どうすりゃいいんだ? | |
| 2770 | |
| 2771 .include を使うと良いらしい。(そんなんでいいのか?!) | |
| 2772 | |
| 2773 csvalue() で取って来たregiserを誰がfreeするの? | |
| 132 | 2774 |
| 2775 Tue Apr 8 14:52:06 JST 2003 | |
| 2776 | |
| 2777 MIPSには bgez とか bgtz とかいう命令があるのね。なんかに | |
| 2778 使えるの? 使えるけどさ。今のコンパイラで使う方法は? | |
| 2779 | |
| 2780 gccが浮動小数点レジスタを避けるようにコンパイルしている | |
| 2781 のは何故だろう? 遅いから? jal dcmp とかは、やっぱり変。 | |
| 2782 | |
| 2783 double と float の差が良くわからない。 | |
| 2784 | |
| 2785 Wed Apr 9 16:20:00 JST 2003 | |
| 2786 | |
| 2787 LOR LAND の定数の扱いを追加 | |
| 2788 | |
| 2789 配列の処理があるから、変数*定数ぐらいのh最適化は | |
| 2790 入れた方が良いかも。その方がレジスタも少なく使うし。 | |
| 2791 (また?) | |
| 2792 | |
| 2793 授業で使うように、また、最適化を落したものが必要かな。 | |
| 2794 | |
| 2795 MIPSの浮動小数点ってさ、single precision しか機械語命令が | |
| 2796 ない? dpsub とかを呼び出すのっておかしくない? (まぁ、 | |
| 2797 いいんだけどさ) | |
| 2798 | |
| 133 | 2799 Fri Apr 11 14:36:33 JST 2003 |
| 2800 | |
| 2801 (二日酔だ...) | |
| 2802 | |
| 2803 要するに、 | |
| 2804 浮動小数点レジスタは single float しか使えない | |
| 2805 double は、すべて、汎用レジスタに置き、計算はすべて、 subroutine | |
| 2806 ってことだよね。(あ〜、やだやだ) | |
| 2807 | |
| 2808 single float だけでの演算を導入するためには、DSUBの他にFSUB | |
| 2809 などを導入する必要がある。これは「うざい」。不可能じゃないけ | |
| 2810 ど、かなりめんどくさいね。浮動小数点誤差の問題もあるし。全部 | |
| 2811 double に変換してから計算すれば問題ないかと言うと、そんなこ | |
| 2812 とはないわけだが。せめて、浮動小数点レジスタ上での演算をおこ | |
| 2813 なうsubroutineはないの? (あるかも知れない) | |
| 2814 | |
| 2815 まぁなぁ。FCOMPとかやればいいだけなんだけど。 | |
| 2816 | |
| 2817 Sat Apr 12 13:30:07 JST 2003 | |
| 2818 | |
| 2819 jal dpadd は、やっぱり、かなり複雑な浮動小数点演算だというが | |
| 2820 わかった。IEEEの形式と合わないとかとかでそうなったんじゃなか | |
| 2821 ろうか? もっとも、PlayStation に合わせてあるのかも知れないけ | |
| 2822 ど。 | |
| 2823 | |
| 2824 ということで、single float 計算を入れないと、もとのgcc との | |
| 2825 差が大きすぎるだろうと思う。ってことは、fmachineop とか FSUB | |
| 2826 を入れないとだめってことか。まぁ、やれば、いいだけなんだけど、 | |
| 2827 他のCPUとの調節がなぁ... | |
| 2828 | |
| 2829 今は、float の演算もpipeline上では1clockなんだろうから、 | |
| 2830 できればdouble でやって欲しいけどね。とはいえ、double/float | |
| 2831 の変換が不要になるので、float base だとMIPSの方が速い | |
| 2832 ってことにはなるかも知れない。 | |
| 2833 | |
| 2834 gdb のdisass を見ると、jal bpadd とかは特定レジスタ | |
| 2835 を使った間接代入になっているらしい。また、disass の | |
| 2836 レジスタ表示が、 | |
| 2837 | |
| 2838 $a0 $a2 $a3 $at $f0 $gp $ra $s0 $s1 $sp $t9 $zero $v1 $f12 $at | |
| 2839 | |
| 2840 とかなので、よくわからん。こまったものだ。これも、 | |
| 2841 ちょっと時間かかるのかな? | |
| 2842 | |
| 2843 | |
| 2844 まぁ、なぁ... ANSI-C に従おうと思うと、このあたりのfloat/double | |
| 2845 はうっとうしいよね。でも、とりあえず動けば良い? | |
| 2846 | |
| 2847 expr の引数として「output type」を入れるか? 基本的には assign | |
| 2848 で決まるtypeを要求する。やっぱり、C の規格書がいるんだろうなぁ。 | |
| 2849 (それは嫌だな...) CbC として、そういうものを入れるのが本当に | |
| 2850 正しいの? (さぁねぇ...) | |
| 2851 float = float op float | |
| 2852 は良いんだけど、 | |
| 2853 double = float op float | |
| 2854 の時に、必要な精度を確保できない。cast すれば良いんだけど、それは | |
| 2855 ANSI-C とは異なる挙動になってしまう。ま、いいか。 | |
| 2856 | |
| 2857 MIPSはdouble=float ということにするっていう手もあるね。 | |
| 2858 その方がきれいか。でも、どうせ、他のCPUもあることを考えると、 | |
| 2859 fbinop するんじゃないの? lbinop も出さないとだめだろうし。 | |
| 2860 short とかunsigned char の扱いもね。(sigh...) | |
| 2861 | |
| 2862 まぁ、時間の問題だから、やれば良いだけなんだけど。めんどい! | |
| 2863 | |
| 2864 (せめてdoubleのルーチンが浮動小数点レジスタを使ってくれれば | |
| 2865 楽だったのに〜) | |
| 2866 | |
| 2867 Mon Apr 14 23:29:37 JST 2003 | |
| 2868 | |
| 2869 やっぱり、ちょっと変更大きいなぁ。 | |
| 134 | 2870 |
| 2871 Fri May 2 14:53:16 JST 2003 | |
| 2872 | |
| 2873 なんでもいいけど、power-pc の test/basic が通らなくなってる。 | |
| 2874 (ま、そうだよな....) struct-pushと args-works の途中で | |
| 2875 動かなくなったらしい。 | |
| 2876 | |
| 2877 あと、引数の引渡しだけど、printf (...) だけ特別扱いしたら? | |
| 2878 プロトタイプがあるのを特別扱いする必要はないんじゃない? | |
| 135 | 2879 |
| 2880 Sat May 3 18:38:57 JST 2003 | |
| 2881 | |
| 2882 わかりました。contains_in_list を修正するのを忘れているね。 | |
| 2883 あと、get_register は、どうせ足りなくなるわけだろ? その | |
| 2884 時はどうするの? 足りなくなるのは関数呼び出しの時だけ? | |
| 2885 (かな?) | |
| 2886 | |
| 2887 だとすれば、関数呼び出しのsaveの変数を局所変数も使えるように | |
| 2888 すれば良いだけだね。 | |
| 2889 | |
| 2890 Sun May 4 09:18:32 JST 2003 | |
| 2891 | |
| 2892 関数呼び出し時の浮動小数点を格納する、r8,r9 の扱いが | |
| 2893 おかしい。 | |
| 2894 | |
| 2895 emit_push / tosop で局所変数だけは特別扱い | |
| 2896 した方がいいんじゃない? register full だと、 | |
| 2897 | |
| 2898 register にload (emit_push) | |
|
136
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2899 register full でそれを局所変数に代入 (*) |
| 135 | 2900 演算時にregisterに再代入 |
| 2901 | |
|
136
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2902 まぁねぇ。それだと、mc-code-386.c の時代に戻るわけ |
|
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2903 だけど。まぁ、その方がいいのかな。もっとも、(*) |
|
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2904 が起こらなければ、特に問題はないんだけどね。 |
|
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2905 |
|
069960078249
remove redundant funcall argument for prototyped code in PowerPC case.
kono
parents:
135
diff
changeset
|
2906 局所変数、大域変数、定数の足し算とかは処理した方がいいのかなぁ。 |
| 137 | 2907 |
| 2908 Sun May 4 15:10:48 JST 2003 | |
| 2909 | |
| 2910 たぶん、oprt とかは、それほど効果は無いよ。効くのは、 | |
| 2911 register full の時だけだろ? | |
| 2912 | |
| 2913 MIPS version は、まだまだ全然と言う感じ。ゆっくり | |
| 2914 片付けて行くしかないね。 | |
| 2915 | |
| 2916 Sun May 4 18:29:26 JST 2003 | |
| 2917 | |
| 2918 d50 では、引数はレジスタに $4,$5,$6,$7 の double 二つしかのらない。 | |
| 2919 | |
| 2920 f50 では、引数は | |
| 2921 $f12,$f14,$6,$7 | |
| 2922 というように4つ乗るらしい。(こまったもんだ...) | |
| 2923 | |
| 2924 i50では、$4,$5,$6,$7 だね。 | |
| 2925 | |
| 2926 あとはstackに積むみたいね。 | |
| 2927 | |
| 2928 これらを get_input_register_var で処理するわけか。 | |
| 138 | 2929 |
| 2930 Mon May 5 15:28:07 JST 2003 | |
| 2931 | |
| 2932 code_fconst/code_dconst と code_drgvar(e4,d,reg) みたいなのが | |
| 2933 入混じってるな。ま、いいんだけど。 | |
| 2934 | |
| 2935 やっぱり、後者に統一。(めんどさ〜) free で d を指定するのはまずい。 | |
| 141 | 2936 |
| 2937 Thu May 8 11:02:42 JST 2003 | |
| 2938 | |
| 2939 regs/fregs の複数は必要ないんじゃないか? 一つで良い? 外から | |
| 2940 は見えないから、mc-code-mips だけでそうするのが良い。 | |
| 2941 | |
| 2942 register のやり方を工夫しないとだめか。 | |
| 2943 | |
| 2944 あーめんどい.... 本当に動くのか? | |
| 2945 | |
| 2946 double のライブラリ呼び出しで$3,$4,$5,$6 を使うわけだけど、 | |
| 2947 ここは必ずあけておかなければいけないわけだよね。でも、実際に | |
| 2948 は、ライブラリの呼び出し後には$3,$4 が使われてしまう。ここで、 | |
| 2949 emit_push されると気まずいが... | |
| 2950 | |
| 2951 本当のfunction callと同じ扱いでもいいんだけど、それだと | |
| 2952 ちょっときつくない? | |
| 2953 | |
| 2954 なんか浮動小数点レジスタ変数へのdpreinc/dpostinc を定義して | |
| 2955 ないんじゃない? それは、まずいんじゃないの? dassop もそうか? | |
| 2956 あれ? なんか何もしてないみたいだな。Intel 版にはレジスタ変数 | |
| 2957 がないから、テストしなかったのか。code の引数はレジスタに割 | |
| 2958 り当てられるから、そのあたりでテストすることは可能だろうね。 | |
| 2959 まぁ、これ自体は難しくはないが... | |
| 2960 | |
| 142 | 2961 code segment では浮動小数点レジスタに割り振られてしまうので、 |
| 2962 実はエラーが出ていたんじゃないかな。これはテストプログラム | |
| 2963 を書くべきでしょうね。 | |
| 2964 | |
| 141 | 2965 あるいは#define REG register でテストする必要があるわけね。 |
| 2966 | |
| 2967 MIPSでは、$4,$5,$6,$7 は、本当に特別扱いしないとだめだね。 | |
| 142 | 2968 |
| 2969 Thu May 15 21:25:45 JST 2003 | |
| 2970 | |
| 2971 fregv は、やっぱりサブルーチン・コールにするんだろ? | |
| 2972 (さすがに授業が始まってしまうと、なかなか進まない...) | |
| 2973 | |
| 2974 Sat May 17 13:57:12 JST 2003 | |
| 2975 | |
| 2976 $4,$5 を常に creg または、double のfregとして使う。 | |
| 2977 $f12 はfloating 用。 | |
| 2978 | |
| 2979 もちろん、emit_pushすればずれちゃうけどね。rename するべきか? | |
| 2980 そもそもrenameは必要ないんじゃないの? | |
| 2981 | |
| 2982 あともう少しなんだけどねぇ。やる気がでん... | |
| 143 | 2983 |
| 2984 Tue May 20 11:08:44 JST 2003 | |
| 2985 | |
| 2986 freg と同じように dreg を作る? (そうすると ia32 | |
| 2987 の書き直しがあるが、それは良いとして...) | |
| 2988 | |
| 2989 でも、mc-codegen.c が creg/freg に依存しているから、 | |
| 2990 それを書き直すのが結構めんどくさい。書き直して | |
| 2991 大丈夫なのか? ううーん... | |
| 2992 | |
| 2993 逆にcreg/dreg/freg を無くすってのは? 全部、creg で | |
| 2994 やるわけだな。ちょっと書き直しが多いけど。原理的には | |
| 2995 それでいいはずだけど。着目しているcurrent register | |
| 2996 は一つのはずだから。 | |
| 2997 (1) | |
| 2998 creg int | |
| 2999 freg double/float | |
| 3000 | |
| 3001 ってなっているからおかしいのであって、 | |
| 3002 (2) | |
| 3003 creg int/double/float | |
| 3004 か、 | |
| 3005 (3) | |
| 3006 creg int | |
| 3007 freg double | |
| 3008 greg float | |
| 3009 だよねぇ。 | |
| 3010 | |
| 3011 やっぱり(2)かなぁ。long long のことをとかを考えると。 | |
| 3012 でも、とりあえず(1)でやるか。 | |
| 144 | 3013 |
| 3014 いずれにせよ、fregv を追放することからはじめるんじゃない? | |
| 3015 | |
| 3016 それはできました。 | |
| 145 | 3017 |
| 3018 Thu May 22 23:40:13 JST 2003 | |
| 3019 | |
| 3020 3808 macro = (char *)car(nptrm->dsp); | |
| 3021 3809 if (nptrm->sc==MACRO) { | |
| 3022 3810 while((*macropp++ = *macro++)); | |
| 3023 3811 macropp[-1]=c; | |
| 3024 (gdb) | |
| 3025 3812 } else if (nptrm->sc==FMACRO) { | |
| 3026 3813 if(c!='(') error(MCERR); | |
| 3027 3814 *macropp++=0; | |
| 3028 3815 macrop = macro_function(macrop,&body,nptrm, | |
| 3029 3816 list2((int)macro,history)); | |
| 3030 | |
| 3031 MACRO の場合のrecursive な処理を忘れいているみたいだけど。 | |
| 3032 それでも良かったはずなんだけど、macro_buf がstatic なので | |
| 3033 不都合が出ているみたいね。 | |
| 3034 | |
| 3035 recursive に処理すると、 | |
| 3036 #deifne car(e) heap[e] | |
| 3037 car(e) | |
| 3038 みたいな時にまずい。これは、どうするんだっけ? | |
| 3039 | |
| 3040 LMACRO ってのがあったみたいね。 | |
| 147 | 3041 |
| 3042 Sun May 25 21:48:46 JST 2003 | |
| 3043 | |
| 3044 macro_eval がまだおかしいのは置いといて... | |
| 3045 | |
| 3046 単純にcreg/fregを統一してしまうと、 | |
| 3047 fdecl で creg をセット | |
| 3048 した時に、float/double/int にどれかに固定される。そのまま、 | |
| 3049 coce_rlvar(creg) とかを呼ばれてしまうので、ちょっと困る。 | |
| 3050 code_rlvar で、if(!is_int_reg(creg)) creg = ireg; | |
| 3051 とかすればいいんだけど、それは、ちょっと変だよね? | |
| 3052 | |
| 3053 そもそも、mc-codgen.c でcregを持ち歩いている理由は? | |
| 3054 なんかあったような気がするが... | |
| 3055 | |
| 3056 そうか、 | |
| 3057 use_int_reg() | |
| 3058 とかしてやれば良いわけね。(rname を使うかどうかはともかく) | |
| 3059 | |
| 3060 code_rlvar とかで設定するregisterを勝手に変えられると | |
| 3061 うれしくない。(よね?) codegen 側で use_int_reg()とか | |
| 3062 できればいいんじゃないの? | |
| 3063 | |
| 3064 Mon May 26 21:06:14 JST 2003 | |
| 3065 | |
| 3066 code_* 側でやるか、mc-codegen 側で行うか? どっちかなぁ。 | |
| 3067 code_* 側の方が良いような気もするけど。 | |
| 3068 | |
| 3069 Thu May 29 10:30:09 JST 2003 | |
| 3070 | |
| 3071 freg/creg の区別は mc-codegen 側でやっていたんだから、 | |
| 3072 mc-codegen 側でやらないと、mc-cdoe-* 側での動的 | |
| 3073 チェックが増えすぎてしまう。 | |
| 3074 | |
| 3075 creg/freg を共有するのは良いのだが、その設定は | |
| 3076 mc-codegen 側ですべきなんじゃないの? | |
| 3077 | |
| 3078 mc-code-* 側を修正するとバグが取り切れない... | |
| 3079 (といいつつ、もう、すぐなんだろうけど... でも、なぁ) | |
| 3080 | |
| 3081 cast を自分で定義できる言語なら簡単なんだろうけど。 | |
| 3082 | |
| 3083 Tue Jun 3 13:03:41 JST 2003 | |
| 3084 | |
| 3085 あぁ、なんか乗り切れない。CONV の直前でcregが不定だ。 | |
| 3086 どっかで use_float を忘れているんだろうな。 | |
| 148 | 3087 |
| 3088 Wed Jun 11 12:27:58 JST 2003 | |
| 3089 | |
| 3090 なんか、ようやっと creg/ireg/freg が片付いたよ。 | |
| 3091 creg を変更したときに、ireg を変更し忘れることが多かった | |
| 3092 みたい。set_creg を必ず使うようにすれば良いだけだと思う | |
| 3093 のだが。 | |
| 3094 | |
| 3095 Thu Jun 12 19:34:48 JST 2003 | |
| 3096 | |
| 3097 まぁ、MIPS用のレジスタ割り当てを書かないとだめだね。 | |
| 3098 ちゃんと書いてもいいんだけどさ。なんか one path に | |
| 3099 するのが面白いんでしょ? | |
| 3100 | |
| 3101 Sun Jul 13 18:26:29 JST 2003 | |
| 3102 | |
| 3103 また、一カ月なにも書かなかったのか。 mips は、mc-code-power.c | |
| 3104 から書き直した方が良さそうだね。 | |
| 3105 | |
| 3106 regs/regv は、i/f/d のすべてのレジスタに関して一つ | |
| 3107 | |
| 3108 でないと stack に積むのを統一できないから。そういう意味では、 | |
| 3109 reg_stack と freg_stack を区別する意味はないわけね。でもstack | |
| 3110 は型付けした方が良いから。でも、区別しておくと、long を増や | |
| 3111 した時にも、stack を増やさないとだめなんじゃない? なので区別 | |
| 3112 しない方が良い。でも、それに手をつけると、また時間かかるんじ | |
| 3113 ゃないの? そのためにはスタックそのものに型付けしないとだめだ | |
| 3114 から結局同じか。 | |
| 3115 | |
| 3116 mips の double を格納するためのregister pairは、regs に | |
| 3117 格納する。regs にアクセスには必ずアクセス関数を通す。 | |
| 3118 なるほど。 | |
| 3119 | |
| 3120 get_input_dregister_var なんだけど、dregister pair の | |
| 3121 場合は、常にpairが決まった値になる必要があるよね。 | |
| 3122 この分はどうする? 前もってとっておくか? | |
| 3123 | |
| 3124 あ、そうか、任意のregister pairを許さなくても良いよ。input register | |
| 3125 に対応する連続したregister pair だけを許そう。そうすれば、あ | |
| 3126 まり気にしなくても良くなるから。でも、gcc が奇数pairを許して | |
| 3127 いたら気まずくない? | |
| 3128 | |
| 3129 regv は、register rename がなければいらないんじゃない? | |
| 150 | 3130 |
| 3131 Mon Jul 14 10:54:46 JST 2003 | |
| 3132 | |
| 3133 なんかなぁ... creg/ireg/freg/dreg は、あんまり良いアイデア | |
| 3134 では、なかったみたい。creg は、このうちのどれかでなくては | |
| 3135 ならないんだが、それを保証できない。 | |
| 3136 | |
| 3137 前と同じで、creg を廃止して、ireg/freg/dreg/lreg とするか? | |
| 151 | 3138 |
| 3139 Mon Jul 14 14:25:23 JST 2003 | |
| 3140 | |
| 3141 なんか unsigned が通らなくなっているみたい。 | |
| 153 | 3142 |
| 3143 Sun Jul 20 17:37:34 JST 2003 | |
| 3144 | |
| 3145 やっぱり dictionary は、書き直さないとだめだよな。 | |
| 3146 それに関して、heap も修正した方が良い。このコード | |
| 3147 はあんまりだものなぁ。 | |
| 3148 | |
| 3149 さて、あとは、オフセットだけど... めんど... | |
| 3150 | |
| 3151 Mon Jul 21 15:12:56 JST 2003 | |
| 3152 | |
| 3153 Frame pointer は使うの? 使った方がいいんじゃない? | |
| 3154 PowerPC は使わなかったけど。 | |
| 154 | 3155 |
| 3156 Tue Jul 22 08:12:48 JST 2003 | |
| 3157 | |
| 3158 switch 文をtableにコンパイルするには... | |
| 3159 | |
| 3160 最初の比較の行き先を後で指定するようにする | |
| 3161 cmp reg,case_value | |
| 3162 bne L_NEXT | |
| 3163 .... | |
| 3164 L_NEXT: | |
| 3165 を、 | |
| 3166 cmp reg,case_value | |
| 3167 bne L_CASE | |
| 3168 .... | |
| 3169 L_NEXT: | |
| 3170 .... | |
| 3171 L_CASE | |
| 3172 で、case 文が終ったらtableを作る。table がいらないようだったら、 | |
| 3173 L_CASE = L_NEXT | |
| 3174 | |
| 3175 各caseの入口は覚えておく。 | |
| 3176 (list of (value, label)) | |
| 3177 | |
| 3178 table は、どうやって作るかと言うと、 | |
| 3179 | |
| 3180 まず、値の分布をチェックする | |
| 3181 密度の高い表を作る(端のいくつかを除いて連続していること) | |
| 3182 というか、(定差分で)連続している部分にだけ表を作れば良いか。 | |
| 3183 table は8entry以上。それ以下は、2分法に負ける。 | |
| 3184 (list of (number of entry, diff, (list of (value,label)))) | |
| 3185 | |
| 3186 512 or 128kbyte まで容認する。限度はなくても良いか。連続している | |
| 3187 部分にしか表は作らない。 | |
| 3188 | |
| 3189 連続してない部分は、2分法にする。 | |
| 3190 | |
| 3191 2 分法でもいいけど。2分法にする? その方が簡単かな。最後のス | |
| 3192 テージは、(順序が一致していれば...) 元のコードが使えるし。そ | |
| 3193 うすると、sort して、真中かから比較して行けば良い。そうすれ | |
| 3194 ば表の分布とか考えなくても良いからいいかもね。 | |
| 3195 | |
| 3196 簡単じゃん。 | |
| 3197 | |
| 3198 まぁ、やっぱり、構文木の先読みをするんじゃないの? そうすれば | |
| 3199 reference のとられてない変数もわかるし。 | |
| 3200 | |
| 3201 Wed Jul 23 16:21:12 JST 2003 | |
| 3202 | |
| 3203 やっぱり構造体のタグの名前はname tableにいれちゃだめだね。 | |
| 3204 まぁ、いれなきゃいけないんだけどさ。どうする? | |
| 3205 どうするっていっても... | |
| 3206 | |
| 3207 Thu Jul 31 15:07:08 JST 2003 | |
| 3208 | |
| 3209 C から変換したコードは動いたけど。まぁ、cast は動くのは | |
| 3210 良いんだけど、こういうのじゃなくて、link を使った変換 | |
| 3211 でもいいんじゃない? そうすれば、spagety stack でもOk | |
| 3212 だな。ただ、GC がないと使い物にならないだろうが。 | |
| 3213 | |
| 3214 Link にすれば、型整合のある変換も可能だよね。ただ、union | |
| 3215 は意味ないか。record 型に直さないとね、 | |
| 3216 | |
| 3217 recursion と loop をdetect すれば、static にcompile | |
| 3218 できる。あるいは、recursion の部分だけ配列にできる | |
| 3219 んじゃないかな。 | |
| 3220 | |
| 3221 それぞれの利点と欠点を考察すればCWは通るんじゃない? | |
| 3222 (本気?) | |
| 155 | 3223 |
| 3224 Mon Aug 4 12:48:40 JST 2003 | |
| 3225 | |
| 3226 converted call | |
| 3227 480 | |
| 3228 8.070u 0.010s 0:08.22 98.2% 0+0k 0+2io 0pf+0w | |
| 3229 call | |
| 3230 480 | |
| 3231 6.590u 0.000s 0:06.67 98.8% 0+0k 0+0io 0pf+0w | |
| 3232 | |
| 3233 だいたい10%ぐらい遅いなぁ。(なんで?) げ、-O6 だと十倍違う... | |
| 3234 | |
| 3235 げ、powerpc の subroutine 内のstaticが通らんじゃん。 | |
| 3236 | |
| 3237 サブルーチンを三段に直しました。 | |
| 3238 | |
| 3239 % time ./a.out 0 | |
| 3240 720 | |
| 3241 9.590u 0.010s 0:09.64 99.5% 0+0k 0+0io 0pf+0w | |
| 3242 % time ./a.out 1 | |
| 3243 719 | |
| 3244 12.610u 0.020s 0:12.71 99.3% 0+0k 0+0io 0pf+0w | |
| 3245 % time ./a.out 2 | |
| 3246 720 | |
| 3247 6.310u 0.020s 0:06.41 98.7% 0+0k 0+0io 0pf+0w | |
| 3248 % vi test/conv1.c | |
| 3249 % gcc -O6 test/conv1.c | |
| 3250 % ./a.out 0 | |
| 3251 720 | |
| 3252 % time ./a.out 0 | |
| 3253 720 | |
| 3254 1.990u 0.020s 0:02.03 99.0% 0+0k 0+2io 0pf+0w | |
| 3255 % gcc test/conv1.c | |
| 3256 % time ./a.out 0 | |
| 3257 720 | |
| 3258 7.530u 0.000s 0:07.64 98.5% 0+0k 0+0io 0pf+0w | |
| 3259 % gcc -O2 test/conv1.c | |
| 3260 % time ./a.out 0 | |
| 3261 720 | |
| 3262 3.520u 0.010s 0:03.55 99.4% 0+0k 0+0io 0pf+0w | |
| 3263 % | |
| 3264 | |
| 3265 ま、こんなものかな。-O2 に負けるなよって気もするが。 | |
| 3266 | |
| 3267 琉大は40Mbps | |
| 3268 | |
| 3269 Intel PC (on PowerPC) の場合 | |
| 3270 | |
| 3271 [root@localhost ~/device]# time ./a.out 2 | |
| 3272 470 | |
| 3273 0.660u 0.010s 0:02.37 28.2% 0+0k 0+0io 92pf+0w | |
| 3274 [root@localhost ~/device]# time ./a.out 3 | |
| 3275 720 | |
| 3276 0.920u 0.020s 0:01.74 54.0% 0+0k 0+0io 92pf+0w | |
| 3277 [root@localhost ~/device]# gcc test/conv1.c | |
| 3278 [root@localhost ~/device]# ./a.out 0 | |
| 3279 | |
| 3280 [root@localhost ~/device]# time ./a.out 0 | |
| 3281 720 | |
| 3282 1.310u 0.030s 0:01.39 96.4% 0+0k 0+0io 92pf+0w | |
| 3283 [root@localhost ~/device]# gcc -O test/conv1.c | |
| 3284 [root@localhost ~/device]# time ./a.out 0 | |
| 3285 720 | |
| 3286 1.130u 0.030s 0:01.16 100.0% 0+0k 0+0io 92pf+0w | |
| 3287 [root@localhost ~/device]# gcc -O4 test/conv1.c | |
| 3288 [root@localhost ~/device]# time ./a.out 0 | |
| 3289 720 | |
| 3290 0.870u 0.000s 0:00.87 100.0% 0+0k 0+0io 92pf+0w | |
| 3291 [root@localhost ~/device]# gcc -O6 test/conv1.c | |
| 3292 [root@localhost ~/device]# time ./a.out 0 | |
| 3293 720 | |
| 3294 0.850u 0.020s 0:00.88 98.8% 0+0k 0+0io 92pf+0w | |
| 3295 [root@localhost ~/device]# | |
| 3296 | |
| 3297 PowerPC の場合は、PIC symbol がやっぱり遅いね。 | |
| 3298 こいつをなんとかするだけでだいぶ違うかも知れない。 | |
| 156 | 3299 |
| 3300 Tue Aug 5 13:53:43 JST 2003 | |
| 3301 | |
| 3302 む、なんか、もう、そうなってるじゃん。 | |
| 3303 | |
| 3304 関数scope 内の staticの初期化が通らないんですけど。 | |
| 3305 | |
| 3306 直りました。対応してなかったみたいね。 | |
| 158 | 3307 |
| 3308 Wed Aug 6 12:07:07 JST 2003 | |
| 3309 | |
| 3310 [kono@pw001 ~/device]% ./mc -s test/conv1.c | |
| 3311 [kono@pw001 ~/device]% gcc test/conv1.s | |
| 3312 [kono@pw001 ~/device]% time ./a.out 1 | |
| 3313 セグメントエラー (coreを出力しました) | |
| 3314 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w | |
| 3315 [kono@pw001 ~/device]% time ./a.out 2 | |
| 3316 470 | |
| 3317 0.350u 0.000s 0:00.35 100.0% 0+0k 0+0io 88pf+0w | |
| 3318 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3319 720 | |
| 3320 0.650u 0.010s 0:00.65 101.5% 0+0k 0+0io 88pf+0w | |
| 3321 [kono@pw001 ~/device]% time ./a.out 1 | |
| 3322 セグメントエラー (coreを出力しました) | |
| 3323 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w | |
| 3324 [kono@pw001 ~/device]% time ./a.out 2 | |
| 3325 470 | |
| 3326 0.350u 0.000s 0:00.35 100.0% 0+0k 0+0io 88pf+0w | |
| 3327 [kono@pw001 ~/device]% time ./a.out 3 | |
| 3328 720 | |
| 3329 0.380u 0.000s 0:00.38 100.0% 0+0k 0+0io 88pf+0w | |
| 3330 [kono@pw001 ~/device]% time ./a.out 4 | |
| 3331 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 77pf+0w | |
| 3332 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3333 720 | |
| 3334 0.660u 0.000s 0:00.65 101.5% 0+0k 0+0io 88pf+0w | |
| 3335 [kono@pw001 ~/device]% time ./a.out 1 | |
| 3336 セグメントエラー (coreを出力しました) | |
| 3337 0.010u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w | |
| 3338 [kono@pw001 ~/device]% time ./a.out 2 | |
| 3339 470 | |
| 3340 0.350u 0.010s 0:00.35 102.8% 0+0k 0+0io 88pf+0w | |
| 3341 [kono@pw001 ~/device]% time ./a.out 3 | |
| 3342 720 | |
| 3343 0.390u 0.000s 0:00.38 102.6% 0+0k 0+0io 88pf+0w | |
| 3344 [kono@pw001 ~/device]% time ./a.out 4 | |
| 3345 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 77pf+0w | |
| 3346 [kono@pw001 ~/device]% gcc test/conv1.c | |
| 3347 [kono@pw001 ~/device]% time ./a.out 1 | |
| 3348 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 77pf+0w | |
| 3349 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3350 720 | |
| 3351 0.430u 0.000s 0:00.42 102.3% 0+0k 0+0io 88pf+0w | |
| 3352 [kono@pw001 ~/device]% gcc -O test/conv1.c | |
| 3353 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3354 720 | |
| 3355 0.370u 0.000s 0:00.36 102.7% 0+0k 0+0io 88pf+0w | |
| 3356 [kono@pw001 ~/device]% gcc -O2 test/conv1.c | |
| 3357 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3358 720 | |
| 3359 0.370u 0.000s 0:00.37 100.0% 0+0k 0+0io 88pf+0w | |
| 3360 [kono@pw001 ~/device]% gcc -O6 test/conv1.c | |
| 3361 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3362 720 | |
| 3363 0.240u 0.010s 0:00.25 100.0% 0+0k 0+0io 88pf+0w | |
| 3364 | |
| 3365 Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/specs | |
| 3366 gcc version 2.95.3 20010315 (release) | |
| 3367 Intel Architecture だと、結構、良い線いっているみたい。 | |
| 159 | 3368 |
| 3369 Thu Aug 14 02:39:29 JST 2003 | |
| 3370 | |
| 3371 done | |
| 3372 [kono@pw001 ~/device]% time ./a.out 0 | |
| 3373 720 | |
| 3374 0.640u 0.000s 0:00.63 101.5% 0+0k 0+0io 88pf+0w | |
| 3375 [kono@pw001 ~/device]% time ./a.out 1 | |
| 3376 719 | |
| 3377 0.720u 0.000s 0:00.71 101.4% 0+0k 0+0io 88pf+0w | |
| 3378 [kono@pw001 ~/device]% time ./a.out 2 | |
| 3379 470 | |
| 3380 0.330u 0.000s 0:00.33 100.0% 0+0k 0+0io 88pf+0w | |
| 3381 [kono@pw001 ~/device]% time ./a.out 3 | |
| 3382 720 | |
| 3383 0.370u 0.010s 0:00.37 102.7% 0+0k 0+0io 88pf+0w | |
| 3384 | |
| 160 | 3385 |
| 3386 +jessica+kono time ./a.out 0 | |
| 3387 720 | |
| 3388 1.190u 0.010s 0:01.51 79.4% 0+0k 0+0io 0pf+0w | |
| 3389 +jessica+kono time ./a.out 1 | |
| 3390 719 | |
| 3391 1.700u 0.000s 0:01.78 95.5% 0+0k 0+0io 0pf+0w | |
| 3392 +jessica+kono time ./a.out 2 | |
| 3393 470 | |
| 3394 0.630u 0.000s 0:00.66 95.4% 0+0k 0+0io 0pf+0w | |
| 3395 +jessica+kono time ./a.out 3 | |
| 3396 720 | |
| 3397 0.790u 0.000s 0:00.81 97.5% 0+0k 0+0io 0pf+0w | |
| 3398 +jessica+kono time ./a.out 4 | |
| 3399 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w | |
| 3400 | |
| 3401 +jessica+kono gcc test/conv1.c | |
| 3402 +jessica+kono time ./a.out 0 | |
| 3403 720 | |
| 3404 0.960u 0.000s 0:00.97 98.9% 0+0k 0+2io 0pf+0w | |
| 3405 +jessica+kono gcc -O test/conv1.c | |
| 3406 +jessica+kono time ./a.out 0 | |
| 3407 720 | |
| 3408 0.470u 0.000s 0:00.48 97.9% 0+0k 0+0io 0pf+0w | |
| 3409 +jessica+kono gcc -O6 test/conv1.c | |
| 3410 +jessica+kono time ./a.out 0 | |
| 3411 720 | |
| 3412 0.260u 0.000s 0:00.26 100.0% 0+0k 0+0io 0pf+0w | |
| 3413 | |
| 3414 Mon Sep 1 13:49:43 JST 2003 | |
| 3415 | |
| 3416 short がやっぱり欲しいよね。long long はともかく... | |
| 3417 そこまでいくと、ANSI-C 対応にできるんだが。long long | |
| 3418 は難しい? | |
| 3419 | |
| 3420 short は、そんなに難しくないはず。あとは、 | |
| 3421 statement を含めたtreeの処理 | |
| 3422 変換系の完成 | |
| 3423 この二つだな。GCC に組み込むのは無理だろう。 | |
| 3424 | |
| 3425 属性文法みたいな手法が使えればね。 | |
| 3426 | |
| 3427 あと、struct のtag。やっぱりword table を作り直さないと。 | |
| 3428 | |
| 3429 Wed Sep 10 21:53:16 JST 2003 | |
| 3430 | |
| 3431 short や unsigned short の前に、 | |
| 3432 なんか unsigned char もないんですけど。 | |
| 3433 | |
| 3434 Wed Oct 8 22:43:17 JST 2003 | |
| 3435 | |
| 3436 (また、一カ月、触ってないのか...) | |
| 3437 | |
| 3438 無名 code はあった方がいいんじゃない? | |
| 3439 | |
| 3440 code *a(int i); | |
| 3441 a = code(int j) { } | |
| 3442 | |
| 3443 みたいな感じ? C にはないけどね。もともと、名前を消費する | |
| 3444 方だからあった方がいいかも。でも、実行時に作られるわけじゃない。 | |
| 3445 それに、こういうものを作ると closure だと思われるような | |
| 3446 気もする。closure みたいなものは「自分で管理する」ってのが | |
| 3447 CbC の思想だろ? | |
| 3448 | |
| 3449 そういえば、static なcodeはあった方がいいんじゃない? | |
| 3450 | |
| 3451 static code func() { .... } | |
| 3452 | |
| 3453 か。それはそうだな。 | |
| 3454 | |
| 3455 Fri Oct 10 13:08:01 JST 2003 | |
| 3456 | |
| 3457 link register をうまく使うにはcontinuationに | |
| 3458 指定するだけではダメで、 | |
| 3459 goto hoge(....,next); | |
| 3460 code next.. | |
| 3461 みたいなのがあった方がいいんじゃない? | |
| 3462 | |
| 3463 goto の後のステートメントは無名codeになればいいんだよね。 | |
| 3464 | |
| 3465 stack を使わないサブルーチンみたいなものか。単なるcall | |
| 3466 になるわけね。それもいいかも。 | |
| 3467 | |
| 3468 Sat Nov 22 15:51:36 JST 2003 | |
| 3469 | |
| 3470 構造体のfieldの定義のnptrは、大域の名前テーブルから | |
| 3471 取り除かないといけない。でも、取り除いていしまうと、 | |
| 3472 構造体からのポインタがずれちゃうので、まずい。 | |
| 3473 | |
| 3474 filed専用の領域を作るのだと、複数の構造体が同じ | |
| 3475 field名を持つときにちょっと困る。構造体のタイプに | |
| 3476 埋め込むのがいいんだけど... | |
| 3477 | |
| 3478 そうすると、構造体のfiledかどうかをgetsymがチェック | |
| 3479 するときにちょっと困る。 | |
| 3480 | |
| 161 | 3481 filed をlinear searchするのは嫌だけど、しかたないか。 |
| 3482 | |
| 3483 なんか、struct の中に、 | |
| 3484 void (*case_)(int cases,int def); | |
| 3485 とかがあると、 | |
| 3486 void (*case_)(); | |
| 3487 int cases; | |
| 3488 int def; | |
| 3489 という感じで余計なfieldが定義されてるみたい。 | |
| 3490 | |
| 3491 adecl で nptr が引数の最後を指してしまうのがまずかった。 | |
| 164 | 3492 |
| 3493 Mon Nov 24 00:52:31 JST 2003 | |
| 3494 | |
| 3495 signed char は実装しましたが... test routine がない。 | |
| 3496 | |
| 3497 あと、short は、code_crxxxx の中でbyteの大きさに従って | |
| 3498 処理するのがいいかな。 | |
| 3499 |