Mercurial > hg > CbC > old > device
changeset 724:e60c3d8dadd6
convert to UTF-8
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 08 Nov 2008 15:11:06 +0900 |
parents | c2fb8e2b1dca |
children | 3f1f6c0610c1 |
files | Changes Idea README.jp mc-code-arm.c mc-code-ia32.c mc-code-mips.c mc-code-powerpc.c mc-codegen.c tools/regs.pl |
diffstat | 9 files changed, 6706 insertions(+), 6704 deletions(-) [+] |
line wrap: on
line diff
--- a/Changes Fri Nov 07 20:12:29 2008 +0000 +++ b/Changes Sat Nov 08 15:11:06 2008 +0900 @@ -1,87 +1,87 @@ Thu Nov 25 17:27:12 JST 1999 -subroutine call がない -局所変数もない -その代わり、大域変数を多用する -大域変数のスコープは局所的 -Fortran の用に局所変数は静的に取る -recursion する時には、自分で保存する -subroutine call時のレジスタのセーブも局所的に行う -それは、ちょっと変じゃない? -やっぱりデフォルトのフレームは持ち歩くか? - -recursive call とそうでないのを区別するか? - -fp は用意する方が良い - -関数定義と同時に、それ専用のfpの構造体を用意する - -C をcompileする時には、stackを持ち歩く +subroutine call +絮紊違 +篁c紊у紊違紊 +紊у紊違鴻潟若絮 +Fortran 絮紊違 +recursion т絖 +subroutine call吾鴻帥祉若絮茵 +<c紊? +c宴若≧? + +recursive call с阪ャ? + +fp 鴻 + +∽医臂絨fp罕篏 + +C compilestack≧ fp = (struct func_state *)stack -えっと、どこに代入するの? そういう問題もあるわけね。 -じゃあ、fpは特別? それは気に入らないな。static -なfpにすれば良いわけね。 +c篁eャ? 馹 +fp劫? 羂ャstatic +fp域 func(void *stack) { static struct func_state { static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -func_state をとってくる演算子があった方が良い? そうね。 +func_state c羲膊絖c鴻? func.state -ぐらい? - -fp->local1 みたいなことだけするなら、C と同じになる。 - -call する時のargument も、 - static な func_state に置く - stack 上の func_state に置く -という二通りの選択肢がある。Cと互換なら、当然、後者。 - -Recursive なら後者だが、この言語は状態遷移を記述するから、static -なものでも良いはず。 - -Internal function は? あってもいいんだけど... - -Recursive call する時には、 fp をsaveする必要があるね。 +? + +fp->local1 帥C + +call argument + static func_state 臀 + stack 筝 func_state 臀 +篋御≪C篋綵吟緇 + +Recursive 緇荐茯倶欠Щ荐菴違static +с + +Internal function ? c... + +Recursive call fp save綽荀 (--(struct func_state *)stack) = fp; call callee(&fp->arg,continuation,stack); -call しても、戻って来ないから... continuation は一般的にはcode -だから... それは Internal function にするか。 - -continuation に一般的にcompileする方法を考えないといけないか。 -self は必要なわけね? - -言語の名前も考えないといかんなぁ。 - -C からのコンパイラも書かないといけないのか... +call 祉cャ... continuation 筝code +... Internal function + +continuation 筝compile号 +self 綽荀? + +荐茯 + +C 潟潟ゃ吾... Mon Dec 13 18:53:04 JST 1999 -compiler based で、内部で partial evaluation できる? - -func をdatabaseとして扱えないなら、それはできない。 - -しかし、状態遷移としては取り扱える。 +compiler based с partial evaluation с? + +func database宴с + +倶欠Щ宴 func.state func.code -みたいな形にしてpartial evaluationすれば良い - -でも止まるのか? - -textual でない、中間的なコード表現があった方が良い? <-> interpreter? - -Prolog ではなんでいけないの? --> Unification が重いから +帥綵≪partial evaluation域 + +с罩≪障? + +textual с筝潟若茵憗c鴻? <-> interpreter? + +Prolog сс? --> Unification Sat Nov 27 13:50:41 JST 1999 -func.state とか作るのだったら、 +func.state 篏c struct { struct { int i; @@ -90,11 +90,11 @@ i = i+1; }; } name; -みたいな形で、それ自体を構造化すれば? で、代入すると部分評価される。 -代入も可能。なるほど。 +帥綵≪с篏罕? с篁eャ荅箴< +篁eャ純祉 *name.code; -値はあるわけ? 値は &state でしょうね。 -self があれば、 +ゃ? ゃ &state с +self 違 struct { struct { int i; @@ -103,39 +103,39 @@ self->i = self->i+1; }; } name; -かな。self = state だよね。 - -union の拡張もあわせて議論すると... - -Partial evaluator をセマンティクスや実行系にいれておくことは可能か? - -byte code とか仮想マシンだったら可能。そうでない場合は? - -いずれにせよ、構造体のタグのunique性を修正しないとだめだな。 - -ヘッダファイルはどうするの? +self = state + +union ≦宍茘域... + +Partial evaluator 祉潟c鴻絎茵膤祉純? + +byte code 篁潟激潟c純с翫? + +罕篏帥違uniqueс篆罩c + +<ゃ? Mon Dec 13 18:53:18 JST 1999 -library との整合性は? - -exec sequence では、 +library 翫с? + +exec sequence с (--(struct func_state *)stack) = fp; call callee(&fp->arg); -という形でpointerだけ渡すの? それは変だよね。 - -値渡しにするとすれば、複数の値を渡せたほうが良い。 +綵≪pointer羝<? 紊 + +ゆ検違茲違ゃ羝<祉 func(void *stack) { static struct func_state { static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -の引数自体が、構造体であるべき。 +綣域篏罕篏с鴻 func( struct void *stack @@ -144,11 +144,11 @@ static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -で、構造体に register storage を許す。 +с罕篏 register storage 荐宴 func( static struct argument { @@ -160,11 +160,11 @@ static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -すると、caller の方も、構造体を引数とするのが自然。 +caller 鴻罕篏綣違吟 call caller( static struct argument { @@ -173,23 +173,23 @@ } arg = {a,b}; ) -みたいな。もちろん、この構造体はインタフェースと呼ばれる。 - -argument は、callee にあった方が良いけど、caller 側にあっても -良い。register なんかは、そう。 +帥<罕篏ゃ潟帥с若鴻若違 + +argument callee c鴻caller 眼c +register caller(interface caller_arg = {a,b,c}) -みたいなsyntax かな。 +帥syntax caller->interface = {a,b,c}; *caller->code; -を、 + caller(a,b,c); -と称する。 - -function には、interface と code と state があることになる。 - -state にアクセスする時のlockは? protected state? synchronized state かな? -もちろん、sequential implementationでは、そんなものはいらない。 +腱違 + +function interface code state + +state ≪祉鴻lock? protected state? synchronized state ? +<sequential implementationс function { interface: @@ -202,72 +202,72 @@ b = a; } -int にvoid value を定義する。実装は重くなるけど... - -serialized の semantics は? - -もう少しmicro-Cに近く! - -carrying state と static state。 +int void value 絎臂絎茖... + +serialized semantics ? + +絨micro-C菴! + +carrying state static state Mon Dec 13 19:42:41 JST 1999 -interface に register keyword を使うのは、あまりに -実装よりすぎる。でも、でないと状態にできない? -そんなことはないか。やっぱりcaller側のstatic 領域に -直接書き込む? - -だとCより遅そう。でも、引数に40個とかかかれたら... +interface register keyword 篏帥障 +絎茖сс倶с? +c宴caller眼static +贋・吾莨若? + +Cс綣違40... Wed Dec 15 14:09:49 JST 1999 -C と互換にする? +C 篋? goto function(arguments); goto *continuation(arguments); -みたいな感じで。 - -stackの管理は? どうせ、library との互換はとらないと -いけないんだから... - -local 変数がある場合は stack を動かす。でも、戻す奴がいない。 -closure 化するか? - -return した時の挙動が複雑になる。大域returnするわけだら。 - -arguments をstatic 領域にかきこむ方式だと互換性がとれない。 -stack 上の frame pointer 上にないとダメだから。 - -両立させるのは無理か? つまり、これだと、呼び出された方の -frame semantics は、C と互換になる。だから、stackの直後に -frame pointer があると思っている (そうか? ) frame pointer -stack pointer に沿って移動した直後に、そこからのoffset -で引数を操作することになる。 - -つまり、それはだめだったことじゃない? つまり、goto だと、 -frame pointer は、stack の直後とは限らないから。前の -frame pointer 相対に引数にアクセスしてくれれば別だけどね。 - -stack に引数を積むのは容認して、goto の場合は、向こう側で -stack を畳むってのは? ということは、普通の関数と定義の -方法を変えるってことか。ま、悪くはないか。 - -すると、goto のsemantics は、C と互換になる。それを受ける -方が異なることをする。それは、なんかおかしいな。それに、 -それだと関数呼び出しが軽くならない... - -ということは、やはり、C のcall は、call function で -実現して、その他の呼び出しは、すべて、goto 扱いに -する方が正しいだろう。 - -問題は、この言語の関数をcallされた時だな。dual entry にして、 -call の時と、goto の時を区別するか。 +帥с + +stack膊∞? library 篋 +... + +local 紊違翫 stack с祉絅眼 +closure ? + +return 茲紊уreturn + +arguments static 劫篋с +stack 筝 frame pointer 筝< + +筝∞∞? ゃ障若喝冴鴻 +frame semantics C 篋stack翫 +frame pointer c (? ) frame pointer +stack pointer 羃帥c腱糸翫offset +у違篏 + +ゃ障c? ゃ障goto +frame pointer stack 翫 +frame pointer 後障綣違≪祉鴻医ャ + +stack 綣違腥絎壕goto 翫眼 +stack 潟c? ∽違絎臂 +号紊c障 + +goto semantics C 篋 +鴻違 +∽医若喝冴荵純... + +C call call function +絎憗篁若喝冴鴻goto 宴 +鴻罩c + +馹荐茯∽違calldual entry +call goto 阪ャ func: stack processing func_goto: normal processing ... -みたいな感じ。でも、return はないから... - -このあたりも自分で記述できる言語であるべきだよね。その通り。 -つまり、C とのstub も自分で記述すると言うことか。 +帥сreturn ... + +ц菴違с荐茯с鴻 +ゃ障C stub ц菴違荐 protocol function { interface c { @@ -287,120 +287,120 @@ }; } -みたいな感じでさ。さっすが、アセンブラ。いまいちreturnが汚いけど。 -まぁ、return はそのままreturnでもいいけどさ。 - -あ、これは良いかも知れない。code が複数かけるから。 - -state 以外は、consistent state であることを保証しない。ってのは? -local 変数は使っても良いけど、call/goto の前後で、値を保証しないか... - -うーん、だんだん炸裂してるなぁ。 - -だから、レジスタに対するマッピングの記述と、そうでない部分の -記述は分離するべきでしょうね。 - - -全部一辺に実装するわけにはいかないからぁ... +帥сc≪祉潟障return羆 +障return 障returnс + +ャcode 茲違 + +state 篁ュconsistent state с篆荐若c? +local 紊違篏帥ccall/goto 緇сゃ篆荐若... + +若梧 + +吾鴻帥絲障潟違荐菴違с +荐菴違≪鴻с + + +筝莨冴絎茖... Thu Dec 16 13:44:21 JST 1999 -lock は状態遷移レベルで実現するのだから、self などを -使ってlockする必要はないはず。 - -全体の直列化は、状態遷移レベルで、 +lock 倶欠Щу憗self +篏帥clock綽荀 + +篏翫倶欠Щс lock(storage) -> transition -みたいな形で記述すれば良い。この当たりを、どのように記述するかは -もう少し先送りしよう。 - - -引数はレジスタ渡しにしよう。長い引数は、呼び出し側の領域への -ポインタとする。実装を規定しても良い。そうすれば、varargs -みたいなものはなくなる。だいたい、なんで、そんなものがいるんだろう? -配列を渡せばいいじゃん。 - -なので、引数は一つ(or 二つ)に限るという方法もある。 - -とすると、やはり、前もって静的領域や動的領域を確保することは -できない。 - -この言語では動的領域は自分で確保するわけだから、その点は問題ない。 +帥綵≪ц菴違域綵荐菴違 +絨 + + +綣違吾鴻炊検激綣違若喝冴眼吾 +ゃ潟帥絎茖荀鎘違varargs +帥с? +羝<違 + +с綣違筝(or 篋)号 + +c腆坂 +с + +荐茯сх∈篆鴻馹 Thu Dec 16 20:24:55 JST 1999 -とすると関数呼び出しは、 +∽医若喝冴 # register save # set 1st argument in register %eax # set 2nd argument in register %ecx # set extra arguments in save area # set extra argument pointer in %edx jmp function -という形式になるわけね。second を処理するのはめんどくさいから一つ -にしよう。 - -えーと、frame pointer はないけど、コンパイルの手順からすると -あった方が良い。しかし、frame pointer そのものをstatic -にとるのはまずい。だから、frame pointer がfirst argument -ということにする方が正しい。とすると引数は、さらに、その -後と言うわけか。 +綵√second 筝 + + +若frame pointer 潟潟ゃ +c鴻frame pointer static +障frame pointer first argument +鴻罩c綣違 +緇荐 f(fp,argument) -fp を渡すのにさらにargument をレジスタで渡すのはおかしい。おかしいけど、 -ま、良いか。 - -return しないなら、return type の定義をとるのは変だな。 - -f(fp,arg1,arg2,arg3) とすると、それぞれが決まったレジスタに入って、 -多い分は配列にあると思われる。ふむふむ... +fp 羝<argument 吾鴻帥ф検 +障 + +return return type 絎臂紊 + +f(fp,arg1,arg2,arg3) 羆冴障c吾鴻帥ャc +紊泣泣... fp->xx -でアクセスすれば、そのまま局所変数になる。全部、配列で -送っても良い。 +с≪祉鴻違障上紊違 +c .set label,value -で as は値をセットするようですね。 - -関数コールの後は戻って来ないから後始末の心配はしなくてよい。 -frame pointer を使ったら自分で面倒を見ること。 - -だと + as ゃ祉с + +∽違潟若緇祉cャ緇紮綽 +frame pointer 篏帥cч√荀 + + a = atoi(s); -みたいなことはできない... - -普通のCの定義と交じると間違いやすい。 - -とすると、struct と同様に、 +帥с... + +C絎臂篋ゃ + +struct 罕 protocol code interface state -を用意するわけね。時間あるのかぁ? - -とりあえず、register 渡しのfunction 定義とgoto文を実装する。 +? + +register 羝<function 絎臂goto絎茖 code name(register "%ebp" void *arg) { goto name(arg); } -ぐらいかな? で、first argument が必ずregisterにのるようにしないと -いけない。register storage class を入れて、 +? сfirst argument 綽register +register storage class ャ register "%ebp" void *arg -とかするわけね。 - -ってことは、まず、レジスタを実装しないといけないわけね。 - -で、stack を使った演算は、一応、そのままにする? それでも動くはず。 -式の途中でgotoは使えないんだから、それでいいはず。 - -で、それから、これを拡張していく。 + + +c障吾鴻帥絎茖 + +сstack 篏帥c羲膊筝綽障障? с +綣筝goto篏帥с + +с≦宍 interface c { register "%ebp" void *arg; } code name(interface c) { - goto name(c.arg); // c. は省略可能 + goto name(c.arg); // c. ュ } -とかね。さらに、 + protocol name { interface c { @@ -414,28 +414,28 @@ } } -などとするわけか。なんと、これが C と共存するわけね。うーん。 + C 怨若 Fri Dec 31 11:44:03 JST 1999 -code でなくて、別な名前のほうが良くない? segment? action? - -レジスタ名が入るのは、やっぱりいや。optionalには許す。 - -interface は構造体のようなものだから... 構造体でいいんじゃない? -構造体の場合は... malloc する? う、うーん。malloc するとして、 -いつfree するの? - -再入するときには、壊れてていいんじゃない? multi-thread でなければね。 -multi thread では、状態は、レジスタ経由または、thread local に持つ -必要がある。static は、だから thread local に持たなくてはならない。 -大域変数に割り振っちゃだめ。でも、いまは、やめて - -interface は、とりあえず、二つまでの値渡しにしよう。 - self と arg -ですね。 - -もう少し拡張しやすいコンパイラがいいなぁ。 +code сャ祉? segment? action? + +吾鴻水ャc宴optional荐宴 + +interface 罕篏... 罕篏с? +罕篏翫... malloc ? 若malloc +free ? + +ャ紕? multi-thread с違 +multi thread с倶吾鴻睡宴障thread local +綽荀static thread local +紊у紊違蚊c<с障 + +interface 篋ゃ障сゆ検 + self arg +с + +絨≦宍潟潟ゃ code name (c,a) struct state *c; struct arg *a; @@ -443,62 +443,62 @@ goto name(arg); } -local 変数は? この互換性の問題かぁ。 - -KL/1 を意識して、interface は heap に置くことにしても良い。 -GC は言語に入れておくべきだが、interfaceは machine independent -であるべき。だとすれば use/forget みたいものはいるだろう。 -でも今のところは考える必要はない。 - -えーと、 +local 紊違? 篋с馹 + +KL/1 顑interface heap 臀 +GC 荐茯ャ鴻interface machine independent +с鴻 use/forget 帥 +с篁綽荀 + +若 code name (c,a) struct state *c; struct arg *a; { int i; goto name(arg); } -の時の一時変数iはどうするの? 基本的にはレジスタ割り当てだけど... -使用させない? んー、大胆な御意見。まぁ、やっぱりheapに割り当てちゃう -のが簡単か。でも、どうせ抜ける時にはいらなくなるわけだから... - -ほんらい、この変数は、次のcallでは必要無くなるのが普通。 - -とにかく、レジスタ変数は必要なんでしょう? - -だから、GC と合わせて言語を設計すべきだよね。API を規定して、 -異なるGCを選択できるようにする。 +筝紊i? 堺吾鴻水蚊綵... +篏睡? 若紊ц緇≧頳障c宴heap蚊綵< +膂≦с... + +祉紊違罨<callс綽荀< + +吾鴻水違綽荀с? + +GC 荐茯荐荐鴻API 荀鎘 +違GC御с Sat Jan 1 22:40:22 JST 2000 -とーにかく、 storage class register を実装しよう。 +若 storage class register 絎茖 stmode=REGISTER -で、local storage とおなじ扱いとする - static register? は、ない。 - -symbol table に storage class をたせば? dsp==EXTRN で判定しているから、 -local 変数が36以上あるとおかしくなるぞ? - -sc は GVAR/LVAR だけど、register は LVAR の特殊な奴だから、 -sc に入れるほうが正しいか... +сlocal storage 宴 + static register? + +symbol table storage class ? dsp==EXTRN уゅ +local 紊違36篁ヤ? + +sc GVAR/LVAR register LVAR 号絅眼 +sc ャ祉罩c... Sun Jan 2 01:47:17 JST 2000 -register 変数はできました。けど、register を二つ使うと、 -一杯になってしまうので、REGISTER6 でコンパイルしないと -結構ひどい。が、register 変数を%esi,%edi に割り当てれば -いいか。 +register 紊違с障register 篋や戎 +筝c障сREGISTER6 с潟潟ゃ +腟罕蚊register 紊違%esi,%edi 蚊綵 + Sun Jan 2 04:43:04 JST 2000 -で、 +с code name (c,a) struct state *c; struct arg *a; { goto name(c); } -の一時変数無しは実装できます。引数は二つまでね。 +筝紊亥<絎茖с障綣違篋ゃ障с .file "tmp.c" .version "01.01" @@ -519,27 +519,27 @@ .size code,_5-code .ident "Micro-C compiled" -う、すごい。 - -goto 文がめんどくさい。stack をたたんで、jmp すれば -よいだけだが.. + + +goto stack сjmp +.. Sun Jan 2 11:17:50 JST 2000 -普通のcallをcontinuation baseにすることができる? +callcontinuation baseс? Sun Jan 2 20:28:45 JST 2000 -goto 文だけど、やはり、一度、expr で生成してから、top level -で jump code を生成しよう。 +goto 筝綺expr хtop level + jump code Tue Jan 4 03:32:55 JST 2000 -code をtypeにしないと、 +code type code *p; -とか書けないね。 +吾 int *p(); -と同じだけどさ。 + main(ac,av) @@ -561,21 +561,21 @@ Tue Jan 4 04:56:56 JST 2000 -うーん、なんかレジスタにつむ順序が違う -これは、adecl がreverseにつむから。 - -code のreturn - -やはりcodeはtypeにしないとだめ。 +若吾鴻帥ゃ綺 +adecl reverseゃ + +code return + +codetype main() { goto code1(); } -とかだと、main に戻って来れない。もちろん、code1() 以降で、 -return するわけにはいかない。(main の disp をcode1 は知り得ない) -goto label をcode1の引数に送れば? +main 祉cャ<code1() 篁ラс +return (main disp code1 ャ緇) +goto label code1綣違? main() { @@ -583,20 +583,20 @@ ret: } -これだと、ret がforward labelかどうか分からないけど? - -code1 中で使う中間変数を stack 上にとるのは悪くない。しかし、それを -%ebp 経由でアクセスするということは、main の中間変数を壊すということ。 -それを防ぐには、main 中のgoto codeで、%ebp を修正してやれば良い。 -(今は戻って来ないので問題ない) - -code1 のgoto では、戻って来ないから、その必要はない。しかし、 -label をcode1 中で渡されると、ちょっと気まずい。 - -とすると、それは禁止して、main() 中でstackをたたんでからgotoするか? -そうすると、無限後退して、結局、帰れないことになる... うーん。 - -main() 中のlocal code を許せば、それは解決するが.. +ret forward label? + +code1 筝т戎筝紊違 stack 筝 +%ebp 腟宴с≪祉鴻main 筝紊違紕 +蚊main 筝goto codeс%ebp 篆罩c域 +(篁祉cャу馹) + +code1 goto с祉cャ綽荀 +label code1 筝ф検<c羂障 + +胼罩≪main() 筝stackсgoto? +♂緇腟絮絽違... 若 + +main() 筝local code 荐宴違茹f浦.. main() { @@ -606,10 +606,10 @@ } } -みたいな感じ。でも、そうするとscope rule を変える必要があるので厳しい。 -ま、悪くはないけどね。 - -continuation を明示する方法もある。 +帥сscope rule 紊綽荀уウ +障 + +continuation 腓冴号 main() { @@ -621,17 +621,17 @@ goto *ret; } -かな? call/cc ? - -label へのgotoを許すのもいいけど、 -でも、label を許すと、すごくspaghettiにならない? +? call/cc ? + +label 吾goto荐宴 +сlabel 荐宴spaghetti? Tue Jan 4 11:47:24 JST 2000 -continuation じゃなくて、return keyword を使おう。 -(実際、continuation と少し違うし) -type が少し変になるけど、まあ良い。 +continuation return keyword 篏帥 +(絎continuation 絨) +type 絨紊障 int main() @@ -644,33 +644,33 @@ goto *ret(3); } -だな。prototype も付けないといけないか。 +prototype 篁 Tue Jan 4 12:21:44 JST 2000 -これだとmethodがすべてstatic になってしまう。dynamic なmethod -呼び出しにするには? dispatcher を自分で作ることになる。かなり -めんどくさいが... +method鴻static c障dynamic method +若喝冴? dispatcher т +... code method(obj,arg) { } -か、あるいは、inline にするか... #define のかわりに inline ねぇ。 -これはあとで考えて良い。 +inline ... #define inline +ц Tue Jan 4 14:22:19 JST 2000 -main の変数を書き潰すのと、goto (*reg)(123) での値は、 -register 渡しで、current register にのらないので、 -結局、return label は専用に作る必要がある。 +main 紊違吾羹違goto (*reg)(123) сゃ +register 羝<сcurrent register с +腟絮return label 絨篏綽荀 Tue Jan 4 18:14:07 JST 2000 -stack を継ぎ足して、呼び出す方式を取れば、call by value -のregister 渡しを制限する必要は無くなる。 - -複数の値を返すことも容易だ。 +stack 膓莇潟若喝冴劫違call by value +register 羝<狗綽荀< + +茲違ゃ菴絎号 .file "tmp.c" .version "01.01" @@ -691,7 +691,7 @@ .size code,_5-code .ident "Micro-C compiled" -おお?! +?! %esp new %esp = old %esp - 12 -4 %ebp-4 = g %esi = a @@ -702,16 +702,16 @@ %ebp+12 = e %ebp+16 = f -interface は付けよう! というか、 +interface 篁! goto name(struct {xxxx}) -みたいな感じで良いわけね。どれをregisterにいれるかと言う問題はあるが。 - -で、どうやってcallすればいいわけ? emit_pushするかわりにpush -する? - -うう、これでは、だめか。code argument の数が変わると、 -ebp をいちいち動かすことになる。そこにはold sp があるから -そいつもコピーする必要がある。 +帥цregister荐馹 + +сccall違? emit_pushpush +? + +сcode argument 違紊 +ebp <≦old sp +ゃ潟若綽荀 %esp new %esp = old %esp - 20 %ebp-20 = g @@ -723,7 +723,7 @@ %ebp-4 = f %ebp = old %esp 0 -そうか、function からcallする時には、local 変数を書き潰して良い。 +function calllocal 紊違吾羹違 # goto name(a,b,d,e,f); @@ -743,135 +743,135 @@ %ebp = %esp 0 %eip 4 <- arg_offset -となる。ということは、pushl %ebp は、間違い。 - -だけど、%ebp をそのまま使うのは良くない。disp_offset がかかっているから。 -だから、もう一度 pushl %ebp したほうがよい。しかし、push する先は、 -上の、(*)。 +pushl %ebp + +%ebp 障鞘戎disp_offset c +筝綺 pushl %ebp 祉push +筝(*) leave movl %ebp,%esp popl %ebp -じゃなかったか? +c? Thu Jan 6 13:00:33 JST 2000 -できたね。これでとりあえず動くはず。速度は問題だが... -あとは、 +сс綺馹... + ANSI-C prototype ANSI-C prototype check Interface Definition GC support Direct handling of Frame -だね。簡単に出来そう? たぶん... +膂≦堺ャ? 吟... Fri Jan 7 09:42:53 JST 2000 -goto 文が動いてなかった。あと peep hole optimization version も -作るか? - -continuation として label を送れるようにするべきか? -そうすると便利なんだけど、ちょっと、汚いプログラムが -出来るようになる。あと、送り側の環境(frame)を維持する -必要がある。ま、できなくはないか... - -そうすると、label が値を持つようになる。 +goto c peep hole optimization version +篏? + +continuation label 鴻? +箴水<c羆違 +堺ャ眼医(frame)膓 +綽荀障с... + +label ゃゃ a = label:; -とか。うーん。label:(a,b,c) {}; みたいな形で、parallel 代入を許すと言う -手もあるね。 - -こちらの方がCとの相性は良いが... main() { label:(){ ... } } -みたいなnestを許すかどうかと言う問題がある。 -変数の参照を許さなければ、特に問題はない。 - -a = label: は、二重の意味があるなぁ。 - -言語の名前。DinnerBell II とか? join も入れる? +若label:(a,b,c) {}; 帥綵≪сparallel 篁eャ荐宴荐 + + +<鴻C御с... main() { label:(){ ... } } +帥nest荐宴荐馹 +紊違с荐宴違鴻馹 + +a = label: 篋潟 + +荐茯DinnerBell II ? join ャ? code entry_a().entry_b() {} -ですか? parallel call も? +с? parallel call ? Fri Jan 7 19:53:53 JST 2000 -いまのままだと return が環境を持ってないから、大域脱出できない。 -まぁ、環境を入れてもいいんだけど、どこに置くかと言う問題が -あるね。 - -そうじゃなくて、return 側で判断するか? +障障障 return 医c紊у怨冴с +障医ャ臀荐馹 + + +return 眼уゆ? return(ID) -みたいな形でIDで判断する。そうすれば、return 側でID -を見て判断できる。けど... - -まぁ、はやり、環境を持って歩く方がいいかなぁ。でも、 -引き渡しているから、二つ引き渡して、片方を使われたときに、 -反対側が消えてしまうのはいたいよね。今のままならば、 -そういうことは起こらない。 - -continuation 特有の問題を避けるなら、このままでもいいんだが... -continuation や環境は、このシステムでは自分で作ることが -できるからね。 - -そうなんだけど.... retlabel や retcont は実はオブジェクト -全体に一つあれば良い。 - -引数を渡すときに、そこに環境へのポインタをいれてやれば良いので、 -解決は割と簡単だが、そうすると、例の構造体を引数で渡すと言う -問題を解決する必要がある。 - -でも、今の実装ならば、まったく同じ変数の構成ならばコピーは -実際には起こらないわけだから問題ないはず。特に、それを保証するために、 -interface を実装する必要がある。 +帥綵≪IDуゆ違return 眼ID +荀ゆс... + +障医c罩鴻с +綣羝<篋ゅ羝<鴻篏帥 +絲上眼羔障篁障障違 +莎激 + +continuation 号馹帥障障с... +continuation 医激鴻ст +с + +.... retlabel retcont 絎吾с +篏筝ゃ域 + +綣違羝<医吾ゃ潟帥域с +茹f浦蚊膂≦箴罕篏綣違ф検荐 +馹茹f浦綽荀 + +с篁絎茖違障c紊違罕違潟若 +絎莎激馹鴻篆荐若 +interface 絎茖綽荀 return -> (void *)old bp return address -bp を直接操作できるようにするといいんだけど.... +bp 贋・篏с.... Sat Jan 8 08:49:59 JST 2000 -今は、code 内ではreturnできないわけだけど。実は、return って、 +篁code сreturnс絎return c code return0(i) int i; { return(i); } -か? 今は禁止してないから書けちゃうよね。どういうcodeが出るんだろう? - -doreturn() では retpending をセットしているだけだから、control=1 -のまま。で、code の終りにくるのでエラーになる。checkret は、 -statement の引数で判断するようにしたほうが合理的だろう。 - -大域脱出は結構根が深いよね。途中をスキップされてうれしいか? -destructor と同じで、途中のcodeは全部呼びたいのが普通だろう。 - -bp が同じになるまで return すれば良いわけだよね。 -return と同じで、明示的に環境を引き渡すようにするか。 -type は void * で良い? - -return する時にstackの上限を越えているかどうかを自分でチェックする -必要があるね。誰にreturnするかをcodeで明示すれば良いわけだけど。 +? 篁胼罩≪吾<code冴? + +doreturn() с retpending 祉control=1 +障障сcode 腟с若checkret +statement 綣違уゆ祉 + +紊у怨冴腟罕鴻羞宴筝鴻? +destructor с筝code若潟 + +bp 障 return 域 +return с腓榊医綣羝< +type void * ц? + +return stack筝莇сс +綽荀茯違returncodeф腓冴域 code return0(i) int i; { return(i); } -を許して、そこで、frame pointer を大域あるいは渡した引数と -比較して処理する? +荐宴сframe pointer 紊у羝<綣違 +罸莠? code return0(i,env) int i; env *env; { if (env==self) return(i); } -あれ? これはおかしいよね。 +? code return0(i,env) int i; env *env; { if (env!=self) { env->return(); return(i); } } -も、なんか変だよなぁ。呼び出しと逆順に帰りたいわけだが... -実際、逆順には帰っているわけだよね。 - -return の中でこそこそ比較するという技もあるけど。 - -問題は、destructor に渡す情報だよね。もちろん、self で良いわけだが、 -このあたりは、言語外の問題で、それを明示的にしたいから、この言語を -作っているわけなのだから、これを内部で処理するのはおかしい。 +紊若喝冴絽違... +絎絽違c + +return 筝с罸莠 + +馹destructor 羝<宴<self ц +荐茯紊馹с腓榊荐茯 +篏cу code return0(i) int i; { return(i); } -これだと、return の型が合わないと言う問題が生じるな。簡単には -チェックできない。 +return 荐馹膂≦ +сс int main() { code a() { @@ -880,7 +880,7 @@ return(i); } } -にすれば、check はできるようになる。でも、これだと、 +違check сс int main() { a: { @@ -889,149 +889,149 @@ return(i); } } -と差がない。module 化を言語外でやるというのが主旨なのだから、これでは -まずい。これは高級アセンブラなのだから。 - -あそうか、return と、大域脱出時のabortとは、状況が違う。だから、 -別なcode を呼び出さないとだめ。あるいは、値で区別するか。これは、 -logic programming のfail/success と似ている。 +綏module 荐茯紊с筝紙с +障蕭膣≪祉潟 + +return 紊у怨堺abort倶 +ャcode 若喝冴ゃу阪ャ +logic programming fail/success 篌若 main() { } abort { ... } -でもいいけど? +с? main() { code abort { ... }; code return { ... }} -かな? - -本来、subroutine call自体が、かなりの省略形なわけだから、これは -仕方がない。今のままで通常のsubroutine callをシミュレートできるのか? +? + +ャsubroutine call篏ュ就 +篁鴻篁障障ч絽吾subroutine call激ャ若с? code (struct arg {...},void *sp) { struct env; push(sp,arg); push(env,arg); } -できるけど、ちょっと重い。やはり、frame pointer を直接操作しないと -だめ。 - -goto 文のほうに、env を一緒に送るものを作ったほうがいいのかも。 +с<cframe pointer 贋・篏 + + +goto 祉env 筝膩篏c祉 goto (*ret)(),environment; -かな。type は? (void *)? +type ? (void *)? goto ret(),environment; -にはならないの? そうすれば、自分でthreadを制御できる。environment -の正当性を評価しなくて良いの? まぁ、ねぇ。 - -これは実装は容易だが... goto といちいち書くのが本当にいいのか? -env に対するoperationがあった方がいいなぁ。push とか? +? 違thread九勝сenvironment +罩eс荅箴<? 障 + +絎茖絎号... goto <≧吾綵? +env 絲障operationc鴻push ? code return0(i) int i; { return(i); } -を認めれば、return 擬変数はいらなくなる。 - -でも、実は、return は、caller の引数の数と一致してないといけない -わけだから、 code return0(i) int i; { return(i); } はだめ。env -と一致してないといけない。ということは分離するとまずいんじゃない? -あれ? そんなはずないな。 +茯違return 紊違 + +с絎return caller 綣違違筝眼 + code return0(i) int i; { return(i); } env +筝眼≪障? +? Sun Jan 9 01:15:56 JST 2000 -やはり、分離してはまずい。もともと、 +≪障 goto func(arg); -自体が、 +篏 goto func(arg) with current.env -みたいなものだ。つまり、これは、DinnerBell の、 +帥ゃ障DinnerBell self message: arg -と同じ。self->func(arg); でも良い。が、function callと区別が付かないのは -良くない。 - -そうすると、type code はsize int でなくなる。 +self->func(arg); сfunction call阪ャ篁 + + +type code size int с code *p = func; -ではいけなくて、 +с code p = {func,env}; -でないといけない。実際、 +с絎 goto func(arg) -では、current environment を pushl %ebp でstack = current env -に積んでいるわけだから。 - -いずれにせよ、 +сcurrent environment pushl %ebp stack = current env +腥с + + struct p = q; -は実装する必要がある。localな、 +絎茖綽荀local code p = {func,env}; -も動くはずだが... +... code (*p)(); goto (*p)(arg); -はだから少しおかしい。これは、goto がenv を補っていると考えるべき。 - -このようにすると、常に、 +絨goto env 茖c鴻 + +絽吾 func,env -の組をcodeとみなすことになる。これは、object と呼ぶべきだ。 -ただ、既存のobjectとは別だよな。actor の方が良い? - -うーん、これでjoinを入れれば、完璧なDinnerBellだな。並列送信はないけど。 +腟code帥object 若吟鴻 +√objectャactor 鴻? + +若joinャ違絎сDinnerBell筝篆< Sun Jan 9 01:40:05 JST 2000 -local 変数の初期化はallocation の後に遅らせる必要がある。 -nptr に入れられるはずだよね? nptr に初期化フラグを足すか? - -文途中で出現するlocal変数の初期化。ちゃんと動いているの? - -構造体のcopyは、lcheck を修正すべきでない。 +local 紊違allocation 緇綽荀 +nptr ャ? nptr 違莇潟? + +筝у榊憗local紊違<? + +罕篏copylcheck 篆罩c鴻с Sun Jan 9 08:49:43 JST 2000 -うーん、なんか修正が多いなぁ。あと、関数呼び出し、goto 文の -構造体への対応か。 +若篆罩c紊∽医若喝冴goto +罕篏吾絲上 goto (*code)(); -が、self env を使うのか、code の先の値を使うのかを区別する -必要がある。もし*を使わないとするとlabel(FNAME)との区別が -つかないぞ。あ、でも、環境を持ち歩くことにしたから、label -へもjumpしようと思えばできるね。 - -並列送信はなくても、この構成ならばstatement単位の並列性を検出するのは -容易だろう。 - -やればできるけど、この修正の量だと1日じゃ終らないかなぁ。 -浮動小数点も入れるのでしょう? +self env 篏帥code ゃ篏帥阪ャ +綽荀*篏帥label(FNAME)阪ャ +ゃс医≧label +吾jump違с + +筝篆<罕statement篏筝с罎冴 +絎号 + +違с篆罩c1ャ腟 +羌絨亥鴻ャс? Mon Jan 10 09:00:12 JST 2000 -引数に構造体を許すには、必ずANSI-Cにする必要がある。難しくは -ないが... - -goto 文には label, code, continuation の3つが来る。 +綣違罕篏荐宴綽ANSI-C綽荀c +... + +goto label, code, continuation 3ゃャ continuation = code + env | label +env -なのだが、code/label では、env の内容が異なる。できれば面白いが、 -その価値はあるのか? - -しかし、code , env を分離するとあまりに危険すぎる。どうせgoto -が危険なんだからいいか? その方が簡単。簡単なら、そっちの方法を -とるべきじゃない? うーん。 - -return の関数依存性はなくした方が良い。 -一つにするのは、pop の問題があるので良くないが... - -そうか、ret をenvを指定して戻るようにしたから、leave する必要は -なくなった。そして、push %ebp に相当する部分は、lea -disp(%ebp),%sp -で消去されている。ということは、jump のfunction依存部分はいらない -ということだね。 - -でも、汚いなぁ。read only属性をhardware supportできればなあ。 - -sched_yields() 相当を書けるかな? lock は? - -一応、できたけど、やっぱり汚い。 +code/label сenv 絎鴻違с育∝純 +箴≦ゃ? + +code , env ≪障演冴goto +演冴? 鴻膂≦膂≦c<号 +鴻? 若 + +return ∽遺絖с鴻 +筝ゃpop 馹ц... + +ret env絎祉leave 綽荀 +cpush %ebp 後lea -disp(%ebp),%sp +фサjump function箴絖 + + +с羆read only絮сhardware supportс違 + +sched_yields() 後吾? lock ? + +筝綽сc宴羆 Wed Jan 12 16:12:27 JST 2000 -あは。ANSI prototype はめんどい。 +ANSI prototype bexpr() -で、関数での引数の順序と、そのあとの宣言の順序が変わることがある。 -そうすると、うしろの方が優先されてしまう。これは、こまる。 - -そうか、code_arg_offset のような方法だと、ANSI style では、 -困ってしまう。 +с∽違с綣違綺絎h綺紊 +鴻障障 + +code_arg_offset 号ANSI style с +違c障 Thu Jan 13 04:46:12 JST 2000 @@ -1057,34 +1057,34 @@ Thu Jan 13 13:38:24 JST 2000 -だいたいできたけど、test/tmp7.c のprintf のtype mismatch は -なんなんだろう? ANSI の副作用だろうなぁ。 - -これだと、プロセスの切替えのときには、結構な量のデータを -コピーすることになる。それでもいいんだけど... - -それごと、どっかにとって置く。continuationへの参照みたいなもの -ができないかな。 - -コピーができれば、environment/return の組は動くわけだから、 -それへの参照と切替えがあっても良いよね。 +сtest/tmp7.c printf type mismatch +? ANSI 篏 + +祉鴻帥腟罕若帥 +潟若с... + +cc臀continuation吾с帥 +с + +潟若с違environment/return 腟 +吾с帥c Fri Jan 14 12:03:35 JST 2000 -Libretto のkeyboardが壊れた... control key が効かない... - -printf の参照の問題は解決しました。list2 がlocalなheap -に割り当てているのがいけなかったね。 - -return の処理は、goto 文で処理するより、environment に -returnto する方が良くはないか? - -environment は実は送り先でそれなりの準備が必要。 -new-environment() みたいなlibrary があれば、thread にできる。 - -join は? - -funcall を用意すると良いね。 +Libretto keyboard紕... control key 鴻... + +printf с馹茹f浦障list2 localheap +蚊綵c + +return goto уenvironment +returnto 鴻? + +environment 絎с羣綽荀 +new-environment() 帥library 違thread с + +join ? + +funcall Mon Jan 17 15:23:34 JST 2000 @@ -1092,8 +1092,8 @@ return bb; } -みたいなのは? 関数の型か代入の型を見て、crn にpointerを渡して、 -あとでcopyしてから stack を畳む。 +帥? ∽違篁eャ荀crn pointer羝< +copy stack 潟 # bb=f1(aaa); movl $bb,%eax @@ -1106,21 +1106,21 @@ addl $400,%esp # return a1; -あ、でも、それだと、local変数を返したときに困るね。leave; ret; -してはいけなくて... - -あ、やっぱり、こういう場合はコピー先をmain2に引き渡しているみたいね。 +сlocal紊違菴違leave; ret; +... + +c宴翫潟弱main2綣羝<帥 void f1(struct aa *ret) { *ret = bb ; return; } -と同じか。これは簡単。 +膂≦ f1().a[55] -みたいな場合は、局所変数に強制的に取ってしまうみたいね。それはそうだ... -が、うちの実装だとちょっと厳しいか。 +帥翫絮紊違綣桁句c障帥... +<絎茖<cウ leal $-sizeof(struct),%esp pushl %esp -なんだけど、関数呼び出しの途中ではできないから.... +∽医若喝冴筝сс.... # main(ac,av) # int ac; @@ -1143,28 +1143,28 @@ # j = 3; subl $20,%esp -このsublを後から指定してやればOk。 - -でも、それだと jump の時にずれない? ずれるか? ずれるね。うーん。 -実行時にチェックしてやるのも変だし。 - -まぁ、それほど必要な機能ではないんだけど。 - -これもcontinuationを渡してやると言う手法が使えないことはないんだが... - -関数呼び出しの最初にやってやればいいか。それでできるかな? +subl緇絎Ok + +с jump ? ? 若 +絎茵с紊 + +障祉綽荀罘純с + +continuation羝<荐羈篏帥... + +∽医若喝冴c違сс? Sun Feb 20 23:59:16 JST 2000 -MIPS のcall frame +MIPS call frame $sp = $fp local variables saved register (including $31 = return address) -mask は使用したレジスタのbit pattern - -4 は何? +mask 篏睡吾鴻帥bit pattern + -4 篏? 18 .mask 0xc0000000,-4 19 .fmask 0x00000000,0 @@ -1190,89 +1190,89 @@ 38 0044 3000BD27 j $31 39 .end main -これと同じようにするならば、registerの使用数を最初に調べる必要が -あるのだけど、one path compiler である micro-C では、それは -できない。したがって、enter は後ろでする方が良い。 +違register篏睡違茯帥鴻綽荀 +one path compiler с micro-C с +сcenter 緇с鴻 Mon Jan 20 18:25:27 JST 2003 -3年間さわってないのかよ。何やってんだ? - -goto 文のバグをとらないといけない。 - -まず、関数引数の構造体の展開。これは、どうってことないはず。 +3綛顔c篏c? + +goto 違 + +障∽医違罕篏絮c goto (*code)(i+1,j,...) -まず、いじらなくてすむ変数を摘出する。 +障紊違冴 foreach arg compare -単純演算 ( op+const , pointer , const assign ) などは、ここで検出する。 -大半は、そのようになるはず。 -レジスタに乗せる分があるから... それには触らないとして... - -複雑なものは、前もって計算しておく。(get_register する) -スタック上かレジスタ上に作る。 - -残りは並列代入となる。再帰的に計算する。 - -えーと、大きな順にやるんだっけ? 小さな順にやるんだっけ? +膣羲膊 ( op+const , pointer , const assign ) ф冴 +紊у +吾鴻帥箙... 茹... + +茲c荐膊(get_register ) +鴻帥筝吾鴻推篏 + +罧筝篁eャ絽亥荐膊 + +若紊сc? 絨c? code f( int a, int b, int c ) { goto g(b,c,a); } -みたいなやつだよね。 - - 移動するものを一つ検出する。 - そのために移動が必要なものを移動しておく(再帰) - 代入する - -こんなんでいいのか? ループしない? するよね。ループしたら -get_register する。 - -前の例だと、 - - g(b,c,a) のbに着目する。 - bに代入するコードを出すと、a が壊れる。 - a が必要かどうかを調べる。それは、引数のリストを見ればわかる。 - その前に、a を移動する。a の移動先を見て、 - 空いていれば、移動してOk。しかし、c - なので、 c を見る。と b になるので、ループするのがわかるので、 - b を get_register する。 - で、c が移動できる。で、aを移動して、とっておいたbを代入。 +帥ゃ + + 腱糸筝ゆ冴 + 腱糸綽荀腱糸(絽) + 篁eャ + +с? 若? 若 +get_register + +箴 + + g(b,c,a) b + b篁eャ潟若冴a 紕 + a 綽荀茯帥鴻綣違鴻荀違 + a 腱糸a 腱糸荀 + 腥冴違腱糸Okc + с c 荀 b с若с + b get_register + сc 腱糸ссa腱糸cb篁eャ Tue Jan 21 22:45:09 JST 2003 -とりあえず、jump は複雑すぎる。もっと簡単にすることを考える。 -parser 側である程度処理できない? +jump 茲c膂≦ +parser 眼с腮綺с? goto f(a+3,b(),c); -などを、 + a = a+3; b = b(); goto f(a,b,c); -程度に簡略化する。この時、f(a,b,c) は(できるだけ)、元の -関数の引数リストに近付ける。のは無理なので、単純変数 -まで落す。 - -あまり関係ないか。一時変数はどうせいるわけだし。ってこと -みたいね。 - -だとすると、元のコードと、そう変わらんね。前のも、そんなに -悪くないってことか。 +腮綺膂∞ュf(a,b,c) (с) +∽違綣違鴻菴篁∞с膣紊 +障ц純 + +障≫筝紊違c +帥 + +潟若紊 +c Wed Jan 22 14:33:12 JST 2003 -やっぱり、途中で局所変数を増やしたいよね。 +c宴筝у紊違紜 Fri Jan 31 20:30:36 JST 2003 -なんか #ifdef / #if がないとだめだな。実装する? -しました。 + #ifdef / #if 絎茖? +障 Tue Feb 4 01:04:12 JST 2003 @@ -1284,89 +1284,89 @@ addl %ecx,%edx movl (%edx),%edx pushl %edx - xchg %edx,%eax .... edx に$10が入る (なんでxchg?) + xchg %edx,%eax .... edx $10ャ (xchg?) call getc addl $4,%esp - movl %eax,-20(%ebp) c に代入 + movl %eax,-20(%ebp) c 篁e movl $chptr,%ecx pushl %ecx popl %ebx - movl (%ebx),%ecx ecx にchptrの中身 + movl (%ebx),%ecx ecx chptr筝荳 addl $1,(%ebx) movb %al,(%ecx) subl %edx,%eax eax-edx ($10) je _1119 -が壊れる理由なんだけど... - -edx,ecx が破壊されちゃうみたいね。 +紕宴... + +edx,ecx 翫<帥 Tue Feb 4 12:17:07 JST 2003 -ようやっと直したよ... - -use_pointer って、なにもしなくていいんだよね? eax,ebx を避ける -ってことらしいけど。 - -inline/引数付き #define 欲しくない? 置き換えは、local name stack に積んじゃう。 -展開は function で行う。 - -getch を工夫する必要はあるが。置き換えスタックが必要。 +c眼... + +use_pointer c? eax,ebx 帥 +c + +inline/綣遺 #define 罨蚊? 臀local name stack 腥 +絮 function ц + +getch 綏ュか綽荀臀鴻帥綽荀 Wed Feb 5 01:16:00 JST 2003 -大域で定義された struct field が大域変数と重なっていると落ちる。 -そりゃそうだけど。どうするの? (直した記憶があるんだけどなぁ...) -struct 毎に field 名とoffset/type の組を持てばい良いんだよね。 - -なんだけど、タグ無しの構造体もあるから、型名の方に付ける必要 -もある。というのは、型名のない構造体もあるから。タグ名には、 -一応、リストがついている。なんかに使う必要があったんでしょう -ね。あ、めんどう。無条件にやっても大域変数名を汚すのを直すの -が難しい。 - -ちょっと、あれだけど、「型名.フィールド名」で登録してしまうのはどう? -型名が後で出て来るところが気まずいが... - -def で登録するときに、nptrにdispを代入せずに、struct field list -(大域変数) に入れて、type の方に、field list (list3(nptr,offset, -type)) を入れれば良い。 - -あとは、strop の方でtypeのlistを見るようにすれば良いわけだ。 - -これなら、簡単に直せるはず。LUSTR/GUSTRなどの区別もなくなるし。 +紊уу臂 struct field 紊у紊違c純< +? (眼荐吟...) +struct 罸 field offset/type 腟違 + +帥亥<罕篏鴻篁綽荀 +罕篏帥医 +筝綽鴻ゃ篏帥綽荀cс +≧>散c紊у紊医羆眼 +c + +<c.c若х脂蚊障? +緇у冴ャ羂障... + +def х脂蚊nptrdisp篁eャstruct field list +(紊у紊) ャtype 鴻field list (list3(nptr,offset, +type)) ャ域 + +strop 鴻typelist荀域 + +膂≦眼LUSTR/GUSTR阪ャ Wed Feb 5 02:10:14 JST 2003 -浮動小数点ねぇ。完全なANSI Cにするのは大変。でも、 -浮動小数点ぐらいないと。 - -code generation part を、さらに分割して、 -複数のコード対応にしやすいようにする。 -おそらく、それほど共有する部分はないけどね。 - -Sample C code をコンパイルして、その結果から(半分手動で) -Micro CbC code generation part を生成する方法を用意する。 +羌絨亥鴻絎ANSI C紊ус +羌絨亥鴻 + +code generation part 蚊 +茲違潟若絲上 +祉掩 + +Sample C code 潟潟ゃ腟() +Micro CbC code generation part 号 Thu Feb 6 11:47:03 JST 2003 -Code Segment を単位として使うときに、大域変数はどういう -ように分けるの? static なんかは意味ないよね。 - -もちろん、自然にグループ分けされるわけだけど。 - -あとデータフローだよね。データフローに関しては、 -あんまりやってないなぁ +Code Segment 篏篏帥紊у紊違 +? static 潟 + +<吟違若 + +若帥若若帥若≪ +障c Fri Feb 7 14:36:15 JST 2003 -inline では、必らず、局所変数の増加がある。また、inline -は普通の関数として展開しておく必要もあるらしい。(何故?) - -#define ねぇ。 +inline с綽絮紊違紜障inline +∽違絮鏆荀(篏?) + +#define #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+1,b+1); @@ -1377,41 +1377,41 @@ c(a,b); } -local #define がいるんだよね。g の中で a が出て来た時には、 -c のa の置き換えは起こってはいけない。ということは、c -の置き換えはg が始まる前に終っている必要がある。dynamic -scope なんだから、assoc の上乗せで良いはず。 -macro のlevelを定義して、あるレベルでは、それ以前の展開 -を行わないという手法が良いかな。 +local #define g 筝 a 冴ャ +c a 臀莎激cc +臀g 紮障腟c綽荀dynamic +scope assoc 筝箙ц +macro level絎臂с篁ュ絮 +茵羈 c(a,b) => a=>"a+1", b=>"b+1" g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") -みたいな感じ? - -やっぱり関数解析でマクロ処理をやらせるのは無理かな? 先読みされちゃうし。 +帥? + +c宴∽域Вс∞? 茯帥< Sat Feb 8 00:53:52 JST 2003 -macro は途中まで書きました。置き換えをマクロが呼び出された -時点で cheap に置くと、それを解消するタイミングがない。 -ここだけmallocしても良いが.. - -chptrsave はlistにする必要がある。list で良い。 - -やっぱりmacro levelを見て、自分と一致したassoc valueまで -手繰って置換するんでしょう。そうすれば、置き換える必要は無い。 -ということは、local_define にmflagsを格納する必要がある。 +macro 筝障ф吾障臀若喝冴 +鴻 cheap 臀茹f帥ゃ潟違 +malloc.. + +chptrsave list綽荀list ц + +c宴macro level荀筝眼assoc value障 +膵違c臀с違臀綽荀< +local_define mflags主綽荀 c(a,b) => a=>"a", b=>"b" a=>"a" .. mflag == 1 g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") a=>"a+1" .. mflag == 2 -macro のもとのnptr が残ってないと、オリジナルを返せない。オ -リジナルは、sc などが破壊されてしまう。ってことは、local macro -は、local table を汚してはいけないってことだよね。ってことは、 -macro table は、もとのとは別に用意する必要がある。 +macro nptr 罧c吾菴 +吾sc 翫障clocal macro +local table 羆cc +macro table ャ綽荀 #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+2,b+2); @@ -1431,7 +1431,7 @@ #endif } -うーむ。ややこしい。 +若 main() c(a,b) mflag++ @@ -1439,11 +1439,11 @@ g(a,b) mflag++; a=>"a+1" mflag ==2 ^ is replaced by c's "a" not g's a; -いったん mflag level n で展開したら、それは mflag level n-1 となる。 +c mflag level n у mflag level n-1 Sat Feb 8 18:13:43 JST 2003 -いちおう、mflag まではデバッグしたが.... mflag を戻してないんじゃないの? +<mflag 障с違.... mflag 祉? ---c(a,b)----------------------- mflag ==1 a=>hoge, b=>hoga (mflag==1) @@ -1452,22 +1452,22 @@ ----printf(a,b)---------- mflag ==3 a=>poge, b=>poga(mflag==3) -g が呼び出されると、ac,bc は mflag==1 でのみ置換される。 - -あるテキストを置き換えると、それは置き換えたマクロのmflag level -(つまり一つ少ないレベル)になる。 -置き換え終ったら、元のlevelに戻す。 - -mflag==2のlevel では、mflag==2のlocal macroの展開しかしない。 - -置き換えると、mflag level 1 になるので、そこで mflag==1 のlocal -macro を展開する。mflag==0 は常に展開を行う。 +g 若喝冴ac,bc mflag==1 с睡舟 + +鴻臀臀mflag level +(ゃ障筝ゅ) +臀腟clevel祉 + +mflag==2level сmflag==2local macro絮 + +臀mflag level 1 с mflag==1 local +macro 絮mflag==0 絽吾絮茵 Sun Feb 9 11:35:23 JST 2003 -うーん、なんかtypeが、list とCHARなどと入混じっているじゃん。 +若typelist CHARユ祁c int save = chptrsave; -で、chptrsave が、$chptrsave になってしまう。 +сchptrsave $chptrsave c障 Sun Feb 9 22:33:36 JST 2003 @@ -1476,64 +1476,64 @@ #define cadr(e) (heap[((int)(e))+1]) car(cadr(e)) -だろ。 + car -> #define e cadr(e) (mleve=1) cadr -> #define e e (mleve=2) -むぅ。これ、うまくいかないんじゃん。こまったなぁ。 +障障c #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+1,b+1); c(a, b); -こっちもだめじゃん。ふーむ。lisp interpreter のように -作ればいいはずなんだけど。 +c<泣若lisp interpreter +篏違 Mon Feb 10 08:10:25 JST 2003 -結局、list base のinterpreter を実装しました。きちゃないが。 -前の方法でも、頑張ればできるんでしょうけどね。 +腟絮list base interpreter 絎茖障< +号с綣泣違сс Tue Feb 11 13:50:03 JST 2003 -struct copy だけど... 関数がstructを返すときに、引数に前もって -積んでおくのでは、そこに値がコピーされてしまうし、あとで、 -スタックをたたんで置くときにきまずい。 - -function call の時に、引数の型のチェックをしてない - -type に -1 とheapの引数が混在しているやつだけど.. -やっぱまずいんじゃないか? - -temporal struct は再利用できるんだけど、dispの変更ができないので -新しく作るしかない。大きいときだけ新しく作るなんていうセコイ -技はあるけど。(そうすると、帰って来た値へのポインタを使えなく -なるが.... 別にいいよね。戻り値それ自身を直接 return する -時もだいじょうぶなはず) - -結局、呼出側で、領域を確保して引き渡すことにしました。この方法だと、 -代入のときに二度コピーする必要もない。 - -register を使用しているかだけじゃなくて、実際にcreg/dregに -値があるかどうかを記憶する必要がある。 +struct copy ... ∽違struct菴綣違c +腥ссゃ潟若障с +鴻帥х舟障 + +function call 綣違с + +type -1 heap綣違羞桁ゃ.. +c宴障? + +temporal struct сdisp紊眼с +違鋎紊с違鋎祉潟 +(絽違cャゃ吾ゃ潟帥篏帥 +.... ャ祉ゃ荳贋・ return +吟) + +腟絮弱阪眼с腆坂綣羝<障号 +篁eャ篋綺潟若綽荀 + +register 篏睡絎creg/dreg +ゃ荐吟綽荀 Wed Feb 12 11:09:22 JST 2003 -それだけどさ... やっぱりアドホックに実現するのは難しいんじゃないの? - -まぁねぇ。register の場所の確保と、寿命は別だから、それで -いいんだけど、regs flag だけでなんとかならないのかな。 -こういう変更ははまるが虚しい。 +... c宴≪絎憗c? + +障register 贋腆坂絲水純ャ +regs flag с +紊眼障 Thu Feb 13 18:37:36 JST 2003 -さて、そろそろ jump にとりかかりますか。 - -構造体の引き渡しのシークエンスに使う局所変数の位置がgccと違う... - -そろそろ register は構造体にすべきだね。 + jump 障 + +罕篏綣羝<激若潟鴻篏帥絮紊違篏臀gcc... + + register 罕篏鴻 struct register { int used; int valued; @@ -1543,61 +1543,61 @@ int type; /* register variable or not */ int number; } -virtual/real は、どうする。 +virtual/real Sat Feb 15 14:00:03 JST 2003 -fdecl_struct を構文的に引数が出現するときに行うと、int *f(int -a) などで、* の評価が終る前に、int aが評価されしまう。*obj -のobj を評価し終らないとfのタイプが確定しない。int*f()[] み -たいな場合があるから。(?) なので、gcc と、そろえるためには、 -arg の先頭で fdecl_struct を行う方法ではだめで、fdecl 中であ -とから修正する方が良い。 - -fix しようにも引数リストなんて、存在しないじゃん! - -varargs を実装するのはめんどくさかろう... - -rvalue(expr(),type) では、expr() のtypeをrvalueに引き渡せな -い。でも、type を大域変数にすると、rvalueを異なるタイプで呼 -び出すときにtypeを変更する必要がある。このrvalueのtype の扱 -いは、かなりはまったことがあるので、rvalue(int e,int type)の -方が良いことは確かなんだが... - -struct_push のregisterの扱いが複雑すぎ。なんか、もっと -簡単にならないの? +fdecl_struct 罕綣違榊憗茵int *f(int +a) с* 荅箴<腟int a荅箴<障*obj +obj 荅箴<腟f帥ゃ腆阪int*f()[] +翫(?) сgcc +arg fdecl_struct 茵号ссfdecl 筝с +篆罩c鴻 + +fix 綣違鴻絖! + +varargs 絎茖... + +rvalue(expr(),type) сexpr() typervalue綣羝< +сtype 紊у紊違rvalue違帥ゃу +喝冴type紊眼綽荀rvaluetype +障cсrvalue(int e,int type) +鴻腆冴... + +struct_push register宴茲c +膂≦? Sun Feb 16 07:58:23 JST 2003 -代入しなくて良いからと言って、ソース -のリストから除いては、上書きを防げない。 +篁eャ荐c純若 +鴻ゃ筝吾蚊 Sun Feb 16 22:55:58 JST 2003 -vdisp ってなんだったんだ? +vdisp cc? Mon Feb 17 12:35:39 JST 2003 -並列代入は出来たみたい。代入は小さいものを先にすべきなのか? -まぁ、できりゃいいんだけど、横に避けるものが大きいのはいや -だよね。 +筝篁eャ堺ャ帥篁eャ絨鴻? +障с罔帥紊с + Tue Feb 18 11:56:10 JST 2003 -overlapped 用の emit_copy +overlapped emit_copy float/double long long Tue Feb 18 19:34:31 JST 2003 -code argument の符号を反転させると、list2(LVAR,offset) -のoffsetがアドレスの方向と一致しているという前提が -崩れる。それで、構造体の格納順序がずれてしまう... - -ということは... def(n) でcodeの時はargumentは、局所変数と同じ -扱いでマイナス符号で処理した方が良い。 - -できたみたい。でもさ、 +code argument 膃垩荵≪list2(LVAR,offset) +offset≪鴻劫筝眼 +經с罕篏主綺障... + +... def(n) codeargument絮紊違 +宴сゃ合垩у鴻 + +с帥с int main( int ac, char *av[]) { @@ -1605,344 +1605,344 @@ goto arg1(0,1,2,3,4,return,environment); } -って、きっと return 文がないと、文句を -言われるよね。むむむ。 - -post processing する時にoverlapしてないという保証がない。 +cc return ャ +荐 + +post processing overlap篆荐若 Wed Feb 19 15:38:55 JST 2003 -自分自身とのoverlapを見てないので、 +荳overlap荀с struct a a,int i int i,struct a a -みたいな時に自分自身を壊してしまう。なので、emit_copy -が、ちゃんと方向を見て壊さないように処理する必要がある。 - -call bcopy でいいじゃん。まね。 +帥荳紕障сemit_copy +<劫荀紕綽荀 + +call bcopy с障 Wed Feb 19 20:42:07 JST 2003 -楊さんの C2CbC と CbC2C を、micro C に取り込む。各所に、 -conv->func(); を埋め込む。conv は、構造体。 +罐 C2CbC CbC2C micro C 莨若 +conv->func(); 莨若conv 罕篏 conv: original c2cbc cbc2c -とする。なるほど。 +祉 Thu Feb 20 05:34:58 JST 2003 -むぅ。code-ia32 で結構はまった。あと、stack のアライメントが -ずれるみたい。6809では問題にならなかったんだけどね。 -leave で調整するべき。 +code-ia32 х罕障cstack ≪ゃ<潟 +帥6809с馹c +leave ц炊眼鴻 Thu Feb 20 14:42:46 JST 2003 -c2cbc,cbc2c なんだけど、いったん、構文木にしてから変換すると、 -結構失われる情報があるけど、いいの? 特に局所変数の名前とか型 -の情報とか。macro もそうだけど。 indent ぐらい保存できないか -なぁ。式の途中でfunction callする場合も取り扱う必要があるの -で、構文木にしてから計算するしかないかな。gexpr の代わりに生 -成するようにするか。そうすると、修正するのは、statement と、 -gexpr になる。でも、結局、構文木で型を持ち歩くしかないんじゃ -ないの? やっぱり変だよ。型の情報がないのは。 - -そうではなくて、exprN() で変換していく方法もある。この方が -情報が欠落しないので楽だろう。そうすると、修正するのは、 +c2cbc,cbc2c c罕紊 +腟罕紊宴宴? 鴻絮紊違 +宴macro indent 篆絖с +綣筝function call翫宴綽荀 +с罕荐膊gexpr 篁c +篆罩cstatement +gexpr с腟絮罕у≧ +? c宴紊宴 + +сexprN() у号鴻 +宴罨純фソ篆罩c exprN(),doXXXX() -となる。これは、量は多い。けど、まぁ、それだけ。この方が -オリジナルを保存しやすい。 - -中間変数を途中で追加すると、宣言部を前もって出力できなく -なる。{int a;...} を認めれば良いわけだど。実装は難しくない。 -じゃ、やれば? でも、汚くなるなあ。出力をいったんバッファ -に貯めれば? どこに? cheapp ですか? 中間変数はいらないん -じゃないの? +紊障鴻 +吾篆絖 + +筝紊違筝ц申絎hc阪с +{int a;...} 茯域絎茖c +? с羆阪c +莢? ? cheapp с? 筝紊違 +? a = g(i)+a; -でしょ。 +с goto g_1(i,f_1,save_a); } code g_1(i,f_1,save_a) { .... goto f_1(ret_value,save_a); } code f_1(ret_value,save_a) { a = ret_value+a; ...} -じゃん。いらないじゃん。。 - - -型を表示するルーチンが必要だね。 - -めんどくさいなぁ。CbCのProlog version とかほしいなぁ。そうすれば、 -変換は簡単。でも、やろうとしてできなかったことでもあるな。 + + + +茵腓冴若潟綽荀 + +CbCProlog version 祉違 +紊膂≦ссcс Thu Feb 20 21:13:23 JST 2003 -MC6809 の mc-codegen.c version は? (ちょっと虚しすぎる?) -X と D で、use_data_register, use_pointer してやる。 -tosop で、X と D の間の足し算を特別扱いする。 -(なるほど...) MAX_MAX=0でうまく動くのか? やっぱり、1は -いるよね。できれば、2だよね。 - -結構、浮動小数点も簡単かも。 - -汎用の書き換えツールも便利そう。 - -でも、Prolog version ってのも面白そう。 +MC6809 mc-codegen.c version ? (<c?) +X D сuse_data_register, use_pointer +tosop сX D 莇潟膊劫ユ宴 +(祉...) MAX_MAX=0с障? c宴1 +с違2 + +腟罕羌絨亥鴻膂≦ + +羆吾若箴水 + +сProlog version c∝純 code(name,interface(....)) :- p()....,goto(name,interface(....)). -みたいな感じ? 結構、簡単にinterpreterを書けるかも知れない。 -これは、あれだね。thread diagram interpreter と似ている。 +帥? 腟罕膂≦interpreter吾ャ +thread diagram interpreter 篌若 Fri Feb 21 13:34:17 JST 2003 -構文要素での書き換えだけど、どれくらいの能力があるの? -その場での書き換えだけだと、ちょっと低すぎない? それで、 -cbc2c,c2cbc はできるとは思う。 - -まぁいいけど.. chk を無視しているところが結構あるんですけど。 +罕荀膣с吾遵? +眼с吾<c篏? с +cbc2c,c2cbc с + +障.. chk ∴腟罕с jmp,enter,leave ... Sat Feb 22 13:05:04 JST 2003 -type の印刷かぁ... - -conv 系は大半はdefault convが呼ばれる。なので、c.c -っていうよりは、default.cだよね。必要なところだけ、 -自分で代入すると言う方法が良いだろう。その方が -ヘッダも一つで済むし。もちろん、object 指向なら -簡単なんだが... +type 医激... + +conv 膤祉紊уdefault conv若違сc.c +cdefault.c綽荀 +т撮ャ荐号鴻 +筝ゃф<object +膂≦... Sun Feb 23 19:47:41 JST 2003 -struct のtypeを印刷するんだけど、一回印刷したら、あとは印刷 -しない方が良い。逆に毎回書くなら、tag名type名は、いらないの -か。 - -とするとtypeの解釈はやめてndeclで処理する? 印刷では、それで -いいわけだけど。 - -このタイプの印刷だと再帰型は印刷が終了しないんじゃないか? -しないね。 +struct type医激筝医激医 +鴻罸吾tagtype + + +type茹indeclу? 医激с + + +帥ゃ医激絽医医激腟篋? + Mon Feb 24 02:31:06 JST 2003 -strings の\nなどを元に戻す必要がある。 - -なんか括弧がわやになってるな。 +strings \n祉綽荀 + +綣сc Mon Feb 24 11:02:07 JST 2003 -typedef されたタイプは、そちらを使う方が良い。けど、情報が失 -われてしまっているので、どこかにとっておかないとだめだね。dsp +typedef 帥ゃ<篏帥鴻宴紊 +障cсcdsp ? -うーむ、これはなかなか難しい。全サーチしてもいいんじゃないか -な。遅いけど。少なくともgnptrで定義されたものはサーチすべき -でしょう。 - -indirect function type の表現がなぁ.... - -sdecl ではconv を行うので、type_print ではsdeclを経由した場 -合に表示を行ってはいけない。 - -なんか関数の引数の型の値が微妙に変わるんですけど... やだなぁ... - -まだ、関数定義のtypedefがstructに変わってしまう。gtypedefed -がうまく動いていない? +若c泣若 +絨gnptrу臂泣若鴻 +с + +indirect function type 茵憗.... + +sdecl сconv 茵сtype_print сsdecl腟宴 +茵腓冴茵c + +∽違綣違ゃ緇絋紊с... ... + +障∽医臂typedefstruct紊c障gtypedefed +障? Mon Feb 24 17:24:31 JST 2003 -まぁねぇ。やっぱり完全に構文木から再構成した方が -便利ではあるよね。特に getsym (空白など)と conv->x_() -との総合作用はめんどくさい。 - -そのためには、局所変数名をtree上で持ち歩く必要がある。 -まぁ、そうすれば良いだけだけど。 - -実際、今のセットで出来るかどうかは、ちょっと怪しい。 -たぶん、buffer に出力するってのをいれればおそらくは -変換できるだろう。 - -式の途中での呼び出しとかを考えると、やっぱり -構文式から生成しないとだめだろうね。 -(ってことは、まだ、かなりの作業があるってこと.... むぅ...) -tmp2.c は、通らないし... +障c宴絎罕罕鴻 +箴水с鴻 getsym (腥榊純) conv->x_() +膩篏 + +絮紊医tree筝ф≧鏆荀 +障域 + +絎篁祉у堺ャ<c +吟buffer 阪c違 +紊с + +綣筝с若喝冴c宴 +罕綣 +(c障篏罐c.... ...) +tmp2.c ... Fri Feb 28 20:32:46 JST 2003 -で、c2cbc は、途中で float の方を先にやるわけ? +сc2cbc 筝 float 鴻? Sat Mar 1 22:05:43 JST 2003 -creg_destroy は、ぜんぜんだめ。これは基本的なアイデアがだめ。 - -long long はstructでいいんじゃない? だめ? で struct 演算を別に -定義してやる。これは、実装にもよるか。 - -float,long longなんだけど、 +creg_destroy 堺≪ゃ≪ + +long long structс? ? struct 羲膊ャ +絎臂絎茖 + +float,long long FRGVAR DRGVAR LRGVAR -などを作る。さらに、 +篏 FMUL DMUL LMUL -などもいる。型の変換は binop で解釈する。変換も演算になる。 +紊 binop цВ紊羲膊 D2F, D2I, F2D, F2I, I2D, I2F, U2D, U2F -ぐらいですか? - -emit_pushは、型を必要とするけど? そうだねぇ。emit_fpush, emit_dpush -かな? - -creg にfloat register(or stack) の値を入れればいいんじゃないの? -それを見て、emit_pushの型を決める。creg は、けっこう、いろんあ -ものが見ているので、いじらない方がいいじゃないかなぁ。 -そうね。FMULとかがあるなら、それで判断できそう。 - -構文木には型を含めないってのは不便。型を入れれば? そうすれば、 +с? + +emit_push綽荀? emit_fpush, emit_dpush +? + +creg float register(or stack) ゃャ違? +荀emit_push羆冴creg c +荀с鴻 +FMULуゆс + +罕c筝箴帥ャ? 違 RGVAR CRGVAR FRGVAR DRGVAR LRGVAR -ではなく、 +с RGVAR -ですむし。その方が変形も楽だしね。型は、 +с鴻紊綵≪罐純 CHAR,UNSIGNED, UNSIGNED CHAR, INT, FLOAT, DOUBLE, LONGLONG -ぐらいですか。 +с emit_data -とすると、書き換えが結構あるけど。 +吾腟罕 Sun Mar 2 12:58:38 JST 2003 -あとはconstantだね。FCONT,DCONSTかな。binopでは -変換とかも必要なわけだけど。 - -そういえば、shot のload/storeもないね。SRGVAR,SASSとかですか? SASS -は、すでにあるなぁ。 +constantFCONT,DCONSTbinopс +紊綽荀 + +違shot load/storeSRGVAR,SASSс? SASS +с Sun Mar 2 22:01:58 JST 2003 -あれ? +? conv->_sm(); (*conv->_sm)(); -の場合は、 - *conv->_sm の値へcallする -んだけど、 +翫 + *conv->_sm ゃcall + goto exit1(); goto (*exit1)(); -の場合は、 +翫 exit1 -の値へjumpするんだよね? およ? なんか勘違いしてる? なんでexit1() -だとindirectが出て、(*exit1)だと出ないんだろう? - -この宣言は、 +ゃjump? ? ? exit1() +indirect冴(*exit1)冴? + +絎h void (*_sm)(); -であって、 +сc void _sm(); -はできない? なんで? - -あぁ、まぁ、いろいろ、めんどくさい。 - -やっぱり、arglist の再帰的扱いがちゃんとしてないとだめ。 - -うーむ、 enum なんてのもあるのね。やさしいけど、いるのか? - -code (code *) * みたいなのがあるので、conv は手直しが必要。 +с? ? + +障 + +c宴arglist 絽亥宴< + +若 enum ? + +code (code *) * 帥сconv 眼綽荀 Mon Mar 3 12:38:08 JST 2003 -float/double は順調に進んでるけど、3日はかかるでしょう。 - -binop を書いちゃうとmc-parse.c は、ほとんど終り?! -代入と関数呼び出しが残っているか。あと single もあるね。 - -emit_push base で書くんだけど、他のCPUではだいぶ様相が -違うんだろうな。 - -dreg/creg のfloating versionが必要です。( です? ) +float/double 茯帥蚊с3ャс + +binop 吾<mc-parse.c 祉腟?! +篁eャ∽医若喝冴罧c single + +emit_push base ф吾篁CPUс倶吾 + + +dreg/creg floating version綽荀с( с? ) Tue Mar 4 14:56:28 JST 2003 -double のcurrent register は387のスタックを使う。(?) -関数呼び出し時に387のスタックが保存されるという -保証は無いので、emit_dpushでは、%esp に保存する。 - -でも、そうすると、代入の後などで387のスタックが -常に残ることになる。こいつをクリアするコードは -どこにいれる? free_register でもいいんだけど.... -ううーむ、つかいずらいやつ。ld じゃなくて、 -stack top に代入するオペレーションはないの? - -(あぁ、でも、なんか、floatは、もうすぐ終っちゃうな... なんか、 -さびし...) +double current register 387鴻帥篏帥(?) +∽医若喝冴387鴻帥篆絖 +篆荐若<сemit_dpushс%esp 篆絖 + +с篁eャ緇387鴻帥 +絽吾罧ゃ≪潟若 +? free_register с.... +若ゃゃld +stack top 篁eャ若激с潟? + +(сfloat腟c<... +潟...) Tue Mar 4 23:58:07 JST 2003 -fmulp とかでは、fpp のstackのつじつまはあう。fstl とかだと、 -合わない。fstpl すればいいんだが、そうすると連続代入でまずくなる。 -値を使うかどうかを代入時に知ることができれば良いんだが。 -(use flag で判断することにした) - -結局、freg は、使わなかったね。0が、入っているので直さないとまずいか。 -fregを見て、stack を直すってのは、やっぱり、まずいよな... - -でも、浮動小数点レジスタを持つCPUの場合はいるんじゃないの? +fmulp сfpp stackゃゃ障fstl +fstpl 違g篁eャс障 +ゃ篏帥篁eユャс域 +(use flag уゆ) + +腟絮freg 篏帥c0ャcх眼障 +freg荀stack 眼cc宴障... + +с羌絨亥鴻吾鴻帥CPU翫? Wed Mar 5 11:25:11 JST 2003 -printf では 引数はdoubleで統一する必要がある。goto() では、 -それをするのはまずい。局所変数と同等だから。ってことは、 - -関数の引数はdoubleにしないとだめなのね。プロトタイプが -ある時は、その限りでない。(うーむ...) - - (くそ、こいつの副作用が結構出るな...) - -あと、fpp のスタックに頼っているので、overflowした時に -困らないか? ほとんどの場合でだいじょうぶだが、だめだった -時にerrorぐらい出せば? でも実行時にしかわからないか... - -I2D でさ、signed/unsigned の区別がいるね。 - -やっぱり FCONST いるんじゃないの? +printf с 綣違doubleх輝筝綽荀goto() с +障絮紊違膈c + +∽違綣違double帥ゃ +с(若...) + + (ゃ篏腟罕冴...) + +fpp 鴻帥若cсoverflow +違? 祉翫с吟c +error冴? с絎茵... + +I2D сsigned/unsigned 阪ャ + +c宴 FCONST ? Wed Mar 5 19:51:59 JST 2003 -副作用以外は終ったけど.... あと、name space が結構重なっている -んだよね。 +篏篁ュ腟c.... name space 腟罕c + struct tag, struct field -が重なっているのは結構うっとうしい。gsearc/lsearch のあたりも -書き直さないとだめかも。 - -あと、list もなぁ。mode の作り方にもよるんでしょうけど。 - -あと、結構、汚いよな... +c腟罕cgsearc/lsearch +吾眼 + +list mode 篏鴻с + +腟罕羆... Wed Mar 5 21:15:34 JST 2003 -できたよ。まだ、テストしてない部分はあるけど。局所変数の初期化とか。 -FCONST とか。3日で出来たね。 - -(gcc の方をやった方がいいかなぁ...) - goto.c が通らなくなってるな。 +с障鴻絮紊違 +FCONST 3ャу堺ャ + +(gcc 鴻c鴻...) + goto.c c Thu Mar 6 14:00:13 JST 2003 -PowerPCのnon-lazy pointerって、テーブルに入っていてそれを読 -み込む形式なのね。いったん、レジスタに読み込んだら、それを再 -利用する形が良いらしい。ということは、code_gvar にキャッシュ -を作らないといけない。しかも RLU ですか? (めんどくさ〜) -でも、そうしないと、 +PowerPCnon-lazy pointerc若ャc茯 +粋昭綵√c吾鴻帥茯粋昭 +綵≪code_gvar c激 +篏 RLU с? () +с i = i+1; -なんてのでも、ひどい目にあってしまう。 - -local variable も最初に move multiple register で大半は -レジスタに読み込んじゃうみたいね。pointer で参照されると -困るんでしょうけど。まぁ、31個もあれば、そういうことを -してもあまり問題ないのかも知れないけど。 - -creg を破壊しない実装にすれば、少しはましになるんじゃない? -(IA32では、それは難しいけど) +с蚊c障 + +local variable move multiple register уぇ +吾鴻帥茯粋昭帥pointer ус +違с障31違 +障馹ャ + +creg 翫絎茖違絨障? +(IA32сc) Thu Mar 6 20:50:24 JST 2003 -やっぱり、使った分だけregisterを保存するようなコードに -なるみたい。one path で、それをするためには、 +c宴篏帥cregister篆絖潟若 +帥one path с .align 2 _main0__: lwz r5,2136(r1) @@ -1964,193 +1964,193 @@ addi r0,r1,64 mr r9,r0 b _main0__; -とかいう感じにするしかないね。 - -あと引数は、レジスタに積むようになっているみたいだけど... r3 から? + + +綣違吾鴻帥腥c帥... r3 ? mflr r31 li r0,7 stw r0,56(r1) -だから8個まではレジスタに積むみたいね。 -r3-r10 だね。 - -構造体もregisterにコピーされるのか。そして、向う側で受取の -コピーを行うわけだね。先頭にreturn structへのポインタがあるのも -同じ。 - -(うう、memcpyしまくりだ...) - -浮動小数点もレジスタ渡し見たい。f1から。(なるほど) - -saveFPってのを呼び出して、 f24-f31をsaveするらしい。 -(31-24)*8 数合わないな? - -pointer のことを考えると、レジスタだとまずいものもある -わけだけど。アドレスを取られてからで間に合うんじゃない? -配列などは、もともとだめだし。場所と値(?)は確保するとして。 - -そうか、逆に、r3-r10 は引数でなければ壊しても良いわけか。 -(それでr9とか良く使われているわけか...) -ということは足りなくなったら、引数をセーブすれば良いわけね。 -(ってことは、LVAR かつ REGISTER っていう状況があるんじゃん... -まぁ、そうだけどさ...) -これは get_register がめんどくさそ。 - -どうも、r11-r12 あたりは自由に使っているらしい。 - -引数を作っている途中で関数呼出しするときは、どうするの? -r30などに移動するのか? - -なんか知らんけど、in file call name と out file call name が -違うみたいね。(sigh...) こんなのなんとかなるのかなぁ。 -全部、stub にしておいて、.set で書き換えるという手もあるけど。 - -(さすがに一日ではできないか...) - -なんか整数から浮動小数点への変換はじぶんでやらないとだめなのね。 -これはサブルーチンを呼んだ方がましだ。 - -get_register は絶対失敗しないようにできるんじゃないか? - -label があると、code_base cache はclearしないといけない。 -それを判断するには fwddef をhookする必要があるけど。 +8障с吾鴻帥腥帥 +r3-r10 + +罕篏register潟若眼у +潟若茵return struct吾ゃ潟帥 + + +(memcpy障...) + +羌絨亥鴻吾鴻炊検荀f1(祉) + +saveFPc若喝冴 f24-f31save +(31-24)*8 医? + +pointer 吾鴻帥障 +≪鴻ч? +贋(?)腆坂 + +r3-r10 綣違с医 +(r9鋎帥...) +莇潟c綣違祉若域 +(cLVAR REGISTER c倶... +障...) + get_register + +r11-r12 宴篏帥c + +綣違篏c筝ч∽医弱冴? +r30腱糸? + +ャin file call name out file call name +帥(sigh...) +stub .set ф吾 + +(筝ャсс...) + +贋違羌絨亥鴻吾紊吟с +泣若潟若鴻障 + +get_register 腟九上けс? + +label code_base cache clear +ゆ fwddef hook綽荀 Fri Mar 7 09:17:10 JST 2003 -問題は、 +馹 register allocation -と + function call/goto call -の構成だな。goto の方は machine dependentなところは -ほとんどない。register のsaveさえ必要ないから。 - -register allocation だけど。 +罕goto 鴻 machine dependent +祉register save綽荀 + +register allocation r0 r1 frame pointer (or stack pointer ) r30 jj r31 relocation register - r0,r1,r2 システムで使う - r0-r10 引数 - 引数でないところは優先的に使う - r20-r29 セーブして使う領域 - -r10-r19 はどうなんだろう? セーブしないのか? - -ia32 の方でもfppのスタックを関数呼び出しのときに吐き出した方が -良い。 + r0,r1,r2 激鴻т戎 + r0-r10 綣 + 綣違с篏帥 + r20-r29 祉若篏帥 + +r10-r19 ? 祉若? + +ia32 鴻сfpp鴻帥∽医若喝冴冴鴻 + r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 r16 r28 r29 r30 r31 -なので、もののみごとに、17-27 までが使われてないね。 - -ということは、関す呼出し時には、保存されるレジスタはないと -思った方が良いってこと? あるいは、r17-r28 は保存されると -思って良いのかな。 +с帥17-27 障с篏帥 + +≪弱冴篆絖吾鴻帥 +c鴻c? r17-r28 篆絖 +c Sat Mar 8 19:28:42 JST 2003 -関数呼び出し時のレジスタセーブを避けるためには、関数呼び出し -を優先して実行してやれば良い。関数呼び出しの結果は局所変数に -セーブする。 +∽医若喝冴吾鴻帥祉若帥∽医若喝冴 +絎茵域∽医若喝冴腟絮紊違 +祉若 f(g(h(a)+1)+2) -は、 + a1=h(a) a2=g(a1+1) f(a1+2) -となる。そうすれば、関数呼び出しのときのスタックはかならず0になる。 - -でも、結局、引数は関数呼び出しの前にセーブするのね。だったら、 -そんなことしないで、セーブすれば良いのか。 +違∽医若喝冴鴻帥0 + +с腟絮綣違∽医若喝冴祉若c +с祉若域 Mon Mar 10 11:42:40 JST 2003 -で、レジスタのセーブなんだけど、mc-codegen.c を変更しない -とすれば、引数のリストを使って変更していくのが良い。 -関数呼び出しは基本的には並列代入になる。並列代入でき -てもできなくても、セーブする必要はある。今の並列代入 -ルーチンのできは良くないので、「同じかどうか」だけ -判断するのが良いのではないか? - -関数呼び出しの前に式用にレジスタに積まれた値はセーブした -方が良い。セーブした後はlvarとしてアクセスすることになる。 -スタックでもいいけど。 -そうすると、stack 配列には、 - - レジスタ レジスタ番号 (>0) - スタック -1 - lvar lvar番号 - -の三種類が入ることになる。それに合わせてtosop/assopを書き直 -す必要がある。emit_pop だけでいいかも。スタックを止めちまう -のも手ではあるが、ia32の方で効率が悪い。やっぱり三種類サポー -トするのが良いだろう。 - -(けっこういろいろあるなぁ... どこから手を付けるか...) +с吾鴻帥祉若mc-codegen.c 紊眼 +違綣違鴻篏帥c紊眼 +∽医若喝冴堺筝篁eャ筝篁eャс +с祉若綽荀篁筝篁e +若潟сс +ゆс? + +∽医若喝冴綣吾鴻帥腥障ゃ祉若 +鴻祉若緇lvar≪祉鴻 +鴻帥с +stack + + 吾鴻 吾鴻睡 (>0) + 鴻帥 -1 + lvar lvar + +筝腮蕁ャtosop/assop吾 +綽荀emit_pop с鴻帥罩≪<障 +сia32鴻у合c宴筝腮蕁泣 + + +(c... 篁...) Tue Mar 11 14:23:57 JST 2003 -save_stacks すると、レジスタはほとんど使われなくなって -しまう。が、コードの見通しは良くなる。 - -定数を右辺に持って行くとsave_stacksでsaveする量が減る。が以 -外にめんどくさいね。反射律が成り立たない演算子に関しては。tosop -の定数版とか作ることになるので... あとスタックに積む順序が逆 -になってしまう。まぁ、もとの版では行われていたことだが... -CMPではrexpr で反転して論理を逆転させる方が簡単か。SUBでは、 -ADD + (-CONST) にする方が良いね。 +save_stacks 吾鴻帥祉篏帥c +障潟若荀 + +絎違勈昇c茵save_stackssave羝篁 +紊絨緇腴羲膊絖≪tosop +絎亥篏... 鴻帥腥綺 +c障障с茵... +CMPсrexpr у荵≪茫荵≪鴻膂≦SUBс +ADD + (-CONST) 鴻 je _xxx -したあと、current register のregv[]が残ってしまう。これは、 -変だよね。gexpr_init で regv が残るのは、case 文の比較だけ。 -あとは全部0にして良い。(まぁ、害は無いんだけど) - -(case 文のjumpは、switch 文が終る時に処理すれば、index jump -にすることができるね) +current register regv[]罧c障 +紊gexpr_init regv 罧case 罸莠 +0(障絎潟<) + +(case jumpswitch 腟違index jump +с) Wed Mar 12 12:58:47 JST 2003 -比較で入れ換えるとの否定は若干違うよね。 +罸莠уャ絎ュ慌 Thu Mar 13 19:39:48 JST 2003 -そういえば、doif で条件が定数だったときとかの最適化は -してないんだね。やさしいけど。chk を使えば良いので。 +違doif ф>散絎違c +chk 篏帥域с f(g(1,2,3),g(1,2,3),g(1,2,3)) -とかだと、結局、g の返り値は一旦メモリに入れないとだめじゃん。 -なんだけど、実際は、r29-r22 を使っているようですね。 - -ってことは、function call の時に、r3-r10 が前の引数かどうかを -チェックして、引数だったらr29-r22に移す作業がいるわけだよね。 -いったんr3とかに入れてしまった後だと、重複してしまうが... -前もって関数呼出しがあるかどうかは、調べることができるから、 -関数呼び出しがあったら、そうするようにする? - -いろいろめんどくさいなぁ... (いったい、いつなったらできるんだ?) +腟絮g 菴ゃ筝<≪ャ +絎r29-r22 篏帥cс + +cfunction call r3-r10 綣違 +с綣違cr29-r22腱祉篏罐 +cr3ャ障c緇茲障... +c∽医弱冴茯帥鴻с +∽医若喝冴c? + +... (cゃcс?) Fri Mar 14 10:38:25 JST 2003 -function の dsp が、arglist と extern flag の両方を入れてしまっている。 -本来は sc で区別するべき物だよね。 - -なんか、emit_pop_free のxregがLVARの時のバグを取るのに苦労した... -gdb は top level でのwhile を受け付けなくて、define してやなんないと -だめみたいね。 +function dsp arglist extern flag 筝≧鴻ャ障c +ャ sc у阪ャ鴻 + +emit_pop_free xregLVAR違眼... +gdb top level сwhile 篁define +帥 Fri Mar 14 15:50:28 JST 2003 -なぁ... 書いても書いても書いても、終らん! +... 吾吾吾腟! Fri Mar 14 19:43:44 JST 2003 -jump の中で input register を割り振るときに floating point register の -ことを考えてなかった。これは register_var とは異なるので異なる -仕組みで割り振る必要がある。ってことは、get_input_register_var -が要るってこと? +jump 筝 input register 蚊 floating point register +c register_var 違х違 +篁腟帥у蚊綽荀cget_input_register_var +荀c? 0x9001a544 <saveFP+4>: stfd f15,-136(r1) @@ -2173,213 +2173,213 @@ 0x9001a588 <saveFP+72>: stw r0,8(r1) 0x9001a58c <saveFP+76>: blr -なのか。ということは、 - f%d に対して、"saveFP+%d",68-(31-f)*4 -かな? - -うーん、これで、全部書いた気がする。でも、ほとんど全部の -関数にバグがあるだろうなぁ。一つ一つ取っていくしかないか。 + + f%d 絲障"saveFP+%d",68-(31-f)*4 +? + +若с吾羂с祉 +∽違違筝やゅc Sat Mar 15 16:04:09 JST 2003 -やぁ... まぁ.... バグだらけだな。 - -function call のレジスタの処理がでたらめ。RISCの場合は、parallel_assign -した方がいいんじゃないか? +... 障.... 違 + +function call 吾鴻帥сRISC翫parallel_assign +鴻? Sun Mar 16 20:59:10 JST 2003 -あぁ、まだまだ、かかりそうだ.... - -定義されてない関数/定数をextern扱いにする必要がある。(なんで、PICなの?) - -function は c0(n->ty)==FUNCTION で識別する。n->sc には、FUNCTION/EXTRN[1] -が入る。だよね。(CODE)も。だけど、n->ty に戻り型が入っている場合が -けっこうあるらしい。 - -(しかし、これは、結構かかるな...) +障障.... + +絎臂∽/絎違extern宴綽荀(сPIC?) + +function c0(n->ty)==FUNCTION цャn->sc FUNCTION/EXTRN[1] +ャ(CODE)n->ty 祉ャc翫 +c + +(腟罕...) Mon Mar 17 12:02:22 JST 2003 -function のnptrだけど、 - nptr->ty function の return type +function nptr + nptr->ty function return type list3(FUNCTION,return_type,arg_type_list); - nptr->sc 本来はFUNCTION/CODE (EXTRN/EXTRN1) - nptr->dsp 引数のリスト -と言う構成なわけだよね。で、引数のリストとtypeは重複している。 - -他のnptrとの整合性を考えると、 + nptr->sc ャFUNCTION/CODE (EXTRN/EXTRN1) + nptr->dsp 綣違鴻 +荐罕с綣違鴻type茲 + +篁nptr翫с nptr->ty return type nptr->sc FUNCTION/CODE - nptr->dsp 引数のリスト -が良い。で、引数のリストにEXTRNの情報を入れる方がいいんじゃないか? -(どっちにするんだよ...) - -プロトタイプと実際の引数リストの整合性はチェックしなくちゃ -いけないわけだから、別な方がいいんじゃないか? とすると、 -やっぱり前者か... - - -extern と、そうでないものとの呼出しを、呼出しの時点で -区別しないといけない。しかし、prototype で定義されている -ものと default extern の区別は、最終の時点でしか判別できない。 -できないよね。定義されてないものが default extern なんだから。 -ってことは、最後に、.set で定義するしかないか。(sigh...) + nptr->dsp 綣違鴻 +с綣違鴻EXTRN宴ャ鴻? +(c<...) + +帥ゃ絎綣違鴻翫сс< +ャ鴻? +c宴... + + +extern с弱冴弱冴鴻 +阪ャprototype у臂 + default extern 阪ャ腟鴻сゅャс +с絎臂 default extern +c緇.set у臂(sigh...) Mon Mar 17 14:34:12 JST 2003 -えーと、input register に regv/regs をセットしないとだめ。 -関数呼び出しの引数を評価する前に save する必要がある。 -さらに、引数の評価の後に、save された変数を呼び出す必要が -ある。(ってことは、いままでのは、まったくのでたらめか..) - -register 変数の場合は、問題ない。ってことは、ia32 側も -変更してしまったので、おかしくなっているね。もっとも、 -code の場合は、そういうsaveとかは必要ないから良いのか。 - -(11日目か...) +若input register regv/regs 祉 +∽医若喝冴綣違荅箴< save 綽荀 +綣違荅箴<緇save 紊違若喝冴綽荀 +(c障障с障cс..) + +register 紊違翫馹cia32 眼 +紊眼障cсcc +code 翫save綽荀 + +(11ョ...) mr creg,hoge mr hoge2,creg -とかは、g_expr_u で最適化するべし。set_freg/set_creg でレジ -スタ変数に割り振ると、set_freg でfreeされてしまう。 - -浮動小数点定数の共有はやった方が良い? - -input register のsaveを忘れている。 -input register の割当が逆順。 +g_expr_u ф鴻set_freg/set_creg с +鴻水違蚊set_freg free障 + +羌絨亥劫違掩c鴻? + +input register save綽 +input register 峨 Mon Mar 17 23:38:14 JST 2003 -あぁ、そうか。input-register のアドレスを取ったときは、 -それをLVARに変えないとだめ。 - -なんだけど、途中で分かっても、loop で前に戻ることがあるので、 -手遅れです。ということは、one path ではできないね。 - -むぅ... function call の save_input_register も同じ「手遅れ」 -の問題があるのね。function argument は、すでに parse されて -いて、その引数は、register に固定されてしまっている。 -save_input_register で、save するコードを出しても、 -そちらを見るようには出来てない。(どうすればいいんだ?) - -function callの先頭で、引数を全部stackにsaveしてしまえば、 -このあたりの問題は解決する。けど、あんまりな気もするね。 -でも、stmw も使えるしな... - -結局、input_register は、LVAR のまま処理して、可能ならば -register を使うって方がいいんじゃないかなぁ.... でも、 -そうすると、今まで書いたコードは、ほとんど無駄かぁ... - -いずれにせよ、あんまり簡単な解決はないね。 +input-register ≪鴻c +LVAR紊 + +筝уcloop у祉с +сone path сс + +... function call save_input_register +馹function argument с parse +綣違register 阪障c +save_input_register сsave 潟若冴 +<荀堺ャ(違?) + +function callс綣違stacksave障違 +馹茹f浦障羂 +сstmw 篏帥... + +腟絮input_register LVAR 障上純 +register 篏帥c鴻.... с +篁障ф吾潟若祉♂... + +障膂≦茹f浦 Tue Mar 18 10:46:48 JST 2003 -結局、全部 stack にsave しました。そうすれば、変更は1行。 - -やっぱり、関数全体を構文木に落してからgexprするべきだよね。 -それ自体は、そんなに難しくないが。 +腟絮 stack save 障違紊眼1茵 + +c宴∽医篏罕純gexpr鴻 +篏c Tue Mar 18 12:41:42 JST 2003 -COND(三項演算子)で使うレジスタが関数の引数を破壊してしまう。 -input register にならない値を使えば良いんだけど。r15 -を使っているんだけど、それでいいの? - -virtual を使っていたときは、use_register で何も破壊されなかった -んだけど、使わないとすると、結構破壊されてしまう。なので、 -ちょっと奥の深い問題かもね。三項演算子の型はチェックしてなかったし。 - -まぁ、それは、一時レジスタを使えば良いとして... - -時々呼び出す、u2d とか bcopy とかで破壊されるinput レジスタ -はどうする? これは、予測は困難だよね。使う分だけsaveするって -言う手もあるけど。うー、どうしよう... 検出できるようにするっ -ていう手もある。(と、思ったら、get_register_var が間違ってい -るみたいね) 検出はちょっと重いか。二乗のアルゴリズムは、あま -り使いたくない。といっても、定数乗になるだけか。呼出側でsave -する? bcopy がどれくらい使うか割りと曖昧。 - -もっと積極的にget_register_var するっていう手もあるよね。そ -うすれば、あまり気にすること無く library call できる。(ちょ -っと、書き換えが多いが...) その方が筋かな。使うレジスタを減 -らそうと思うと、それは検出するのと、それほど差はないわけか。 - -このあたりも構文木を全部持っていれば解決できるんだよな。 - -うーん、まだまだ、だな。 - -関数が関数呼び出しで決まる場合の input register の破壊を考えて -ませんでした。これも、どうすればいいんだ... まぁ、get_register_var -するのが簡単だよね。 - -save register が狂っているようだね。max_register_var あたり? +COND(筝羲膊絖)т戎吾鴻帥∽違綣違翫障 +input register ゃ篏帥域r15 +篏帥cс? + +virtual 篏帥cuse_register т翫c +篏帥腟罕翫障с +<c絅ャ羞宴馹筝羲膊絖сc + +障筝吾鴻帥篏帥域... + +若喝冴u2d bcopy х翫input 吾鴻 +? 篋羝育c篏帥savec +荐若... 罎冴с +(cget_register_var c +帥) 罎冴<c篋箙≪眼冴 +篏帥c絎遺弱阪眼save +? bcopy 篏帥蚊с + +c腥罐窮get_register_var c +違障羂< library call с(< +c吾紊...) 鴻膈篏帥吾鴻帥羝 +罎冴祉綏 + +罕c域В羆冴с + +若障障 + +∽違∽医若喝冴ф浦障翫 input register 翫 +障с違... 障get_register_var +膂≦ + +save register cmax_register_var ? Wed Mar 19 02:22:51 JST 2003 -なんだか、struct のtag listが、int a,b,c; のようになっているのを -一つと数えているらしい。困ったものだ。前に言ったのをちゃんと -実装しよう。 - -macro のバグも見つけちゃったよ... むぅ。 - -でも、とりあえず、a.out は動きました。 +struct tag listint a,b,c; c +筝ゃ違違c荐c< +絎茖 + +macro 違荀ゃ<c... + +сa.out 障 Wed Mar 19 12:59:01 JST 2003 -なんか、浮動小数点をprintfに引き渡すときは、rnレジスタにも -値をいれていて、しかも、そっちを見るみたいね。これは、 -めんどくさい.... +羌絨亥鴻printf綣羝<rn吾鴻帥 +ゃc<荀帥 +.... r4,r5 ... f1 r6,r7 ... f2 r8,r9 ... f3 - f4 からは単独 -(あぁ、なんか、これは異常にめんどくさいぞ... こんなことするなら -f0 から r0 にコピーさせてよ...) - -40(r1)とかをprintfは、派手にぶっこわすようですね。いったい -どれだけ取れば良いんだろう? - --112 ぐらい? 今は-72程度か。 - -(なんか風邪ひいた... 家内がくるというのに...) - -浮動小数点のバグも順調に取れています。 - -なんか、save_stack が余計なsaveしてない? -まぁ、一時変数を良く使うのでfree listを作った方が良いかもね。 - -その前に整数演算のチェックが必要だな。 + f4 +(医幻... +f0 r0 潟若...) + +40(r1)printf羇丈吟cсc +域? + +-112 ? 篁-72腮綺 + +(蘂蚊... 絎九...) + +羌絨亥鴻違茯帥障 + +save_stack 篏荐save? +障筝紊違鋎帥free list篏c鴻 + +贋井膊с綽荀 Thu Mar 20 12:06:27 JST 2003 -まだ、save したレジスタを破壊しているな。 +障save 吾鴻帥翫 set L_98,244 stw r15,lo16(-44+L_98)(r1) -ぐらいで、もう壊れちゃうみたい。ってことは、L_98 がもっと -大きくないとダメなのか。 +с紕<帥cL_98 c +紊с< Thu Mar 20 23:43:42 JST 2003 -ようやっと、self compile が通りそう。register save 系が -やっぱり難しいみたいだね。dynamic loader を壊したりするし。 - -あとmodがおかしいみたいで、hashの値が違うらしい。マイナスの値 -になるunsignedのかけ算ねぇ。int.c のrecursionが通らない。 -まだ、offset がおかしいらしい。 - -macro のバグもとれたし。 - -一応は、self compile は通りました。 +cself compile register save 膤祉 +c宴c帥dynamic loader 紕 + +mod帥сhashゃゃ鴻 +unsigned膊int.c recursion +障offset + +macro 違 + +筝綽self compile 障 Fri Mar 21 03:18:26 JST 2003 -やっぱり、r1 と x(r30) の計算が合わない。きっと、 -呼出側で、引数の分のoffset を用意しているのだろう。 -だから、どれくらいの引数の関数を呼び出したかという -値がいるのではないか? +c宴r1 x(r30) 荐膊c +弱阪眼с綣違offset +綣違∽違若喝冴 +ゃс? Fri Mar 21 12:22:11 JST 2003 @@ -2390,14 +2390,14 @@ caller arg xx register save local callee arg xx reg_save disp max_func_args*size_of_int -ということだったみたいね。ようやっと self compile が通りました。 - -free_glist を作るか.... +c帥c self compile 障 + +free_glist 篏.... Sat Mar 22 11:17:41 JST 2003 -creg/freg を g_expr の引数にした方が、レジスタマシン系では、素直な -みたい。そうすれば、 +creg/freg g_expr 綣違鴻吾鴻帥激括鎧с膣眼 +帥違 ## conv->static_(); addis r15,r31,ha16(_conv-L_242) la r15,lo16(_conv-L_242)(r15) @@ -2405,21 +2405,21 @@ lwz r3,244(r3) mr r29,r3 mtctr r29 -みたいな mr は減るね。もっとも一命令だけどさ。3% もあるみたい。 -ちょっと多いか... 386 での use_register もなくなるしなぁ。 -(あぁ、でも大半はポインタキャッシュだな。こっちを直す方が -簡単か) - -まぁ、そういう最適化をしないっていうのが、このコンパイラの立場 -なわけだけど。 - - -構造体の引数渡しでは、構造体そのものをレジスタに載せて -引き渡しているみたいだね。まったく... それで、あわてて -メモリに代入しているわけか。 - -なんか mtctr r2; bdn Lxx とかいうのがあるのね。main frame っぽい! -これはベンチマーク用って感じだね。 +帥 mr 羝c筝巡擦3% 帥 +<c紊... 386 с use_register +(с紊уゃ潟帥c激ャc<眼鴻 +膂≦) + +障c潟潟ゃ腴 + + + +罕篏綣井検с罕篏吾鴻帥莠 +綣羝<帥障c... с +<≪篁eャ + + mtctr r2; bdn Lxx main frame c純! +潟若c Sun Mar 23 16:06:29 JST 2003 @@ -2450,23 +2450,23 @@ 214 if(lineno==0) return; (gdb) c 69 -うまくいかんね。 - -a+a+a....a で落ちてしまう。まぁねぇ。 - -結局、stack frame の問題か。 +障 + +a+a+a....a ц純<障障 + +腟絮stack frame 馹 Mon Mar 24 03:06:32 JST 2003 -Intel 側にもだいぶ embug してしまったようだ。 - -basicとかfloatの難易度を上げすぎたか? - -mc-code-power.c のlvar は、 +Intel 眼 embug 障c + +basicfloatf綺筝? + +mc-code-power.c lvar input arg > 0 local var < 0 output arg > ARG_OFF -とするべきだね。 +鴻 Mon Mar 24 12:08:43 JST 2003 @@ -2487,48 +2487,48 @@ bl _main3 -うーむ、最低な奴。最初の28byteだけレジスタ渡しなのか。アドレス -は変わらないんでしょうけど。まぁ、合わせなくても害は無いけどさ。 -そのうちね。(そんなに難しくは無いが... また、function が複雑 -怪奇になるな) しかし浮動小数点レジスタも使うとかそんなんじゃなくて -良かったかも。 +若篏絅眼28byte吾鴻炊検≪ +紊с障絎潟< +<(c<... 障function 茲 +絅) 羌絨亥鴻吾鴻帥篏帥 +c stwu r1,lo16(-L_9)(r1) -とかしているから、局所変数は64k以内ってことだね。haしてもいいんだけどさ。 +絮紊違64k篁ュcha Mon Mar 24 17:07:59 JST 2003 -さて、ようやっと fact-a.c に取り掛かれるわけだけど、今のままだと、 - input register -> メモリへのsave -ってのがあるんだよね。これはいただけない。sub routine call すると、 -r0-r10 は破壊されちゃうし。ということは、code segment の引数は、 -r29-r20 が良いんじゃないか? 浮動小数点f31-f20を含めて。 - -問題は、どこでinput register を指定するかだけど、get_input_register_var -で code 用かどうかを指定するのが良いかな。fnptr ではダメなので明示した -方が良いだろう。 - -r31, r1 の設定があるのはやむを得まい。r1=r30であった方が良いのだろうか? -その方がfunction calll の時の変更が少ないだろう。 - -メモリとinput register (この場合はr29-r20,f21-f20だけど)の対応は -どうする? 通常だと呼出側が確保するわけだけど、そうはいかないね。 -レジスタもsaveする必要が無いから、いろいろ簡単でよろしい。 - -あとは、return/environment の扱いだけど。ia32 の方でもいろいろ -動かなくなっているようだな。 +c fact-a.c 篁障障 + input register -> <≪吾save +csub routine call +r0-r10 翫<code segment 綣違 +r29-r20 ? 羌絨亥f31-f20 + +馹input register 絎get_input_register_var + code 絎fnptr с<ф腓冴 +鴻 + +r31, r1 荐絎緇障r1=r30сc鴻? +鴻function calll 紊眼絨 + +<≪input register (翫r29-r20,f21-f20)絲上 +? 絽吾弱阪眼腆坂 +吾鴻帥save綽荀<膂≦с + +return/environment 宴ia32 鴻с +c Mon Mar 24 21:56:47 JST 2003 -うーん、別にフレームを変えないで、そのままでいいか。 -その方が楽だよね。return しようと思うといちいち -frame をうごかさないといけないけど、return は -別処理するんだから、いらないか。 +若ャ若紊с障障с +鴻罐純return < +frame return +ュ Wed Mar 26 14:29:21 JST 2003 -で、フレームを変えないとすると、 +с若紊 <------r1_offset------------------------------> * <------------lvar_offset-------> @@ -2537,18 +2537,18 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -なので、r1/r30 を常に移動させる必要がある。前のcode segment/ -function がどこにr1/r30を持っていたかを知る手段はないので、 -jump する前に糢とに戻す必要がある。r30が固定ならばr1のみの -修正で良く、前に戻す必要はない。 - -でも、r1_offset 分を戻せば良いだけなんだから、r30を * に固定 -しても良いんじゃないか? ! でもいいんだけど。こっちの方が簡単 -かな? code の場合は register_save は 0 (つまり、マイナス)な -わけだから。(まぁ、穴を開けておいても良いけど) - -Intel の場合はどうして、こうしなかったのか? (でも、最後にチェック -した時にはcore dumpしていたが...) +сr1/r30 絽吾腱糸綽荀code segment/ +function r1/r30cャ罧泣с +jump 膤≪祉綽荀r30阪r1帥 +篆罩cц祉綽荀 + +сr1_offset 祉域r30 * 阪 +? ! сc<鴻膂≦ +? code 翫 register_save 0 (ゃ障ゃ) +(障腥眼) + +Intel 翫c? (с緇с +core dump...) ebp <-----esp-----------> <------r1_offset------------------------------> @@ -2558,9 +2558,9 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -というわけなので、* にそろえる方が Intel 版とも一致する。 -ってことは、ebp の移動は Intel でもやっていたってこと? -いやfunctionではこうなっているんだけど、code では違う。 +с* 鴻 Intel 筝眼 +cebp 腱糸 Intel сcc? +functionсccode с ebp <-----esp-----------> @@ -2571,7 +2571,7 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -ってわけか。とすると powerpc では、 +c powerpc с r30 <------r1_offset------------------------------> r1 # * <------------lvar_offset-------> @@ -2580,23 +2580,23 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -の#にr30を固定してr1をずらすことになる。やっぱ、こっちだよね。 -zz はから。xx に、base となる関数呼び出しが来る。から、 -callee arg は破壊される。 - -どっちも可能だな。両方実装する? やっぱり後者からかな。gcc は -前者の方が簡単だろう。 - -入力変数をレジスタに割り振ってしまうと、その範囲では -簡単に動いてしまう。(そりゃ、そうだ...) - -goto with environment で構造体を返すのには注意が必要。 -どこでコピーする? goto した場所? return-continuation? -そうねぇ。return-continuation 側が普通でしょう。あぁ、 -でも返し先は元の関数呼び出しの引数上だから壊れちゃって -いるかもね。だから、とっておく実装の方が良いわけね。 - -(なんか -O3 にすると、mc1 が落ちるな...) +#r30阪r1c宴c< +zz xx base ∽医若喝冴ャ +callee arg 翫 + +c<純筝≧劫茖? c宴緇gcc +鴻膂≦ + +ュ紊違吾鴻帥蚊c障膀蚊с +膂≦障(...) + +goto with environment ф篏菴羈綽荀 +с潟若? goto 贋? return-continuation? +return-continuation 眼с +с菴∽医若喝冴綣遺紕<c +c鎘茖鴻 + +( -O3 mc1 純<...) Sat Mar 29 16:35:18 JST 2003 @@ -2607,23 +2607,23 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -このままだと、* が previous r1/r30 になるので、function から -goto する時に戻り番地やzzにあるはずのsaved r31/r30が破壊されて -しまう。それは、ちょっと困るということは、一旦、dummy subroutine -(普通はstub っていうか)を呼び出す方が良い? 戻り番地とprevious r1/r30 -は持ち歩いているわけだけど... また、r20-r29はつぶされてしまう -ので、前もってsaveする必要もある。f31-f20も。(結構多いな...) +障障* previous r1/r30 сfunction +goto 祉違zzsaved r31/r30翫 +障<c違筝dummy subroutine +(stub c)若喝冴鴻? 祉違previous r1/r30 +≧... 障r20-r29ゃ吟障 +сcsave綽荀f31-f20(腟罕紊...) # * r30 <--------------r1_offset-----------> r1 r+ +--+----------+----------+-----------+----------+----+ xx zz reg save !callee arg!code local caller arg xx r20-r29 -これだと environment は持ち運ぶ必要はない? いや、ある? -逆に戻り番地を持ち運ぶ必要はなくなるわけね。そっちの -方がきれいかな。goto-continuation みたいな感じか。 - -返り側は、 + environment ♂九荀? ? +祉違♂九荀c< +鴻goto-continuation 帥 + +菴眼 lwz r1,continuation lwz r1,0(r1) @@ -2632,8 +2632,8 @@ lmw r30,-8(r1) blr -程度で良い? このr30ってのはgoto先では知り得ない。いや、待てよ、 -この場合は、r20-r29って決まっているわけか。 +腮綺ц? r30cgotoсャ緇緇 +翫r20-r29c羆冴障c lwz r1,continuation set r3/f1 as a return value @@ -2643,12 +2643,12 @@ lmw r20,-148(r1) (?!) blr -で良いわけか。構文は同じでreturn addressは無視することにするか。 -呼出側は、 - - 通常の関数呼び出し (引数0) (は、手間0だから..) +ц罕return address∴ +弱阪眼 + + 絽吾∽医若喝冴 (綣0) (0..) bl L_stub_NN -L_return: (普通のretrunもあるから、必要な場合がある) +L_return: (retrun綽荀翫) lwz r1,0(r1) lwz r0,8(r1) mtlr r0 @@ -2666,13 +2666,13 @@ stw r0,8(r1) b saveFP+36 ; save f23-f31 -ちょっと複雑すぎるかな。特に gcc では、こういう操作は難しいかも。 - -あ、そうか。register saveは、このy関数が呼び出された時点で -やってしまえば良い。そうすれば必要ない。戻り番地も既に xx -に入っている。だよね。 - - * gotoを呼び出した関数のr1 ! r1(goto前のr1) +<c茲鴻 gcc с篏c + +register savey∽違若喝冴鴻 +c障域医荀祉違≪ xx +ャc + + * goto若喝冴∽違r1 ! r1(gotor1) # * r30<--r1_offset-------------> r1 r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -2680,33 +2680,33 @@ f20-f31 <-my_func_args--><--disp-----><-max_func_arg-> *size_of_int *size_of_int -とすれば stub は必要ない。cousin arg も保存されている。goto の -引数のみがlocal変数を上書きする形で格納される。これで、original -のIA32実装と一致することになる。(引数の保存を除いて。いや、 -元のも保存されているんじゃないの?) - -それで、code segment から関数呼出しするときは? (ってことは、 -それようのテストも必要なわけか...) + stub 綽荀cousin arg 篆絖goto +綣違帥local紊違筝吾綵≪ф主сoriginal +IA32絎茖筝眼(綣違篆絖ゃ +篆絖?) + +сcode segment ∽医弱冴? (c +鴻綽荀...) Wed Apr 2 17:40:32 JST 2003 -register 変数が既に使われていても、わざわざsaveする必要はない。 -戻って来ないから。register を使ったことにするには、used_max_register_var -を設定してやれば良い。 - -Intel版で goto が動かなくなったのは、arg_offset が、register 変数分 -も取るようになったから。save することを考えると、その方が良い。実際、 -function call があるとsaveされてしまう。ということは、別に r20-r29 -である必要はないってことか。通常のinput register varで良い。とすると、 -register変数をsaveする必要もないね。 -ただ、input register var は、function callの前には saveする必要が -ある。でも、これは、やっぱり手遅れか。ってことは、やっぱり、 -r20-r29が良いってことか。 - -jump() では、呼出し引数は、-arg_size つまり、局所変数と -同じ扱いになっている。ってことは、 - - * gotoを呼び出した関数のr1 ! r1(goto前のr1) +register 紊違≪篏帥save綽荀 +祉cャregister 篏帥cused_max_register_var +荐絎域 + +Intel goto carg_offset register 紊医 +csave 鴻絎 +function call save障ャ r20-r29 +с綽荀c絽吾input register varц +register紊違save綽荀 +input register var function call save綽荀 +сc宴cc宴 +r20-r29c + +jump() с弱冴綣違-arg_size ゃ障絮紊違 +宴cc + + * goto若喝冴∽違r1 ! r1(gotor1) # * r30<----r1_offset---------> r1 r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -2716,303 +2716,303 @@ r1 <----------------------r30 (return continuation) -で、callee arg は保存されたまま、code local だけ変わるってことだね。 - -return continuation で、構造体を返そうと思うと難しい。そもそも、 -浮動小数点が、ちゃんと返るのか? +сcallee arg 篆絖障障code local 紊c + +return continuation с罕篏菴c +羌絨亥鴻<菴? Thu Apr 3 13:47:23 JST 2003 -r1 は stack top に保存してあるものを、そのままenvironment -として渡すのが良い。 - -stack 上のデータが64kbyteなのは制限だが、やむをえまい。 - -というわけで、powerpc 版の CwC はできあがり。 - - return continuation での構造体の引渡し - function のprototypeでの重複した引数の省略 - -あたりが、まだ、テストしていない。あと、 - - 関数単位での構文木の作成 - 従来のフレーム構造の再利用バージョン - -も課題ではある。 +r1 stack top 篆絖障environment +羝< + +stack 筝若帥64kbyte狗障 + +сpowerpc CwC с + + return continuation с罕篏綣羝< + function prototypeс茲綣違 + +障鴻 + + ∽医篏с罕篏 + 緇ャ若罕若吾с + +茯臥с Fri Apr 4 10:41:22 JST 2003 -おいぉい、-O3 にすると、mc-codegen.c の arg_register は -r14 まで使うよ。それは、まずいんでないかい? 困ったなぁ。 +-O3 mc-codegen.c arg_register +r14 障т戎障с? 違c Mon Apr 7 14:29:51 JST 2003 -そういえば、unsigned char は処理してんの? crgvar はあるけど、 -curgvar とかはないみたいだけど。 - -あと、-1.0 とかが d2i とかを生成するのを直してないんでないかい? - -MIPS の比較命令は、 +違unsigned char ? crgvar +curgvar 帥 + +-1.0 d2i 眼с? + +MIPS 罸莠巡擦 beq $2,$3,$L18 slt $2,$2,$3 bne $2,$0,$L17 -という感じなわけね。(signed less than か?) - -だとすると今の方法ではうまくないかも。 - -PS2Linuxのアセンブラが低能すぎて、forward reference を全然 -解決してくれない。どうすりゃいいんだ? - -.include を使うと良いらしい。(そんなんでいいのか?!) - -csvalue() で取って来たregisterを誰がfreeするの? +(signed less than ?) + +篁号с障 + +PS2Linux≪祉潟篏純forward reference +茹f浦? + +.include 篏帥(с?!) + +csvalue() уcャregister茯違free? Tue Apr 8 14:52:06 JST 2003 -MIPSには bgez とか bgtz とかいう命令があるのね。なんかに -使えるの? 使えるけどさ。今のコンパイラで使う方法は? - -gccが浮動小数点レジスタを避けるようにコンパイルしている -のは何故だろう? 遅いから? jal dcmp とかは、やっぱり変。 - -double と float の差が良くわからない。 +MIPS bgez bgtz 巡擦 +篏帥? 篏帥篁潟潟ゃт戎号? + +gcc羌絨亥鴻吾鴻帥帥潟潟ゃ +篏? ? jal dcmp c宴紊 + +double float 綏 Wed Apr 9 16:20:00 JST 2003 -LOR LAND の定数の扱いを追加 - -配列の処理があるから、変数*定数ぐらいのh最適化は -入れた方が良いかも。その方がレジスタも少なく使うし。 -(また?) - -授業で使うように、また、最適化を落したものが必要かな。 - -MIPSの浮動小数点ってさ、single precision しか機械語命令が -ない? dpsub とかを呼び出すのっておかしくない? (まぁ、 -いいんだけどさ) +LOR LAND 絎違宴菴遵 + +紊*絎違h +ャ鴻鴻吾鴻帥絨鋎帥 +(障?) + +罐т戎障純綽荀 + +MIPS羌絨亥鴻csingle precision 罘罌域巡擦 +? dpsub 若喝冴c? (障 +) Fri Apr 11 14:36:33 JST 2003 -(二日酔だ...) - -要するに、 - 浮動小数点レジスタは single float しか使えない - double は、すべて、汎用レジスタに置き、計算はすべて、 subroutine -ってことだよね。(あ〜、やだやだ) - -single float だけでの演算を導入するためには、DSUBの他にFSUB -などを導入する必要がある。これは「うざい」。不可能じゃないけ -ど、かなりめんどくさいね。浮動小数点誤差の問題もあるし。全部 -double に変換してから計算すれば問題ないかと言うと、そんなこ -とはないわけだが。せめて、浮動小数点レジスタ上での演算をおこ -なうsubroutineはないの? (あるかも知れない) - -まぁなぁ。FCOMPとかやればいいだけなんだけど。 +(篋ラ...) + +荀 + 羌絨亥鴻吾鴻帥 single float 篏帥 + double 鴻羆吾鴻帥臀荐膊鴻 subroutine +c() + +single float с羲膊絨ャDSUB篁FSUB +絨ャ綽荀筝純 +羌絨亥壕ゅ勲馹 +double 紊荐膊医馹荐 +羌絨亥鴻吾鴻推с羲膊 +subroutine? (ャ) + +障FCOMP違 Sat Apr 12 13:30:07 JST 2003 -jal dpadd は、やっぱり、かなり複雑な浮動小数点演算だというが -わかった。IEEEの形式と合わないとかとかでそうなったんじゃなか -ろうか? もっとも、PlayStation に合わせてあるのかも知れないけ -ど。 - -ということで、single float 計算を入れないと、もとのgcc との -差が大きすぎるだろうと思う。ってことは、fmachineop とか FSUB -を入れないとだめってことか。まぁ、やれば、いいだけなんだけど、 -他のCPUとの調節がなぁ... - -今は、float の演算もpipeline上では1clockなんだろうから、 -できればdouble でやって欲しいけどね。とはいえ、double/float -の変換が不要になるので、float base だとMIPSの方が速い -ってことにはなるかも知れない。 - -gdb のdisass を見ると、jal bpadd とかは特定レジスタ -を使った間接代入になっているらしい。また、disass の -レジスタ表示が、 +jal dpadd c宴茲羌絨亥号膊 +cIEEE綵√сc +? cPlayStation ャ + + +сsingle float 荐膊ャgcc +綏紊сcfmachineop FSUB +ャc障違 +篁CPU茯睡... + +篁float 羲膊pipeline筝с1clock +сdouble сc罨蚊double/float +紊筝荀сfloat base MIPS鴻 +cャ + +gdb disass 荀jal bpadd 劫吾鴻 +篏帥c・篁eャc障disass +吾鴻粋;腓冴 $a0 $a2 $a3 $at $f0 $gp $ra $s0 $s1 $sp $t9 $zero $v1 $f12 $at -とかなので、よくわからん。こまったものだ。これも、 -ちょっと時間かかるのかな? - - -まぁ、なぁ... ANSI-C に従おうと思うと、このあたりのfloat/double -はうっとうしいよね。でも、とりあえず動けば良い? - -expr の引数として「output type」を入れるか? 基本的には assign -で決まるtypeを要求する。やっぱり、C の規格書がいるんだろうなぁ。 -(それは嫌だな...) CbC として、そういうものを入れるのが本当に -正しいの? (さぁねぇ...) +с障c +<c? + + +障... ANSI-C 緇float/double +cс域? + +expr 綣違output typeャ? 堺 assign +ф浦障type荀羆c宴C 荀惹吾 +(絆...) CbC ャ綵 +罩c? (...) float = float op float -は良いんだけど、 + double = float op float -の時に、必要な精度を確保できない。cast すれば良いんだけど、それは -ANSI-C とは異なる挙動になってしまう。ま、いいか。 - -MIPSはdouble=float ということにするっていう手もあるね。 -その方がきれいか。でも、どうせ、他のCPUもあることを考えると、 -fbinop するんじゃないの? lbinop も出さないとだめだろうし。 -short とかunsigned char の扱いもね。(sigh...) - -まぁ、時間の問題だから、やれば良いだけなんだけど。めんどい! - -(せめてdoubleのルーチンが浮動小数点レジスタを使ってくれれば -楽だったのに〜) +綽荀膕上墾腆坂сcast 域 +ANSI-C 違c障障 + +MIPSdouble=float c +鴻с篁CPU +fbinop ? lbinop 冴 +short unsigned char 宴(sigh...) + +障馹域! + +(double若潟羌絨亥鴻吾鴻帥篏帥c +罐純c) Mon Apr 14 23:29:37 JST 2003 -やっぱり、ちょっと変更大きいなぁ。 +c宴<c紊翫ぇ Fri May 2 14:53:16 JST 2003 -なんでもいいけど、power-pc の test/basic が通らなくなってる。 -(ま、そうだよな....) struct-pushと args-works の途中で -動かなくなったらしい。 - -あと、引数の引渡しだけど、printf (...) だけ特別扱いしたら? -プロトタイプがあるのを特別扱いする必要はないんじゃない? +сpower-pc test/basic c +(障....) struct-push args-works 筝 +c + +綣違綣羝<printf (...) 劫ユ宴? +帥ゃ劫ユ宴綽荀? Sat May 3 18:38:57 JST 2003 -わかりました。contains_in_list を修正するのを忘れているね。 -あと、get_register は、どうせ足りなくなるわけだろ? その -時はどうするの? 足りなくなるのは関数呼び出しの時だけ? -(かな?) - -だとすれば、関数呼び出しのsaveの変数を局所変数も使えるように -すれば良いだけだね。 +障contains_in_list 篆罩c綽 +get_register 莇潟? +? 莇潟∽医若喝冴? +(?) + +違∽医若喝冴save紊違絮紊違篏帥 +域 Sun May 4 09:18:32 JST 2003 -関数呼び出し時の浮動小数点を格納する、r8,r9 の扱いが -おかしい。 - -emit_push / tosop で局所変数だけは特別扱い -した方がいいんじゃない? register full だと、 - - register にload (emit_push) - register full でそれを局所変数に代入 (*) - 演算時にregisterに再代入 - -まぁねぇ。それだと、mc-code-386.c の時代に戻るわけ -だけど。まぁ、その方がいいのかな。もっとも、(*) -が起こらなければ、特に問題はないんだけどね。 - -局所変数、大域変数、定数の足し算とかは処理した方がいいのかなぁ。 +∽医若喝冴羌絨亥鴻主r8,r9 宴 + + +emit_push / tosop у紊違劫ユ宴 +鴻? register full + + register load (emit_push) + register full с絮紊違篁e (*) + 羲膊register篁e + +障mc-code-386.c 篁c祉 +障鴻c(*) +莎激違鴻馹 + +絮紊違紊у紊違絎違莇潟膊鴻 Sun May 4 15:10:48 JST 2003 -たぶん、oprt とかは、それほど効果は無いよ。効くのは、 -register full の時だけだろ? - -MIPS version は、まだまだ全然と言う感じ。ゆっくり -片付けて行くしかないね。 +吟oprt 祉号<鴻 +register full ? + +MIPS version 障障吟荐c +篁茵 Sun May 4 18:29:26 JST 2003 -d50 では、引数はレジスタに $4,$5,$6,$7 の double 二つしかのらない。 - -f50 では、引数は +d50 с綣違吾鴻帥 $4,$5,$6,$7 double 篋ゃ + +f50 с綣違 $f12,$f14,$6,$7 -というように4つ乗るらしい。(こまったもんだ...) - -i50では、$4,$5,$6,$7 だね。 - -あとはstackに積むみたいね。 - -これらを get_input_register_var で処理するわけか。 +4や(障c...) + +i50с$4,$5,$6,$7 + +stack腥帥 + + get_input_register_var у Mon May 5 15:28:07 JST 2003 -code_fconst/code_dconst と code_drgvar(e4,d,reg) みたいなのが -入混じってるな。ま、いいんだけど。 - -やっぱり、後者に統一。(めんどさ〜) free で d を指定するのはまずい。 +code_fconst/code_dconst code_drgvar(e4,d,reg) 帥 +ユ祁c障 + +c宴緇腟延() free d 絎障 Thu May 8 11:02:42 JST 2003 -regs/fregs の複数は必要ないんじゃないか? 一つで良い? 外から -は見えないから、mc-code-mips だけでそうするのが良い。 - -register のやり方を工夫しないとだめか。 - -あーめんどい.... 本当に動くのか? - -double のライブラリ呼び出しで$3,$4,$5,$6 を使うわけだけど、 -ここは必ずあけておかなければいけないわけだよね。でも、実際に -は、ライブラリの呼び出し後には$3,$4 が使われてしまう。ここで、 -emit_push されると気まずいが... - -本当のfunction callと同じ扱いでもいいんだけど、それだと -ちょっときつくない? - -なんか浮動小数点レジスタ変数へのdpreinc/dpostinc を定義して -ないんじゃない? それは、まずいんじゃないの? dassop もそうか? -あれ? なんか何もしてないみたいだな。Intel 版にはレジスタ変数 -がないから、テストしなかったのか。code の引数はレジスタに割 -り当てられるから、そのあたりでテストすることは可能だろうね。 -まぁ、これ自体は難しくはないが... - -code segment では浮動小数点レジスタに割り振られてしまうので、 -実はエラーが出ていたんじゃないかな。これはテストプログラム -を書くべきでしょうね。 - -あるいは#define REG register でテストする必要があるわけね。 - -MIPSでは、$4,$5,$6,$7 は、本当に特別扱いしないとだめだね。 +regs/fregs 茲違綽荀? 筝ゃц? 紊 +荀mc-code-mips с + +register 鴻綏ュか + +若.... 綵? + +double ゃ若喝冴$3,$4,$5,$6 篏帥 +綽違с絎 +ゃ若喝冴緇$3,$4 篏帥障с +emit_push 羂障... + +綵function call宴с +<cゃ? + +羌絨亥鴻吾鴻水違吾dpreinc/dpostinc 絎臂 +? 障? dassop ? +? 篏帥Intel 吾鴻水 +鴻ccode 綣違吾鴻帥 +綵с鴻純 +障篏c... + +code segment с羌絨亥鴻吾鴻帥蚊障с +絎若冴鴻違 +吾鴻с + +#define REG register с鴻綽荀 + +MIPSс$4,$5,$6,$7 綵劫ユ宴 Thu May 15 21:25:45 JST 2003 -fregv は、やっぱりサブルーチン・コールにするんだろ? -(さすがに授業が始まってしまうと、なかなか進まない...) +fregv c宴泣若潟祉潟若? +(罐紮障c障蚊障...) Sat May 17 13:57:12 JST 2003 -$4,$5 を常に creg または、double のfregとして使う。 -$f12 はfloating 用。 - -もちろん、emit_pushすればずれちゃうけどね。rename するべきか? -そもそもrenameは必要ないんじゃないの? - -あともう少しなんだけどねぇ。やる気がでん... +$4,$5 絽吾 creg 障double freg篏帥 +$f12 floating + +<emit_push違<rename 鴻? +rename綽荀? + +絨羂с... Tue May 20 11:08:44 JST 2003 -freg と同じように dreg を作る? (そうすると ia32 -の書き直しがあるが、それは良いとして...) - -でも、mc-codegen.c が creg/freg に依存しているから、 -それを書き直すのが結構めんどくさい。書き直して -大丈夫なのか? ううーん... - -逆にcreg/dreg/freg を無くすってのは? 全部、creg で -やるわけだな。ちょっと書き直しが多いけど。原理的には -それでいいはずだけど。着目しているcurrent register -は一つのはずだから。 +freg dreg 篏? ( ia32 +吾眼...) + +сmc-codegen.c creg/freg 箴絖 +吾眼腟罕吾眼 +紊т紊? 若... + +creg/dreg/freg <c? creg +<c吾眼紊 +сcurrent register +筝ゃ (1) creg int freg double/float -ってなっているからおかしいのであって、 +ccсc (2) creg int/double/float -か、 + (3) creg int freg double greg float -だよねぇ。 - -やっぱり(2)かなぁ。long long のことをとかを考えると。 -でも、とりあえず(1)でやるか。 - -いずれにせよ、fregv を追放することからはじめるんじゃない? - -それはできました。 + + +c宴(2)long long +с(1)с + +fregv 菴醇障? + +с障 Thu May 22 23:40:13 JST 2003 @@ -3027,198 +3027,198 @@ 3815 macrop = macro_function(macrop,&body,nptrm, 3816 list2((int)macro,history)); -MACRO の場合のrecursive な処理を忘れいているみたいだけど。 -それでも良かったはずなんだけど、macro_buf がstatic なので -不都合が出ているみたいね。 - -recursive に処理すると、 +MACRO 翫recursive 綽帥 +сcmacro_buf static +筝遵冴帥 + +recursive #deifne car(e) heap[e] car(e) -みたいな時にまずい。これは、どうするんだっけ? - -LMACRO ってのがあったみたいね。 +帥障c? + +LMACRO cc帥 Sun May 25 21:48:46 JST 2003 -macro_eval がまだおかしいのは置いといて... - -単純にcreg/fregを統一してしまうと、 - fdecl で creg をセット -した時に、float/double/int にどれかに固定される。そのまま、 -coce_rlvar(creg) とかを呼ばれてしまうので、ちょっと困る。 -code_rlvar で、if(!is_int_reg(creg)) creg = ireg; -とかすればいいんだけど、それは、ちょっと変だよね? - -そもそも、mc-codgen.c でcregを持ち歩いている理由は? -なんかあったような気がするが... - -そうか、 +macro_eval 障臀... + +膣creg/freg腟延障 + fdecl creg 祉 +float/double/int 阪障障 +coce_rlvar(creg) 若違障с<c違 +code_rlvar сif(!is_int_reg(creg)) creg = ireg; +違<c紊? + +mc-codgen.c creg≧宴? +c羂... + + use_int_reg() -とかしてやれば良いわけね。(rname を使うかどうかはともかく) - -code_rlvar とかで設定するregisterを勝手に変えられると -うれしくない。(よね?) codegen 側で use_int_reg()とか -できればいいんじゃないの? +域(rname 篏帥) + +code_rlvar ц┃絎register紊 +(?) codegen 眼 use_int_reg() +с違? Mon May 26 21:06:14 JST 2003 -code_* 側でやるか、mc-codegen 側で行うか? どっちかなぁ。 -code_* 側の方が良いような気もするけど。 +code_* 眼сmc-codegen 眼ц? c< +code_* 眼鴻羂 Thu May 29 10:30:09 JST 2003 -freg/creg の区別は mc-codegen 側でやっていたんだから、 -mc-codegen 側でやらないと、mc-cdoe-* 側での動的 -チェックが増えすぎてしまう。 - -creg/freg を共有するのは良いのだが、その設定は -mc-codegen 側ですべきなんじゃないの? - -mc-code-* 側を修正するとバグが取り切れない... -(といいつつ、もう、すぐなんだろうけど... でも、なぁ) - -cast を自分で定義できる言語なら簡単なんだろうけど。 +freg/creg 阪ャ mc-codegen 眼сc +mc-codegen 眼сmc-cdoe-* 眼с +с紜障 + +creg/freg 掩荐絎 +mc-codegen 眼с鴻? + +mc-code-* 眼篆罩c違... +(ゃゃ... с) + +cast у臂с荐茯膂≦ Tue Jun 3 13:03:41 JST 2003 -あぁ、なんか乗り切れない。CONV の直前でcregが不定だ。 -どっかで use_float を忘れているんだろうな。 +箙CONV 翫creg筝絎 +c use_float 綽 Wed Jun 11 12:27:58 JST 2003 -なんか、ようやっと creg/ireg/freg が片付いたよ。 -creg を変更したときに、ireg を変更し忘れることが多かった -みたい。set_creg を必ず使うようにすれば良いだけだと思う -のだが。 +c creg/ireg/freg 篁 +creg 紊眼ireg 紊眼綽紊c +帥set_creg 綽篏帥域 + Thu Jun 12 19:34:48 JST 2003 -まぁ、MIPS用のレジスタ割り当てを書かないとだめだね。 -ちゃんと書いてもいいんだけどさ。なんか one path に -するのが面白いんでしょ? +障MIPS吾鴻水蚊綵吾 +<吾 one path +∝純с? Sun Jul 13 18:26:29 JST 2003 -また、一カ月なにも書かなかったのか。 mips は、mc-code-power.c -から書き直した方が良さそうだね。 - - regs/regv は、i/f/d のすべてのレジスタに関して一つ - -でないと stack に積むのを統一できないから。そういう意味では、 -reg_stack と freg_stack を区別する意味はないわけね。でもstack -は型付けした方が良いから。でも、区別しておくと、long を増や -した時にも、stack を増やさないとだめなんじゃない? なので区別 -しない方が良い。でも、それに手をつけると、また時間かかるんじ -ゃないの? そのためにはスタックそのものに型付けしないとだめだ -から結局同じか。 - -mips の double を格納するためのregister pairは、regs に -格納する。regs にアクセスには必ずアクセス関数を通す。 -なるほど。 - -get_input_dregister_var なんだけど、dregister pair の -場合は、常にpairが決まった値になる必要があるよね。 -この分はどうする? 前もってとっておくか? - -あ、そうか、任意のregister pairを許さなくても良いよ。input register -に対応する連続したregister pair だけを許そう。そうすれば、あ -まり気にしなくても良くなるから。でも、gcc が奇数pairを許して -いたら気まずくない? - -regv は、register rename がなければいらないんじゃない? +障筝吾c mips mc-code-power.c +吾眼鴻 + + regs/regv i/f/d 鴻吾鴻帥≪筝 + +с stack 腥腟延с潟с +reg_stack freg_stack 阪ャ潟сstack +篁鴻с阪ャlong 紜 +stack 紜? у阪 +鴻сゃ障 +? 鴻帥篁 +腟絮 + +mips double 主register pairregs +主regs ≪祉鴻綽≪祉拷∽違 +祉 + +get_input_dregister_var dregister pair +翫絽吾pair羆冴障cゃ綽荀 +? cc? + +篁紙register pair荐宴input register +絲上gregister pair 荐宴違 +障羂сgcc 絅pair荐宴 +羂障? + +regv register rename 違? Mon Jul 14 10:54:46 JST 2003 -なんかなぁ... creg/ireg/freg/dreg は、あんまり良いアイデア -では、なかったみたい。creg は、このうちのどれかでなくては -ならないんだが、それを保証できない。 - -前と同じで、creg を廃止して、ireg/freg/dreg/lreg とするか? +... creg/ireg/freg/dreg 障≪ゃ +сc帥creg <с +篆荐若с + +сcreg 綮罩≪ireg/freg/dreg/lreg ? Mon Jul 14 14:25:23 JST 2003 -なんか unsigned が通らなくなっているみたい。 + unsigned c帥 Sun Jul 20 17:37:34 JST 2003 -やっぱり dictionary は、書き直さないとだめだよな。 -それに関して、heap も修正した方が良い。このコード -はあんまりだものなぁ。 - -さて、あとは、オフセットだけど... めんど... +c宴 dictionary 吾眼 +≪heap 篆罩c鴻潟若 +障 + +祉... ... Mon Jul 21 15:12:56 JST 2003 -Frame pointer は使うの? 使った方がいいんじゃない? -PowerPC は使わなかったけど。 +Frame pointer 篏帥? 篏帥c鴻? +PowerPC 篏帥c Tue Jul 22 08:12:48 JST 2003 -switch 文をtableにコンパイルするには... - -最初の比較の行き先を後で指定するようにする +switch table潟潟ゃ... + +罸莠茵緇ф絎 cmp reg,case_value bne L_NEXT .... L_NEXT: -を、 + cmp reg,case_value bne L_CASE .... L_NEXT: .... L_CASE -で、case 文が終ったらtableを作る。table がいらないようだったら、 +сcase 腟ctable篏table c L_CASE = L_NEXT -各caseの入口は覚えておく。 +caseュc荀 (list of (value, label)) -table は、どうやって作るかと言うと、 - - まず、値の分布をチェックする - 密度の高い表を作る(端のいくつかを除いて連続していること) - というか、(定差分で)連続している部分にだけ表を作れば良いか。 - table は8entry以上。それ以下は、2分法に負ける。 +table c篏荐 + + 障ゃ絽с + 絲綺蕭茵篏(腴ゃゃg) + (絎綏)g茵篏域 + table 8entry篁ヤ篁ヤ2羈莢 (list of (number of entry, diff, (list of (value,label)))) -512 or 128kbyte まで容認する。限度はなくても良いか。連続している -部分にしか表は作らない。 - -連続してない部分は、2分法にする。 - -2 分法でもいいけど。2分法にする? その方が簡単かな。最後のス -テージは、(順序が一致していれば...) 元のコードが使えるし。そ -うすると、sort して、真中かから比較して行けば良い。そうすれ -ば表の分布とか考えなくても良いからいいかもね。 - -簡単じゃん。 - -まぁ、やっぱり、構文木の先読みをするんじゃないの? そうすれば -reference のとられてない変数もわかるし。 +512 or 128kbyte 障у壕綺g +茵篏 + +g2羈 + +2 羈с2羈? 鴻膂≦緇 +若吾(綺筝眼...) 潟若篏帥 +sort 筝罸莠茵域 +域;絽 + +膂≦ + +障c宴罕茯帥? +reference 紊違 Wed Jul 23 16:21:12 JST 2003 -やっぱり構造体のタグの名前はname tableにいれちゃだめだね。 -まぁ、いれなきゃいけないんだけどさ。どうする? -どうするっていっても... +c宴罕篏帥違name table< +障? +cc... Thu Jul 31 15:07:08 JST 2003 -C から変換したコードは動いたけど。まぁ、cast は動くのは -良いんだけど、こういうのじゃなくて、link を使った変換 -でもいいんじゃない? そうすれば、spaghetti stack でもOk -だな。ただ、GC がないと使い物にならないだろうが。 - -Link にすれば、型整合のある変換も可能だよね。ただ、union -は意味ないか。record 型に直さないとね、 - -recursion と loop をdetect すれば、static にcompile -できる。あるいは、recursion の部分だけ配列にできる -んじゃないかな。 - -それぞれの利点と欠点を考察すればCWは通るんじゃない? -(本気?) +C 紊潟若障cast +link 篏帥c紊 +с? 違spaghetti stack сOk +GC 篏帥 + +Link 違翫紊純union +潟record 眼 + +recursion loop detect 違static compile +сrecursion с + + +鴻罨鴻絲CW? +(羂?) Mon Aug 4 12:48:40 JST 2003 @@ -3229,11 +3229,11 @@ 480 6.590u 0.000s 0:06.67 98.8% 0+0k 0+0io 0pf+0w -だいたい10%ぐらい遅いなぁ。(なんで?) げ、-O6 だと十倍違う... - -げ、powerpc の subroutine 内のstaticが通らんじゃん。 - -サブルーチンを三段に直しました。 +10%(?) -O6 ... + +powerpc subroutine static + +泣若潟筝罧泣眼障 % time ./a.out 0 720 @@ -3261,11 +3261,11 @@ 3.520u 0.010s 0:03.55 99.4% 0+0k 0+0io 0pf+0w % -ま、こんなものかな。-O2 に負けるなよって気もするが。 - -琉大は40Mbps - -Intel PC (on PowerPC) の場合 +障-O2 莢c羂 + +紊с40Mbps + +Intel PC (on PowerPC) 翫 [root@localhost ~/device]# time ./a.out 2 470 @@ -3293,23 +3293,23 @@ 0.850u 0.020s 0:00.88 98.8% 0+0k 0+0io 92pf+0w [root@localhost ~/device]# -PowerPC の場合は、PIC symbol がやっぱり遅いね。 -こいつをなんとかするだけでだいぶ違うかも知れない。 +PowerPC 翫PIC symbol c宴 +ゃс狗ャ Tue Aug 5 13:53:43 JST 2003 -む、なんか、もう、そうなってるじゃん。 - -関数scope 内の staticの初期化が通らないんですけど。 - -直りました。対応してなかったみたいね。 +c + +∽scope staticс + +眼障絲上c帥 Wed Aug 6 12:07:07 JST 2003 [kono@pw001 ~/device]% ./mc -s test/conv1.c [kono@pw001 ~/device]% gcc test/conv1.s [kono@pw001 ~/device]% time ./a.out 1 -セグメントエラー (coreを出力しました) +祉違<潟 (core阪障) 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w [kono@pw001 ~/device]% time ./a.out 2 470 @@ -3318,7 +3318,7 @@ 720 0.650u 0.010s 0:00.65 101.5% 0+0k 0+0io 88pf+0w [kono@pw001 ~/device]% time ./a.out 1 -セグメントエラー (coreを出力しました) +祉違<潟 (core阪障) 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w [kono@pw001 ~/device]% time ./a.out 2 470 @@ -3332,7 +3332,7 @@ 720 0.660u 0.000s 0:00.65 101.5% 0+0k 0+0io 88pf+0w [kono@pw001 ~/device]% time ./a.out 1 -セグメントエラー (coreを出力しました) +祉違<潟 (core阪障) 0.010u 0.000s 0:00.00 0.0% 0+0k 0+0io 73pf+0w [kono@pw001 ~/device]% time ./a.out 2 470 @@ -3363,7 +3363,7 @@ Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.3/specs gcc version 2.95.3 20010315 (release) -Intel Architecture だと、結構、良い線いっているみたい。 +Intel Architecture 腟罕膩c帥 Thu Aug 14 02:39:29 JST 2003 @@ -3412,186 +3412,186 @@ Mon Sep 1 13:49:43 JST 2003 -short がやっぱり欲しいよね。long long はともかく... -そこまでいくと、ANSI-C 対応にできるんだが。long long -は難しい? - -short は、そんなに難しくないはず。あとは、 - statement を含めたtreeの処理 - 変換系の完成 -この二つだな。GCC に組み込むのは無理だろう。 - -属性文法みたいな手法が使えればね。 - -あと、struct のtag。やっぱりword table を作り直さないと。 +short c宴罨蚊long long ... +障сANSI-C 絲上сlong long +c? + +short c + statement tree + 紊膤祉絎 +篋ゃGCC 腟粋昭∞ + +絮ф羈帥羈篏帥違 + +struct tagc宴word table 篏眼 Wed Sep 10 21:53:16 JST 2003 -short や unsigned short の前に、 -なんか unsigned char もないんですけど。 +short unsigned short + unsigned char с Wed Oct 8 22:43:17 JST 2003 -(また、一カ月、触ってないのか...) - -無名 code はあった方がいいんじゃない? +(障筝茹c...) + +≦ code c鴻? code *a(int i); a = code(int j) { } -みたいな感じ? C にはないけどね。もともと、名前を消費する -方だからあった方がいいかも。でも、実行時に作られるわけじゃない。 -それに、こういうものを作ると closure だと思われるような -気もする。closure みたいなものは「自分で管理する」ってのが -CbC の思想だろ? - -そういえば、static なcodeはあった方がいいんじゃない? +帥? C 羔莢祉 +鴻c鴻с絎茵篏 +篏 closure +羂closure 帥х∞c +CbC 潟? + +違static codec鴻? static code func() { .... } -か。それはそうだな。 + Fri Oct 10 13:08:01 JST 2003 -link register をうまく使うにはcontinuationに -指定するだけではダメで、 +link register 障鋎帥continuation +絎с<с goto hoge(....,next); code next.. -みたいなのがあった方がいいんじゃない? - -goto の後のステートメントは無名codeになればいいんだよね。 - -stack を使わないサブルーチンみたいなものか。単なるcall -になるわけね。それもいいかも。 +帥c鴻? + +goto 緇鴻若<潟≦code違 + +stack 篏帥泣若潟帥call + Sat Nov 22 15:51:36 JST 2003 -構造体のfieldの定義のnptrは、大域の名前テーブルから -取り除かないといけない。でも、取り除いていしまうと、 -構造体からのポインタがずれちゃうので、まずい。 - -filed専用の領域を作るのだと、複数の構造体が同じ -field名を持つときにちょっと困る。構造体のタイプに -埋め込むのがいいんだけど... - -そうすると、構造体のfiledかどうかをgetsymがチェック -するときにちょっと困る。 - -filed をlinear searchするのは嫌だけど、しかたないか。 - -なんか、struct の中に、 +罕篏field絎臂nptr紊у若 +ゃсゃ障 +罕篏ゃ潟帥<с障 + +filed絨篏茲違罕篏 +fieldゃ<c違罕篏帥ゃ +莨若... + +罕篏filedgetsymс +<c違 + +filed linear search絆 + +struct 筝 void (*case_)(int cases,int def); -とかがあると、 + void (*case_)(); int cases; int def; -という感じで余計なfieldが定義されてるみたい。 - -adecl で nptr が引数の最後を指してしまうのがまずかった。 +т荐field絎臂帥 + +adecl nptr 綣違緇障障c Mon Nov 24 00:52:31 JST 2003 -signed char は実装しましたが... test routine がない。 - -あと、short は、code_crxxxx の中でbyteの大きさに従って -処理するのがいいかな。 +signed char 絎茖障... test routine + +short code_crxxxx 筝byte紊с緇c + Mon Nov 24 10:53:31 JST 2003 -short も実装したけど、まだ、コンパイルは通らない。 - -そろそろ stdio.h を通さないとダメだね。(いろいろあるだろうなぁ...) -とりあえず、#include <> をなんとかしないと。 - -long long の演算はともかく long long の代入はできた方がいい -か。でも、それなら、構造体の定義でいいんじゃない? +short 絎茖障潟潟ゃ + + stdio.h <(...) +#include <> + +long long 羲膊 long long 篁eャс鴻 +с罕篏絎臂с? typedef struct { char a[4]; } long long -みたいな感じ? それはできないが、コンパイラ内部ではそうするという -手もある。 +帥? с潟潟ゃс + Mon Nov 24 18:59:30 JST 2003 -うーん、こんなエラー残っているのか。code_cpostint とか -はぜんぜん使われないわけ? - -struct { char a[4],a; } は直しました。 - -short の引数の扱いも修正。 +若惹ccode_cpostint +篏帥? + +struct { char a[4],a; } 眼障 + +short 綣違宴篆罩c Mon Nov 24 22:20:29 JST 2003 -同じレジスタをずーっと使わずにstatementごとに -ずらすと、ちょっと速くなるかもね。どうなんだろう? -rename されちゃえばあんまり関係ないのかも知れないけど。 - -二つのレジスタを交互に使うとかだと、まぁ、誤差ですね。 +吾鴻帥若c篏帥statement +<c? +rename <違障≫ャ + +篋ゃ吾鴻帥篋や篏帥障茯ゅ勲с Wed Nov 26 13:27:00 JST 2003 -include path は内蔵のものと、外部のものと二ついるわけね。 - -predefined が結構無いといけないみたい。 - -にゃ〜 inline は必須なの? macro で実装するのは難しいんじゃないかなぁ。 -inline には、結構、いろんな変な部分があるんだよな。一旦はコンパイル -しないといけないはずだし。 +include path 泣紊篋ゃ + +predefined 腟罕<帥 + + inline 綽? macro у茖c +inline 腟罕紊筝潟潟ゃ + inline int f(int a,int b) { int c; c = a+b; return c; } -だよね。 + f(3,4) -があった時には、 - int _c,int _a,int _b; をlocal変数に付け加える +c + int _c,int _a,int _b; local紊違篁 _a = 3; _b = 4; _c = _a+_b; -をコンパイル。 +潟潟ゃ current register = _c -とする。かなぁ。 - -むしろ、 + + + c = { decl; statements* return value; } -を実装して、#define を拡張する -方が簡単じゃない? そのためには nest したdecl を扱わないと -だめだけど... - -いや、やっぱり、中間木をなんとかするのかなぁ。 - -とりあえず、無視。普通の関数(static)としてcompileする。 - -やっぱり、long long はいるのね〜 - -やっぱり、enum もいるよね〜 - -なんか、知らないけど、やっぱり全部実装しないとだめなのね。 - -あと、const int かな。 +絎茖#define ≦宍 +鴻膂≦? nest decl 宴 +... + +c宴筝 + +∴∽(static)compile + +c宴long long + +c宴enum + +ャc宴絎茖 + +const int Fri Nov 28 14:01:25 JST 2003 -volatile ... (なにすればいいんだろう?) - -なんか、*.c 以外だとソースを上書きしちゃうんじゃ... - (これは直しました) - -うーん、struct のtagとtype名を一緒にされちゃうのか... -こういうことをされると変数テーブルを直さないと動かせない... -TYPE_TAG みたいなアドホックなどだと直せない。 -なんとかなんないかなぁ。 - -あと、struct のforward definition ってのがあるみたいね。 - -#if defined(A) && A で、後ろが評価されちゃうみたいだけど。そ -うすると後ろの名前がdefineされてしまう。ふーむ。こんなのどう -やって防げばいいんだ? - -やっぱりlong long を64bit にしないとファイルサイズが -合わない。 - -やっぱり include は、そのファイルのある場所から読み込む -性質があるのか。 +volatile ... (違?) + +*.c 篁ュ純若鴻筝吾<... + (眼障) + +若struct tagtype筝膩<... +紊違若眼... +TYPE_TAG 帥≪眼 + + +struct forward definition c帥 + +#if defined(A) && A с緇荅箴<<帥 +緇define障泣若 +c蚊違? + +c宴long long 64bit <ゃ泣ゃ冴 + + +c宴 include <ゃ贋茯粋昭 +ц蟹 Sat Nov 29 19:01:26 JST 2003 @@ -3600,40 +3600,40 @@ REGS_SAVED_ALL /* All registers */ } regs_saved_t; -やっぱり、あるのね。 +c宴 void (*signal ()) (int); -が動かなくなってます。 +c障 Sun Nov 30 05:30:56 JST 2003 -ようやっと <stdlib.h> が通った。 - -nkf.c が while() { int hoge;... } を使っているのは、変。 -なんで、こういうことするかなぁ。これをサポートするのは -不可能ではないけど、いろいろ手直しがいる。 - -なんか、少し早めに n->sc が定義されちゃって、変な -ことが起きているみたいだね。 - -stat の関数名とtag名が重なっているみたい。やっぱり -tag名の名前空間をわけないとだめかぁ... +c <stdlib.h> c + +nkf.c while() { int hoge;... } 篏帥c紊 +с泣若 +筝純с眼 + +絨 n->sc 絎臂<c紊 +莎激帥 + +stat ∽医tagc帥c宴 +tag腥咲... Sun Nov 30 17:41:04 JST 2003 -マクロを登録するときには、コメントをとらないとだめ。 - -while のslfree でマクロのchptrsave が破壊されてしまう。 - -やっぱり、nkf.c は、一発では動かないみたいね。compile は -できたけどさ。 - - >> は符号依存 テストルーチンが入ってなかった - -うーん、K&Rの引数の順序が関数の引数とずれているときは、 -関数の順序の方を優先しないといけない... う、うーん。 +脂蚊潟<潟 + +while slfree сchptrsave 翫障 + +c宴nkf.c 筝冴с帥compile +с + + >> 膃垬絖 鴻若潟ャcc + +若K&R綣違綺∽違綣違 +∽違綺鴻... 若 { extern hoge... @@ -3643,15 +3643,15 @@ h_conv(f, c2, c1) FILE *f; int c1, c2; -まぁ、いろいろあるねぇ。 +障 #define hex(c) (('0'<=c&&c<='9')?(c-'0'):\ ('A'<=c&&c<='F')?(c-'A'+10):('a'<=c&&c<='f')?(c-'a'+10):0) fprintf(stderr,"mime_getc h: %d c2 %d c3 %d\n",((hex(c2)<<4) + hex(c3)),c2,c3); return ((hex(c2)<<4) + hex(c3)); -ふむ。(?::)+(?::) みたいな時には、code-set-fixed-register のregister -が二ついるわけね。push できないの? +泣(?::)+(?::) 帥code-set-fixed-register register +篋ゃpush с? case COND: /* a?0:1 should consider non-branch instruction */ case DCOND: @@ -3669,17 +3669,17 @@ else emit_dpop_free(emit_dpop(d),d); return t; -は、あんまり良くない。register machine ならいいんだけど。 -結構、実装が変わるから、code-$(ARCH) に移した方がいいかな。 - - -なんか、arg_reording() が、 +障register machine +腟罕絎茖紊code-$(ARCH) 腱祉鴻 + + +arg_reording() PowerPC fnptr->dsp = arg_reorder(reverse0(sarg),reverse0(fnptr->dsp)); IA32 fnptr->dsp = arg_reorder(sarg,fnptr->dsp); -ということになっているみたい。おんなじ順序じゃないのね。どうしようかな。 -これは、わかりました。 +c帥綺 +障 case COND: /* a?0:1 should consider non-branch instruction */ case DCOND: @@ -3696,15 +3696,15 @@ fwddef(e3); return d; -なんだけど、t のcregが、ia32 ではvirtual register なので、変更される -ことがある。(こまったもんだね) - -CONDには type をいれた方がいいみたいね。a?b:c type でlist5か。 +t cregia32 сvirtual register с紊眼 +(障c) + +COND type 鴻帥a?b:c type list5 void (*signal ()) (int); -これだと signal が二回 function だと思われる。 + signal 篋 function recursive macro #define stdout stdout @@ -3713,31 +3713,31 @@ { register double d; int i = stdout; - d *= i; register float への assop + d *= i; register float 吾 assop return (int)d; } -というわけで、nkf は system の/usr/include/stdio.h で動きました。 -なんか、うれしい。 - -ptr_cache のmr は確かに無駄だけど... 保留してまで取り除く -価値はないんじゃないかな。でも32bitとってるかならなぁ。 -lvar cache みたいなものも面白いけど。まぁ、そこまで -やるなら、レジスタの寿命とか見ればいいんだよな。。。 +сnkf system /usr/include/stdio.h у障 + + +ptr_cache mr 腆冴♂... 篆障уゃ +箴≦ゃс32bitc +lvar cache 帥∝純障障 +吾鴻帥絲水純荀違 Wed Dec 3 13:11:15 JST 2003 -スレッドとの相性 -っていうか、こいつをthread libraryとして使うにはどうすればいいの? - env と return を生成する? - -構文的に別にした方が安全だけど。 +鴻御 +cゃthread library篏帥違? + env return ? + +罕ャ鴻絎 Sun Dec 14 16:26:19 JST 2003 -long long やるの? 割算はサブルーチン呼び出しみたいね - -float/double から long long, unsigned long long への変換もいるのか。 +long long ? 牙泣若喝若喝冴帥 + +float/double long long, unsigned long long 吾紊 F2LL D2LL F2ULL @@ -3746,75 +3746,75 @@ LL2D ULL2F ULL2D -かぁ。(めんどくさいだけどさ) - -(本気? どれくらいかかる? 2-3日かなぁ...) - (実際には半年かかった...) - -getsym の数字の扱いはunsignedでするべきだよね。 -で、- があった時にoverflow を検出するのが良いよな。 - -あと、strol とかのoverflowの検出をさぼってるな。 +() + +(羂? ? 2-3ャ...) + (絎綛眼c...) + +getsym 医宴unsignedс鴻 +с- coverflow 罎冴 + +strol overflow罎冴若c Fri Jan 2 09:53:53 JST 2004 goto hoge(...,next); fuagua....; -みたいな構文をいれる? Fortran みたい.... -(簡単か?) +帥罕? Fortran 帥.... +(膂≦?) Sat Jan 3 17:12:46 JST 2004 FEATURE_LONGLONG FEATURE_FLOAT -みたいな感じで feature を落せる方が良い? 機能を増やす方向 -とは相性が良くない言語だから。 - -LEとかLTは、GE,GTで置き換えられるんだけど、片方が定数のときには -dual_op で入れ換えられちゃうので、やっぱり必要なみたい。 +帥 feature 純鴻? 罘純紜劫 +御с荐茯 + +LELTGE,GTх舟鴻絎違 +dual_op уャ<сc宴綽荀帥 Mon Jan 5 15:55:37 JST 2004 -byte code format というよりは、やっぱりbyte code encode -された構文木が欲しいんだよね。 - -ついでに interpreter も作るか。byte code interpreter ではなくて、 -(ではなくて?) code 生成が速いんだから、code生成しながら実行する -方が良いね。やっぱり、incore compiler か。 - -inline なんだけど... #define に置き換えられる? +byte code format c宴byte code encode +罕罨蚊 + +ゃс interpreter 篏byte code interpreter с +(с?) code code絎茵 +鴻c宴incore compiler + +inline ... #define 臀? inline int hoge(int hoga1) { hoge2 } -は、 + #define hoge(hoga1_0) { #define hoga1 ((int) hoga1_0) int hoga1 = hoga1_0; hoge2 } -でいいわけだよね。で、問題は return だけど... - -うーん、いま6ですな。 - -inline は、そのままstringバッファにしこんで、関数呼び出し時に -処理する方が正しいか。 - - 引数は、#define hoga1 ((int) hoga1_0) していく。 - 展開終了時に元に戻す - -あぁ、でも、大域変数がまずいか。 - -ということは、やっぱり、その場で構文解析してしまうのが良い。 +сс馹 return ... + +若6с + +inline 障string<с∽医若喝冴 +鴻罩c + + 綣違#define hoga1 ((int) hoga1_0) + 絮腟篋祉 + +с紊у紊違障 + +c宴眼ф茹f障 inlined LVAR (ARG) -の両方が必要。tree のコピーなしに展開することは可能? (できそうだけど...) - -ということは、やっぱり、制御構造にもnodeを割り振るべきだよね。 +筝≧鴻綽荀tree 潟若絮? (с...) + +c宴九勝罕node蚊鴻 order 1 compiler + JIT + intensive optimizer -ですかね。 +с Wed Jan 14 10:21:49 CET 2004 -function callを compiler の外に出せないかなぁ。 +function call compiler 紊冴 code function_interface(args) { ..... push(args); (in asm) @@ -3823,58 +3823,58 @@ } code function_continuation(args) { } -みたいな感じで... ま、遅くなるだろうけど... - -でも、そうすれば、コンパイラの移植は比較的簡単になる。 +帥... 障... + +с違潟潟ゃ腱紙罸莠膂≦ Thu Jan 15 11:52:03 CET 2004 -stack は、 - system wide に一つ ( classical environment) - code に一つ ( Fortran type ) - object に一つ (like message buffer in ABCL) -っていう選択もあるね。 +stack + system wide 筝 ( classical environment) + code 筝 ( Fortran type ) + object 筝 (like message buffer in ABCL) +c御 Sun Jan 18 11:08:13 JST 2004 -(なんか、遅すぎなんだよね... CPS 変換か...) - -shift/reset をCで実装するのは簡単だが... +(... CPS 紊...) + +shift/reset Cу茖膂≦... reset{ shift(); } -みたいな感じ? - -stack / data structure の保護の方法に、もっと何かがあるんじゃ -ないかな。 - -関数呼び出しなんだけど... - -apply みたいなのがあればいい? +帥? + +stack / data structure 篆茘激号c篏 + + +∽医若喝冴... + +apply 帥違? goto apply(function_name,continuation(return_type),args....); -かな。で、この部分を、C/asm で書くというわけね。 -ま、おんなじようなものか。(何と?) この部分だけ interpreter 的に -なっちゃうな。varargs でもいいんだけど... - -コンパイラをCbCで書くと言う作業が残っているんだよな... - -う、やっぱり、long long は、遠い... できんの? +сC/asm ф吾 +障(篏?) interpreter +c<varargs с... + +潟潟ゃCbCф吾荐篏罐罧c... + +c宴long long ... с? Mon Apr 5 00:20:13 JST 2004 -間違えて3日分消しちゃったい。 - -int でも RLVAR とかの unsigned/signed の区別がないとまずいよね。 - -包括的なテストルーチンがあった方が便利。long.c を消しちゃったし。 +3ュ羔<c + +int с RLVAR unsigned/signed 阪ャ障 + +鴻若潟c鴻箴水long.c 羔<c Fri Apr 9 02:11:42 JST 2004 -やっぱり incore compiler と、non textural syntax が欲しい。 -ま、そうだよね。 - -あと、#include の search path のセマンティクスを直さないと。 +c宴 incore compiler non textural syntax 罨蚊 +障 + +#include search path 祉潟c鴻眼 Mon Apr 12 12:19:35 JST 2004 @@ -3883,124 +3883,124 @@ 3463 !(t==LONGLONG||t==ULONGLONG) && 3464 (car(t)==STRUCT||car(t)==UNION)) { -じゃなくて、t>0 && (car(t)==STRUCT||car(t)==UNION)) { -じゃないか? +t>0 && (car(t)==STRUCT||car(t)==UNION)) { +? Wed Apr 14 14:26:04 JST 2004 -creg なんだけど、直接レジスタを入れるのだと「複数レジスタを -使って double / long を扱う」ってのがやりずらい。だから、 -register 変数を入れるのがいいんじゃない? でも、そうすると -変更が多くなるけど... - -free_register の関係があるから、やっぱり、全部変えないと -だめだね。 - -creg/freg を止めたのは、MIPSが float/double を区別する -必要があるため。この時に、creg を構造体化するべきだった -みたいだね。 +creg 贋・吾鴻帥ャ茲違吾鴻帥 +篏帥c double / long 宴c +register 紊違ャ? с +紊眼紊... + +free_register ≫c宴紊 + + +creg/freg 罩≪MIPS float/double 阪ャ +綽荀creg 罕篏鴻c +帥 creg = { ireg, freg, dreg } -みたいにしても良かったわけだ。 - -もしかして、regv って使ってないの? (そうかも...) - -register は list で持つ? 配列にいれる? +帥c + +regv c篏帥c? (...) + +register list ф? ? regs[0] = glist4(LREGISTER,use,r1,r2) regs[0] = glist3(REGISTER,use,r1) -みたいな感じ? うーん... それよりは、 +帥? 若... ireg_list dreg_list freg_list lreg_list -かな。でしょ? 意外にめんどくさい。ptr cache のコードもあるし。 - -まぁ、conservative にいこう。 - -lreg は、積極的に解放しないとまずいけど、どのタイミングで? -というか、creg もそのタイミングで解放して良いんじゃない? -ふーん。 - -gexpr_init() のタイミングで解放してもいいんだけど、それだと、 -gexpr_0 で廻っているときに解放されないけど。 +с? 鎀ptr cache 潟若 + +障conservative + +lreg 腥罐窮茹f障障帥ゃ潟違? +creg 帥ゃ潟違цВ障? +泣若 + +gexpr_init() 帥ゃ潟違цВ障 +gexpr_0 у算c茹f障 g[long long hoge] -みたいな場合では、途中で解放して欲しいよね? - -use_int とかで lreg は解放して良いんじゃない? - -creg =0 で free_register(creg) が呼ばれているね。困ったな。 +帥翫с筝цВ障罨蚊? + +use_int lreg 茹f障? + +creg =0 free_register(creg) 若違違c Sat Apr 17 17:01:02 JST 2004 -long long register で、regsと regv をそろえる -必要はない。regs は普通に用意して、regv ではなくて、 -lreg_hとlreg_lみたいな感じにする。 - -うーん、register full かぁ。何おかしくしちゃったかなぁ。 +long long register сregs regv +綽荀regs regv с +lreg_hlreg_l帥 + +若register full 篏<c Wed Apr 21 17:32:40 JST 2004 -unsigned のcosnt計算がおかしいんじゃない? +unsigned cosnt荐膊? Thu Apr 22 12:33:04 JST 2004 -ようやっと、int/float が元に戻りました。 - -lrexpr は、codegen で、long の計算に置き換えた方がいい? -でも、それだと、64bit 演算をサポートしているCPUがうれしく -ないか。 - -あと、もう少し! でも、2,3日かかりそう。 -loprtc も、あった方がいいんじゃない? (まね....) +cint/float 祉障 + +lrexpr codegen сlong 荐膊臀鴻? +с64bit 羲膊泣若CPU + + +絨! с2,3ャ +loprtc c鴻? (障....) Fri Apr 23 14:40:02 JST 2004 -あとは、switch, inline, stdargs, alloca かな。 asm もあるか。 -asm は、ちょっと趣旨から外れるからいいか。 - -PowerPC のalloca は、おかしい。おかしいよな。 - -join いれるの? - -a?a,b:a,b って許されるの? - -"" の中のマクロが展開されてしまうんですけど。(ま、そうなんだけど) - -#hoge は無視するか、そのままにするか... +switch, inline, stdargs, alloca asm +asm <c莇f紊 + +PowerPC alloca + +join ? + +a?a,b:a,b c荐宴? + +"" 筝絮障с(障) + +#hoge ∴障障... Sat Apr 24 14:39:14 JST 2004 long long op int, unsigned long long op int/unsigned -ってのがあるのか.... うーん... +c.... 若... Sun Apr 25 17:20:40 JST 2004 -実装しないのにテストルーチン入れるなよ。。。 register lassop - -compiler を書くには... - (1) parser を書く - (2) code 生成部を書く - (3) compiler のcompile エラーを取る - (4) compiler のコード生成をデバッグする - (5) 生成したコードがアセンブラを通るかどうかを直す - (6) 生成したコードが正しいかどうかを調べる -で、(4) までできました。 - - -やっぱり、use_int とかって、なんとなくだめ。だめな -理由があるんだろうなぁ。ほとんどバグはここから -来るんだものね。 - -use_int とかは、codegen でやったんじゃいけなくて、 -もっとも下のcode生成部分でやらないといけないんじゃない? -それでいいのか? - -あ、そうか、 - -creg に対する操作ばっかりじゃないので、code_xxxx(xxxx,creg) -というようになっている。そうすると、creg をその外で -creg = use_int(creg) する必要がある。だね。 +絎茖鴻若喝ャ register lassop + +compiler 吾... + (1) parser 吾 + (2) code 吾 + (3) compiler compile 若 + (4) compiler 潟若違 + (5) 潟若≪祉潟眼 + (6) 潟若罩c茯帥鴻 +с(4) 障сс障 + + +c宴use_int c +宴祉違 +ャ + +use_int codegen сc +c筝codeс? +с? + + + +creg 絲障篏違cсcode_xxxx(xxxx,creg) +ccreg 紊 +creg = use_int(creg) 綽荀 void code_lvar(int e2,int reg) { @@ -4010,10 +4010,10 @@ lvar(e2); } -だと、reg が間に合わない。手遅れ。 - -reg にcreg 以外が入るのは、基本的には assign_opt 系ですね。 -これを creg に直せば。。。。 +reg + +reg creg 篁ュャ堺 assign_opt 膤祉с + creg 眼違 void code_lvar(int e2,int reg) { @@ -4026,7 +4026,7 @@ lvar(e2); } -みたいな? +帥? #define use_int(reg) if (reg==-1) reg = use_int0(reg) void @@ -4041,113 +4041,113 @@ return creg; } -かな。 #define で? ま、どっちでもおんなじようなものか。 - -でも、これは変更多いなぁ。 + #define ? 障c<с + +с紊翫 Mon Apr 26 05:35:24 JST 2004 -一応、no long long は通ったみたいだが。。 - -構造体の戻値を持つ場合に、引数がないとうまくいかない。 - -#include "" は、今読んでいるファイルのcurrent directory も探す。 - -まぁ、ia32 は、eax,edx にlong,long を積んで、あとは、 -対メモリで計算するわけね。そうだろうな。むしろ、 -やさしいかも。 - -あぁ、そうか、long の引数の渡し方は、 -r10 はレジスタ、残りはメモリに入るわけね。 +筝綽no long long c帥 + +罕篏糸ゃゅ翫綣違障 + +#include "" 篁茯с<ゃcurrent directory 「 + +障ia32 eax,edx long,long 腥с +絲障<≪ц膊 + + +long 綣違羝<鴻 +r10 吾鴻帥罧<≪ャ Wed Apr 28 13:01:13 JST 2004 -だいぶ、通りました。ltosop は、終り。 - -drexpr, lrexpr で cond を処理してなかった。 - -浮動小数点の誤差はどうしようもないの? printf の問題? - -あぁ、なんか、まだ、printf が局所変数を壊しているね。 - -そういえば、局所変数のアライメントは合わせてないけどいいの? - -unsigned って、もしかして、もう少しルールが複雑? +吟障ltosop 腟 + +drexpr, lrexpr cond c + +羌絨亥鴻茯ゅ勲? printf 馹? + +障printf 絮紊違紕 + +違絮紊違≪ゃ<潟? + +unsigned c絨若茲? / % << > I op I I I I I I op U I I I I U op I I I U I U op U U U U U -でもないか。 - -なんか、いろいろ直した割に、進んでないな。 - -code_bool がjmpを使うのはいかにもまずいよね。そうねぇ。 - -しかし、float/double printf("%d",f0>f1) の真偽値だけが反転する -バグが取れない。 - -code-gen.c の方は動いたが、float.c の方がだめ。 -なんか、まるででたらめに動いているみたい.... - -function() の中で、lreg がinput registerと重なってしまう。 +с + +眼蚊蚊с + +code_bool jmp篏帥障 + +float/double printf("%d",f0>f1) 遵ゃ荵≪ +違 + +code-gen.c 鴻float.c 鴻 +障сс帥.... + +function() 筝сlreg input registerc障 Thu Apr 29 19:40:08 JST 2004 -良くわかんないけど通った。 +c Sun May 2 09:40:21 JST 2004 -やっぱり LREGISTER なんて作るんじゃなかった。code_lconst -とかで edx,eda と dsi,edi pair の切替えをやらないと。 +c宴 LREGISTER 篏ccode_lconst + edx,eda dsi,edi pair 帥 Thu May 6 08:33:23 JST 2004 -ia32, powerpc とも long long まで、通りました。ia32 も一週間 -かかったか。次は、MIPS, ARM ですな。 - -大域変数+オフセット ( heap[3] みたいなの) で、 -heap+24 とか出ない。もともとは offset,y だったから -いらなかったんだけどね。 - -互換性を捨ててしまえば、大域変数ポインタを導入しても -いいんだけど。だだ、32bit 以上のオフセットだとRISC -命令だとまずい。 +ia32, powerpc long long 障с障ia32 筝演 +c罨<MIPS, ARM с + +紊у紊+祉 ( heap[3] 帥) с +heap+24 冴 offset,y c +c + +篋с障違紊у紊違ゃ潟帥絨ャ +32bit 篁ヤ祉RISC +巡擦障 -オブジェクト指向だとそのあたりは解決するんだけどね。 - -longlong/float のregressionはいいんだけど、もう少し -整合性があった方がいいかもね。 - -なんか、Linux のinclude directory って、どうにかなんないの? - -assop で、 +吾с茹f浦 + +longlong/float regression絨 +翫сc鴻 + +Linux include directory c? + +assop с calc left exp move creg,dreg move const,creg op creg,(dreg) -って、やっているのなんか変じゃない? - -a && b で、b のboolを計算しているのは変。use のフラグ -を見るのを追加したら。 +cc紊? + +a && b сb bool荐膊紊use +荀菴遵 Sat May 8 21:29:32 JST 2004 -浮動小数点やlong longの代入で同じ値は一つにまとめるべきだよね。 -連想 list を一つ持てば良いだけだし。 - -string をまとめるかどうかは、const かどうかによるわけだが... - -RETURN register あたりの処理がダサイ。ま、しょうがないか。 - -MIPS のdebugにかかるんだけど、今は時期が悪いよな。なんで、 -もっと早くできなかったのか。gcc modification はどうした? - -だから register を 0 で入ってないとするのはまずいって -言っているのに... - -float は normal register に積むのか。 +羌絨亥鴻long long篁eャуゃ筝ゃ障鴻 +f list 筝ゆ域 + +string 障const ... + +RETURN register 泣ゃ障 + +MIPS debug篁с +cсcgcc modification ? + + register 0 уャc障c +荐c... + +float normal register 腥 s.s $f4,16($sp) mov.s $f12,$f0 @@ -4156,91 +4156,91 @@ mfc1 $7,$f3 jal f -ま、いいんだけどさ。(でも、なんで$4,$5 を使わないんだ?) - -long long も4,5,6,7 しかレジスタに積まない。ま、正解だけど。 - -げ、レジスタのセーブって自分でやるのか。(じゃ、mask ってなん -だよ...) ってことはentry はあとで出力しないとだめだね。 - -まぁ、いちいち驚かないけど... 細かいエラーが残っているな。 - -やっぱり codegen の拡張法を作っておかないとダメだね。 - -関数呼び出しパートをCbC自身で書けないのかなぁ。 -あまりにめんどくさすぎ。 - -cpload は、gp レジスタの処理に関係するらしい。gp レジスタって何? -cploat $25 の $25 は、stack offset みたいね。$sp を変更するときに、 -なんかのフラグを壊さないようにするための処理みたい。 - -だとすれば、code segment 側でstackを頻繁に移動するのはまずい? - -float/double のフローは mc-parse では、少し、齟齬があるみたい。 - -は、良いとして.... - - cprestore, mask の計算 - offset の合わせ - -が終れば動くの? それだけ? - -あぁ、 +障(с$4,$5 篏帥?) + +long long 4,5,6,7 吾鴻帥腥障障罩hВ + +吾鴻帥祉若cс(mask c +...) centry у阪 + +障<♂... 膣違若罧c + +c宴 codegen ≦宍羈篏c< + +∽医若喝冴若CbC荳ф吾 +障 + +cpload gp 吾鴻帥≫gp 吾鴻帥c篏? +cploat $25 $25 stack offset 帥$sp 紊眼 +違紕帥 + +違code segment 眼stack紫腱糸障? + +float/double 若 mc-parse с絨藹藹帥 + +.... + + cprestore, mask 荐膊 + offset + +腟医? ? + + int endian; extern int endian; -も通す必要があるのね。まぁ、フラグの扱いだけだけど.... +綽荀障違宴.... Thu May 13 12:58:58 JST 2004 - .frame の数字には input variable のsave分も入るんじゃないの? - - code_l1 の ll0 がおかしくなるのは、strtoll がintに宣言されてるから。 - -function のargumentは複雑なものから計算して行くのがルールなのね。 -ま、そうだよな。できないことはない.... - -そうなのか。最初にループを廻して複雑なものをレジスタなり変数なり -に代入して、引数リストを置き換えてしまえば良い。ついでに、 -代入するべき変数はそこで計算しておいて... (って、これって、 -parallel_assignment でやっていることと同じか) - -その部分はcodegen でやってもいいんだけど... ia32 のような場合は -むしろ不要なのか。 - -でも、やっぱり、意外に複雑だよ。struct をどうするかとかさ。 - -struct は、call memmove するんだけど、そいつを先にやるわけには -いかない。先にやると、その間のfunction callが壊してしまう。 -後に持って良くと、input register が壊れるので、やっぱり、 -特別扱いする必要がある。ってことは... + .frame 医 input variable saveャ? + + code_l1 ll0 strtoll int絎h + +function argument茲荐膊茵若 +障с.... + +若綮祉茲吾鴻帥紊違 +篁eャ綣違鴻臀障域ゃс +篁eャ鴻紊違ц膊... (cc +parallel_assignment сc) + +codegen сc... ia32 翫 +筝荀 + +сc宴鎀茲struct + +struct call memmove ゃ +function call紕障 +緇cinput register 紕сc宴 +劫ユ宴綽荀c... complex function argument struct copy simple arguments -っていう順番でやれば良いってことか.... うーん。 - -(うーん、でもなぁ。やるの?) - -function argument の計算で、long long register が破壊されるのは、 -なんか方法が悪いんじゃないの? 本来、lreg は値渡しできるべきだよね。 -まぁねぇ。 - -複雑なものから計算する方が良いってことは、スタックに積む -引数から計算した方が良いってことか。 - -ま、それはできたとして... +cс域c.... 若 + +(若с?) + +function argument 荐膊сlong long register 翫 +号? ャlreg ゆ検с鴻 +障 + +茲荐膊鴻c鴻帥腥 +綣違荐膊鴻c + +障с... Sat May 15 22:45:30 JST 2004 -結局、.cprestore は、最初にないといけないので、include を -使うしかないらしい。 - -add.s の浮動小数点レジスタが印字されないけど。 +腟絮.cprestore сinclude +篏帥 + +add.s 羌絨亥鴻吾鴻帥医 Sun May 16 13:58:42 JST 2004 -問題はレジスタのsaveだね。使ったレジスタはコード生成の後で -しかわからないので。後方にjmp すればいいんだけど。どんな -風に? +馹吾鴻帥save篏帥c吾鴻帥潟若緇 +с緇鴻jmp 違 +蘂? subu $sp,$sp,$L_r1_offset .cprestroe @@ -4264,10 +4264,10 @@ $L_fsave: j $31 -みたいな感じにする? すると、必ず$31はsaveすることになるけど。 -noreorder しないとだめかも。 - -この方がコンパクトだけど、 +帥? 綽$31save +noreorder + +鴻潟潟 subu $sp,$sp,$L_r1_offset .cprestroe sw $fp,$_Lr1_offset-16($sp) @@ -4286,46 +4286,46 @@ s.s $f20,-8($sp) j $L_save_0 -の方がいいかな。save する必要がなければ、 +鴻save 綽荀違 j $L_save $L_save_0: move $fp,$sp $L_save = $L_fsave_0 -とできるし。 - -両方作って、時間計る? - -まぁ、前者の方が凝っているし、命令数的にも変わらないから、 -space factor 的に前者の方が速いんじゃないか? - -でも後者の方が簡単だよな。 +с + +筝≧剛c荐? + +障鴻c巡擦亥紊 +space factor 鴻? + +с緇鴻膂≦ Mon May 17 01:09:02 JST 2004 -さて、アセンブルは通るようになりましたが... - -どうも、$0,$1が出てしまう場合があるみたい。これを検出する -手段を作った方が良いね。 - -あと、int の後のdouble/longlong は、$3 のあと、$5,$6 と -来るみたいですね。 - -さて、いよいよ、オフセット合わせか。 +≪祉潟障... + +$0,$1冴障翫帥罎冴 +罧泣篏c鴻 + +int 緇double/longlong $3 $5,$6 +ャ帥с + +祉 Tue May 18 13:05:24 JST 2004 -なんかレジスタセーブがぼろぼろじゃん。max_reg_var とかが、 -ちゃんとレジスタの個数を表すようにしろよ。 +吾鴻帥祉若若若max_reg_var +<吾鴻帥違茵 Wed May 19 13:49:40 JST 2004 -endian に関するコードは、ちゃんとソースにそう書いた方が良いね。 - -やぁ、なんかEndianが合わないよ。ぜんぜん。 - -printf に $6,$7 と同じ値を渡しているのに、 +endian ≪潟若<純若鴻吾鴻 + +Endian + +printf $6,$7 ゃ羝< diff test/code-gen-all.gcc.out test/code-gen-all.mc-mips.out 53,54c53,54 @@ -4335,75 +4335,75 @@ > code_lrindirect 37ffffffc9 37 c8 80 > code_lrindirect 240518168521 55 200 128 -となるのはなんでだろう? 37 が overwrite されているのか。 -でも、37のポジションは正しいんだよな。37自体はレジスタには -乗ってないし。 +с? 37 overwrite +с37吾激с潟罩c37篏吾鴻帥 +箙c Wed May 19 22:15:33 JST 2004 -しかし、がんがんバグは取れていくわけだけど、なんか、 -微妙にわけわからないバグが残っているな。 - -MIPSってconst のかけ算ないんだよね。だったら、*4ぐらい -はshiftした方が良いかも。 +違 +緇絋違罧c + +MIPScconst 膊c*4 +shift鴻 Thu May 20 21:46:17 JST 2004 -register_dassop をテストしてなくて、コードも間違ってる。 - -chptrsave なんだけど、 +register_dassop 鴻潟若c + +chptrsave case hoge: macro_replace() -で、case hoge: が終了すると、getsymの先読みで、macro_replace -を展開して、そこが lfree ( chptrsave = list2(hoge,chptrsave) )に乗ってしまう。 -docase で、lfree = slfree すると、そのlist2 は破壊されてしまう。 -つまり、slfree=lfree;.... getsym ...; lfree=slfree は、正しくない。 -なので、list2 じゃなくて、glist2 して、free_glist2 してやるようにする。 - -でも、そもそも、macro_buffer は、どうなの? その領域は再利用されるのか? -そうでないと巨大なmacroを書かれたときに気まずい。cheap は、malloc -してもいいんじゃないかなぁ。 - -code-gen-all.c と simp1.c は通ったんだけど、basic.c が微妙に -通らない。なんでかな。diff もね。 +сcase hoge: 腟篋getsym茯帥сmacro_replace +絮 lfree ( chptrsave = list2(hoge,chptrsave) )箙c障 +docase сlfree = slfree list2 翫障 +ゃ障slfree=lfree;.... getsym ...; lfree=slfree 罩c +сlist2 glist2 free_glist2 + +сmacro_buffer ? ? +с綏紊сmacro吾羂障cheap malloc + + +code-gen-all.c simp1.c cbasic.c 緇絋 +сdiff Fri May 21 13:09:10 JST 2004 -switch なんだけど、long long を通すと落ちるね。 - -なかなかself compileが通らないな。今度は、getsym か。やっぱり、$gp -関連? - -代入文の型が右辺値の型になっていた。こんなバグが、まだ、 -残っていたとは。 - -double register の順序を決めないとdead lock するな。 - -えーと、double register がconflict しまくるなぁ。 -さすがに function では起きないらしいが... -ということは、set_[dl]operand の問題か。 - -やっぱり register parallel assign を書くのが簡単だよね。 - -slt/beq ってのが、うまく動いてないみたいね。 +switch long long 純< + +self compile篁綺getsym c宴$gp +∫? + +篁eユ勈昇ゃc違障 +罧c + +double register 綺羆冴dead lock + +若double register conflict 障 + function с莎激... +set_[dl]operand 馹 + +c宴 register parallel assign 吾膂≦ + +slt/beq c障帥 Sat May 22 12:49:55 JST 2004 -なんか構造体の先頭はレジスタに置くみたいね... いいけど。 -$5,$6,$7 か。 - -continuation frame は、$sp=$fp にするの? 関数引数は -$fpに積んでいるから、そうする必要があるわけだけど。 -そうすると$fp を毎回動かさないといけないんだよね。 -まぁ、PowerPCでも、そうしているわけだけど。 - -jal 後に $gp を書き戻すわけだけど、そのアドレスは -決まっているし、毎回セーブする必要もないけど。 -$sp 相対だとまずいなぁ。 - -fmask,mask とかも要らないんじゃないの? そもそも -なんでいるんだろう? +罕篏吾鴻帥臀帥... +$5,$6,$7 + +continuation frame $sp=$fp ? ∽医違 +$fp腥с綽荀 +$fp 罸 +障PowerPCс + +jal 緇 $gp 吾祉≪鴻 +羆冴障c罸祉若綽荀 +$sp 後障障 + +fmask,mask 荀? +с? (gdb) x/20i carg1 0x400a80 <carg1>: lui $gp,0xfc0 @@ -4418,10 +4418,10 @@ 0x400aa4 <carg1+36>: lw $a0,0($t3) 0x400aa8 <carg1+40>: lui $t2,0xf000 -というように .cp 関連は変換される。本当は自分でやった -方が良いんだけど。 - -ブランチは jal みたいには変換されないのか。まずい? + .cp ∫c紊綵сc +鴻 + +潟 jal 帥紊障? 0x400b00 <carg1+128>: move $a1,$s5 0x400b04 <carg1+132>: move $a2,$s4 @@ -4431,42 +4431,42 @@ 0x400b14 <carg1+148>: nop 0x400b18 <carg1+152>: lw $gp,32($s8) -やっぱり sp 相対で $gp はセーブされるのか。jalr と -自分で明示する方が安心か。 - - *.i が作られるのは良いが、 .include で -ファイル名がずれる。出力ファイルに相対して - .i を作るべき。 - -a.c b.c のようにつなげると止まらなくなる。(-Dのループか?) - -結構、比較のバグが残っているじゃん。定数比較でembugしたかもね。 - -long long の比較は int の比較から作る汎用ルーチンを作った方が -良くない? - -つうか、まったく間違ってました。 +c宴 sp 後障 $gp 祉若jalr +ф腓冴鴻絎綽 + + *.i 篏 .include +<ゃ阪<ゃ後障 + .i 篏鴻 + +a.c b.c ゃ罩≪障(-D若?) + +腟罕罸莠違罧c絎井莠embug + +long long 罸莠 int 罸莠篏羆若潟篏c鴻 +? + +ゃ障cc障 Sun May 23 17:10:59 JST 2004 -やっとMIPSが仕上ったよ。まだ、code jump は、できてないけど。 - -そもそも external jumpができるかどうか調べてないな。 - -slt $r1,$r2,12 みたいなコードも出したいが... - -parallel_rassign って target=source で無限ループしない? +cMIPS篁筝c障code jump с + + external jumpс茯帥鴻 + +slt $r1,$r2,12 帥潟若冴... + +parallel_rassign c target=source х♂若? Sun May 23 21:21:22 JST 2004 -やっぱり、boolean の扱いがなぁ。jmpでない方が良いよね。 +c宴boolean 宴jmpс鴻 Mon May 24 07:11:57 JST 2004 -関数呼び出しの引数は、やっぱり$spオフセットで積むべきでしょう。 -でないと、$fp!=$sp の時におかしくなる。($s8=$fp) - -code から大域変数が読めない。 +∽医若喝冴綣違c宴$sp祉х鴻с +с$fp!=$sp ($s8=$fp) + +code 紊у紊違茯 0x401170 <main1>: lui $gp,0xfc0 0x401174 <main1+4>: addiu $gp,$gp,28352 @@ -4485,7 +4485,7 @@ 0x400ab0 <carg1+16>: sw $gp,32($sp) 0x400ab4 <carg1+20>: move $s8,$sp -ですか。$t9 ってなんだろう? +с$t9 c? 0x401290 <main+48>: lw $t9,-32744($gp) 0x401294 <main+52>: addiu $t9,$t9,4464 @@ -4493,24 +4493,24 @@ 0x40129c <main+60>: nop 0x4012a0 <main+64>: lw $gp,16($s8) -これか。ってことは、恐れていた通り、 +c printf("\tj %s\n",s); -ではだめなのね。 - -$t8 は、$25 ってことは、$t9 は$26? jmp先みたいだね。 $jp? -cpload $25 の$25 じゃないの? じゃぁ、 +с + +$t8 $25 c$t9 $26? jmp帥 $jp? +cpload $25 $25 ? jrn = register_name(cadr(jmp)); printf("\tmove $25,%s\n",jrn); printf("\tjal\t$31,$25\n"); -すればいいのかな? - -.ent しないっていう手もあるけど... 外から入って来た時に -どうする? (そもそも、code って、外から呼び出せるの?) +違? + +.ent c... 紊ャcャ +? (code c紊若喝冴?) printf("\tla $25,%s\n",s); printf("\tj\t$25\n"); -でいいみたいだね。 +с帥 1,9d0 < arg1: 0 1 2 3 4 : 1 1 < arg1: 1 2 3 4 0 : 1 1 @@ -4527,7 +4527,7 @@ arg1: 1 2 3 4 0 : 0 0 args: 0 263785888 4200109 2712942 0 : 0 0 Segmentation fault -ま、いろいろあるね。 +障 0x401180 <main1+16>: sw $gp,16($sp) @@ -4536,41 +4536,41 @@ 0x40129c <main+60>: nop 0x4012a0 <main+64>: lw $gp,16($s8) -この一貫しないのやめてよ.... $sp!=$fp にすると、$gp がずれて -しまう。call の前に $fp=$sp にするという手もあるが.... - -結局、自分で、 +筝莢.... $sp!=$fp $gp +障call $fp=$sp .... + +腟絮с lw $gp,16($sp) -するので解決。 +цВ羆冴 Mon May 24 13:26:54 JST 2004 -MIPS の jump は、できました。MIPSはR1SAVEしないのね。R1SAVE -の方が若干安全な気もするが、毎回手間があるのはいただけないよ -ね。 - -leave で、control が必ず on になるのは何故? - -次は、やっぱり、c2cbc でしょう。 - -(float) f == 1.0 で double に変換しているな。 - -register oprtc が、 +MIPS jump с障MIPSR1SAVER1SAVE +鴻ュ慌絎羂罸 + + +leave сcontrol 綽 on 篏? + +罨<c宴c2cbc с + +(float) f == 1.0 double 紊 + +register oprtc move $4,$20 addu $4,$4,16 move $20,$4 -とかなるのは悲しくない? +蚊? Tue May 25 05:14:30 JST 2004 -indirect jump で、$25 に代入するんだけど、 -後ろに廻せば必ず simple になるから、そこでは -$25 に直接代入できるね。move 一つ減るだけだけど。 - -pcond は、pcond_const を持つべき。 - -cmp/jcond は、一つで処理した方が良い。switch 文も bne $6,1,$L_11 -とかできた方が良いよね。 +indirect jump с$25 篁eャ +緇綮祉医 simple с +$25 贋・篁eャсmove 筝ゆ + +pcond pcond_const ゃ鴻 + +cmp/jcond 筝ゃу鴻switch bne $6,1,$L_11 +с鴻 struct proto tcp_prot = { .name = "TCP", @@ -4581,21 +4581,21 @@ .ioctl = tcp_ioctl, .init = tcp_v4_init_sock, -は、便利だよね。あった方がいいよな。(そんなに難しくないし) -ただ、一旦全部リストにしないと格納できないか。混在した場合は -どうなるんだろう? 文句言えばいいの? - -やっぱり、難しいんじゃないかなぁ。これって、その場でemit_data/ -decl_data できないよね。local の場合はassign の列にコンパイ -ルすることはできるんだけど。global は、assign_data で、なん -かのキューに入れるか。mode を増やすわけね。 - -decl_data の先頭でgetsymするのはまずいわけね。 +箴水c鴻(c) +筝鴻主с羞桁翫 +? ヨ違? + +c宴cc眼emit_data/ +decl_data сlocal 翫assign 潟潟 +сglobal assign_data с +ャ若ャmode 紜 + +decl_data getsym障 while(t1) { offset = decl_data(car(t1),n,offset); /* alignment? */ .... } -の代わりに、 +篁c getsym(); if (SYM==DOT) { @@ -4618,33 +4618,33 @@ offset = decl_data(car(t1),n,offset); /* alignment? */ .... } -みたいな感じ? nest した場合は、emit_sname_assign でも decl_data -を呼んで、再度キューに入れるしかないか。 +帥? nest 翫emit_sname_assign с decl_data +若с綺ャ若ャ Mon May 31 19:08:57 JST 2004 -register_assop は、いいんだけど、register_assop_const の -コードが良くないね。 +register_assop register_assop_const +潟若 Wed Jun 2 13:12:35 JST 2004 -rexpr に value option を付けて、 +rexpr value option 篁 code_bool -では、rexpr,drexp を呼んだ方がいいんだけど... && || とかどうする -かな。 - -あーあ、なんか恥ずかしいミスが残っているね。 +сrexpr,drexp 若鴻... && || + + +若ャ鴻罧c Thu Jun 3 13:16:33 JST 2004 -code_bool はできたんだけど、まぁ、自己満足だよね。 - -code_bool で !use の時に、null branchが残っちゃうけど... -ま、仕方がないか。 +code_bool с障綏掩莇潟 + +code_bool !use null branch罧c<... +障篁鴻 Fri Jun 4 12:57:28 JST 2004 -switch 文をやるんだけど、 +switch main() { int i=3,j=1,k=0; @@ -4655,25 +4655,25 @@ printf("%d\n",k); } -なんだけど、j<10 などを評価する前にjmpする必要があるので、最 -初のcase文にjumpしないといけないが、jump する必要があるかど -うかは、switch の次の文を実際に評価してみないとわからない。 - -なので、 checkret() で、その処理を行う方が良い。 +j<10 荅箴<jmp綽荀с +casejumpjump 綽荀 +switch 罨<絎荅箴<帥 + +с checkret() с茵鴻 if (first_case) { jmp(first_case); first_case =0; } -かな。もし、これが行われるなら、飛び先はtable jump routine であるべき。 - -switch をまとめるのはやったけど、現状のコードだとtable -は、ほとんどでないね。2分木は出るけど。IDが連続するように -工夫した方がいいのかな。 - -chunk の merge のalgorithm だけど.... O(N^2) だよね。 +茵蕋喝table jump routine с鴻 + +switch 障c憟吟潟若table +祉с2冴IDg +綏ュか鴻 + +chunk merge algorithm .... O(N^2) c0, c1, c2, ... cn -で、(なんか見たことある...) +с(荀...) c0, c1, c2, ... cn +------------------+ rate @@ -4685,64 +4685,64 @@ +-----+ rate ... -というのを作る。((n-1)*(n-2)/2) か。で、一番、rate の高いものを -取るのが、正しいとは限らない.... rate じゃなくて、cover 率が -高いものの方が良い。消去法が良くて、まず、 - - RATE 以下のものを消去する (生成しない) - そして、cover 率の高いものをとって、すべてを取り尽くす +篏((n-1)*(n-2)/2) с筝rate 蕭 +罩c.... rate cover +蕭鴻羔サ羈障 + + RATE 篁ヤ羔サ () + cover 蕭c鴻絨純 +------------+ rate 75% +-------++------+ rate 80% -みたいなのをどうするかだけど... テーブルが少ない方を優先? -テーブルが一つが良いとは限らない。 - -count が多いのに delta が異なると一般的にはだめ。 +帥... 若絨鴻? +若筝ゃ + +count 紊 delta 違筝 +-------++---------+ rate 80% - <------> みたいな形で取り合う場合もある。 - -この場合は cover rate が変わらないので、table rate で計算する? - -えーと、生成した全ての区間の組合せが許されるわけではない。 + <------> 帥綵≪у翫 + +翫 cover rate 紊сtable rate ц膊? + +若咲腟荐宴с c0, c1, c2, ... cn - +----+ rate これが fix すると、 + +----+ rate fix +---------+ rate +-------------+ rate +-----+ rate - ... などしか許されない。 - -後ろから計算しても前から計算してもおんなじはず。 -ただ、飛び値が多い場合の計算量がなぁ。 - -まぁ、やっぱり、 + ... 荐宴 + +緇荐膊荐膊 +蕋喝ゃ紊翫荐膊 + +障c宴 for i (0..n) { - c_i を c_n に向かって可能な限り拡大する - できなかったら、それを生成 + c_i c_n c純≦ぇ + сc } -でしょ? - -まぁ、だいたいできたんだけど、細かいバグが残っていそうだね。 +с? + +障с膣違違罧c < # chunks 1 = sum 1/123 sum = 1 --- > # chunks 1 = sum 1/2 sum = 1 -なんてのもあるし。 - -merge が大きい方からやってくようにしちゃったけど、少し、 -結果が良くないみたい。人間は、case 1: case 2: ... というように -書くからね。そんなに難しくないはずだが、直すのが面倒。 + + +merge 紊с鴻c<c絨 +腟帥篋咲case 1: case 2: ... +吾c眼√ Sun Jun 6 02:41:27 JST 2004 -次はバイナリサーチで、テーブルを生成するコードを書けば良いだ -けだが。2分法だときれいなブランチパターンにならない。8分法ぐ -らいで書くのがいいんじゃないかな。 +罨<ゃ泣若с若潟若吾域 +2羈潟帥若潟8羈 +ф吾 case_group_1: if (c==case_2) goto case_2 ( or nested case_group ) @@ -4764,14 +4764,14 @@ ... else goto default; -かな... (*) は、オプション。ない方が良いCPUもあるだろう。MIPSとか。 - -フラットの方が良い場合もあるはず。(実測する?) +... (*) 激с潟鴻CPUMIPS + +鴻翫(絎羝?) Sun Jun 6 09:39:13 JST 2004 -で、nested branch は、どう実装すれば良いの? recursive に -書くんだよね? bottom up に書きたいところだけど。 +сnested branch 絎茖域? recursive +吾? bottom up 吾 #define CASE_INDEX_COUNT 8 switch_index(int chunk,int *cslist) { @@ -4782,136 +4782,136 @@ while(chunks) { chunk = switch_index(chunk,&cslist); -ぐらい? (chunk でやるの?!) ... ん... だったら、merge_chunk -でできるんじゃないの? できるだろうけど、ちょっと複雑すぎるか。 - -table があるなら、必ず index は必要。 - -index がtableになることって... 偶然にはあるかも知れないし、 -無理にすればできないことはないだろうけど... +? (chunk с?!) ... ... cmerge_chunk +сс? с<c茲 + +table 綽 index 綽荀 + +index tablec... 句吟ャ +∞違с... Sun Jun 6 23:07:16 JST 2004 -level 1 table がおかしい。そうだよなぁ。 - -今のアルゴリズムだと、10ずつ連続しているテーブルに -少数のanomalyがあるって時に困るね。テーブルが分解されちゃう。 -ま、そんなコードないと思うけど。 - -cmpdimm を直すのを忘れてました。 - -あと、delta!=1 だと、割算したときの余りが0であることを確認しないと -いけない。gcc では、delta!=1 の表は出さないみたいだね。 - -あと、行き先が同じcaseは、range check にするとか... -(まぁねぇ。。) - -ま、一応はできました。 - -kernel とか gcc とか compile できると良いけどねぇ。 +level 1 table + +篁≪眼冴10らg若 +絨違anomalyc違若茹c< +障潟若 + +cmpdimm 眼綽障 + +delta!=1 牙篏0с腆肴 +gcc сdelta!=1 茵冴帥 + +茵caserange check ... +(障) + +障筝綽с障 + +kernel gcc compile с Mon Jun 7 18:24:27 JST 2004 -さて、次は、構造体の初期化か、c2cbc か。mc-tree の分離か。 - -局所変数の初期化がレジスタ変数であるに関わらずスタックを -初期化しているな。 +罨<罕篏c2cbc mc-tree ≪ + +絮紊違吾鴻水違с≪鴻帥 + gcc -E -c -DCONFIG_TASK_SIZE=4096 -DCONFIG_KERNEL_START=1 -D__KERNEL__=1 tcp_ipv4.c -I../../include > ~/src/device/test/struct_init.c -kernel source は、まだ、早いんじゃない? asm とかあるし。 -でも、asm も難しそうではないけどね。 - -stdarg は簡単なんだけど、初期化用の C source を持っていた方が -良いね。macro だけでなく typedef もしたいよね。 - -"test" "test" は、macro 中では使えない。っていうか使う必要ない? -どうせ、あとで解釈されるから。 - -hoge##name みたいなのの扱いだけど... hogefuga に変換されたあと、 -また、展開する必要があるんだよね。 - -初期化ソースは、chptr に代入すると macro processing されない。 -macro は、getline で行われるから。うーん。 - -うーん、line continuation と macro の関係は奥が深いな。 -getch が null を返すのを認めれば良いんだけど、他のところの -影響が大きい。 +kernel source 障? asm +сasm cс + +stdarg 膂≦ C source c鴻 +macro с typedef + +"test" "test" macro 筝с篏帥c篏帥綽荀? +цВ + +hoge##name 帥宴... hogefuga 紊 +障絮綽荀 + +純若鴻chptr 篁eャ macro processing +macro getline ц若 + +若line continuation macro ≫絅ャ羞宴 +getch null 菴茯域篁 +綵演帥紊с ## l = va_arg(ap,long long); ## (*((longlong *)ap)++) -うーん。macro 関係か。space 除いているの誰だろう? - -あ、そうか、register 上の引数は、varargs の場合は、 -すべてメモリに入れないといけないわけね。じゃぁ、 -浮動小数点か整数かはどうやって判断するの? +若macro ≫space ゃ茯違? + +register 筝綣違varargs 翫 +鴻<≪ャ +羌絨亥鴻贋違cゆ? Wed Jun 9 10:14:35 JST 2004 -切符買わないと。なんか、関数の引数の型のチェックをしてない -みたい。 - -stdarg できました。struct size のエラーはなに? - -えーと、 +膃莢激∽違綣違с +帥 + +stdarg с障struct size 若? + +若 alloca asm struct partial field init hoge##name -がないね。というか、これだけ? (頑張れ〜) +? (綣泣) Thu Jun 10 17:57:35 JST 2004 -struct partial field init は、できたんだけど、局所変数の場合 -は、不定の部分を0にしているみたいね。つまり、static にとって、 -コピーしているみたいね。これは標準的なセマンティクスなのかな? - -やっぱり、重複した初期化は許されないのが普通なのか。 - -skipspc()=='.' だとコメントがスキップされない。ふーむ。 -もういいよ。skip flag で。 - -なんで macro_expansion が +struct partial field init с絮紊違翫 +筝絎0帥ゃ障static c +潟若帥罔羣祉潟c鴻? + +c宴茲荐宴 + +skipspc()=='.' 潟<潟鴻泣若 +skip flag с + + macro_expansion c = 1; macrop = list2((int)macropp,macrop); while(c && (*macropp++ = c = *body++)) { -なんて変なループなんだ? +紊若? Sat Jun 12 10:42:15 JST 2004 -そうか、inline のために constant switch とかをやると、全体的 -に statement をskip するってのを書かないといけないわけね。chk -を使えば良いんだろうけど。それほど、難しくはないけど.... - -alloca も r1 と $sp を動かしているだけじゃん。 - -残りは、 +inline constant switch 篏 + statement skip c吾chk +篏帥域祉c.... + +alloca r1 $sp + +罧 alloca inline asm -と言うことになりましたが... MIPS のstdargも動いてないけど... -問題は include file の方だものな。 - -typeof かぁ。 +荐障... MIPS stdarg... +馹 include file 鴻 + +typeof typeof (hoge) i; sizeof(typeof(hoge)); ((typeof (hoge)) fuga) -みたいな感じ。 - -なんか g() で、register_save が出ちゃってるね。 +帥 + + g() сregister_save 冴<c Sun Jun 13 12:20:39 JST 2004 -ia32 の alloca は、関数の引数に呼び出されるのはまずい。あと、 -stack の途中も、まずい。じゃぁ、どうするの? +ia32 alloca ∽違綣違若喝冴障 +stack 筝障? a = alloca(3)+3; f(i,alloca(3),j); -みたいなのでも破綻しちゃうのね。 - -powerpc でも結構奥が深いな。関数呼び出し時の引数は、 -r1 相対でつまないとだめ。そうだよね。というか、 -最初から r1 相対で積めよ。 +帥с雁胸< + +powerpc с腟罕絅ャ羞宴∽医若喝冴綣違 +r1 後障сゃ障 + r1 後障х lwz r2,0(r1) neg r0,r0 @@ -4920,96 +4920,96 @@ addi r0,r2,15 srwi r0,r0,4 slwi r0,r0,4 - stw r0,208(r30) <=== 最初のlocal 変数のアドレス。 + stw r0,208(r30) <=== local 紊違≪鴻 b L26 L25: li r0,0 stw r0,208(r30) L26: -ってわけか。 - -うーん、 +c + +若 int i; goto f(alloca(100),&i); -なのってあるよね。だとすれば、local 変数はつぶさない方が -いいのか。その方が簡単か。そうすると絶対に local 変数と -goto の引数は重ならないから parallel assignment の必要 -ないし。なんで、最初からそうしなかったんだろう? - -しかし、そうするにはどこ直せば良いんだろう? max-func-arg? - -まぁ、取り合えず、alloca と goto は両立しないってことで -いいんじゃない? 一段、subroutine はさめば良いだけだしね。 +c違local 紊違ゃ吟鴻 +鴻膂≦腟九障 local 紊違 +goto 綣違 parallel assignment 綽荀 +сc? + +眼域? max-func-arg? + +障alloca goto 筝∞c +? 筝罧泣subroutine 域 Mon Jun 14 20:48:13 JST 2004 -PowerPC の alloca は動いたけど... +PowerPC alloca ... Tue Jun 15 10:47:53 JST 2004 -やっぱ inline の方が asm macro より先? asm macro も constraints を -限定すればそんなに難しくないと思うけど。 - -inline は、本当は CSE とか flow 解析とかやらないといけないんだけどね。 - -ただ、inline するのが良いかは CbC との相性によるよな。 - -というわけで、asm が先の方がいいんじゃない? - -ia32 のswitch 文がおかしくなってるぞ。 +c inline 鴻 asm macro ? asm macro constraints +絎違c + +inline 綵 CSE flow 茹f + +inline CbC 御с + +сasm 鴻? + +ia32 switch c Wed Jun 16 13:05:40 JST 2004 -asm は、({....; val;}) も一緒に実装しないとだめ。あと、 -local_decls での redefined だけど、なんかいい方法あるの? -無視ってもいいんだけど... - -association list を使って、unwind すれば良いんだけどね。 -それは、全体的に手直しした方が良い。後回し。 - -cheap の扱いで boundary を見てないのがいつくあるね。 +asm ({....; val;}) 筝膩絎茖 +local_decls с redefined 号? +∴c... + +association list 篏帥cunwind 域 +篏眼鴻緇 + +cheap 宴 boundary 荀ゃ Thu Jun 17 17:10:21 JST 2004 -えーと、 - "m" とかは、メモリの変更なので見なくてよろしい - "r" はレジスタを割り当てる - "=" は出力のマークなので無視して良い - "+", "&" は出力のマークなので無視して良い -で、 - "0" 0番目のoperand -とかなんだけど... こいつは input (先にコンパイルする方) -に現れる。だから、output operand を先に処理する。out -put operand は単純な代入文だから、それでOk。 +若 + "m" <≪紊眼ц + "r" 吾鴻帥蚊綵 + "=" 阪若х∴ + "+", "&" 阪若х∴ +с + "0" 0operand +... ゃ input (潟潟ゃ) +憗output operand out +put operand 膣篁eユOk Fri Jun 18 13:33:19 JST 2004 -なんか、%0,%1 とかって、同じレジスタに割り振られることも -あるみたいね。さらに、連続してでて来るとも限らないみたい。 - -ってことは? - -なんか、間違えた。%0...%8 は、パラメターの順序を -さしているのね。そうだよな。 +%0,%1 c吾鴻帥蚊 +帥gсャ帥 + +c? + +%0...%8 <帥若綺 + Sat Jun 19 00:17:33 JST 2004 -asm は終りました。まぁ、ia32とかMIPSとかは、独自な問題が -あるんだろうけど。 +asm 腟障障ia32MIPS馹 + Sat Jun 19 06:40:30 JST 2004 -label がfunction localになってないみたい。 - -builtin_expect かぁ。 - -bit field が少しある見たい。 - -結局、全部、実装しないとだめか。 +label function localc帥 + +builtin_expect + +bit field 絨荀 + +腟絮絎茖 q = (struct spin_lock) { }; -とか。 + typedef struct __wait_queue wait_queue_t; @@ -5018,64 +5018,64 @@ ... }; -って言う感じで typedef の struct が後だしジャンケンされてしまう。 -後ろの struct def は、typedef された型名を知りようがない。うん。 -0 なら、type に nptr が入っているので、それのfiled listを探せば良い。 - -やっぱbit filedしないとだめか。どうするのかな。type の拡張? - -bit field 実装したくないよ〜 - -まぁ、構造体の代入と同じような形にすれば良いわけだけど。 - -bit field の初期化ってのもあるのか。(うげ〜) - -うーん、やっぱ、果てないな。 +c荐 typedef struct 緇吾c潟宴潟障 +緇 struct def typedef ャ +0 type nptr ャcсfiled list「域 + +cbit filedtype ≦宍? + +bit field 絎茖 + +障罕篏篁eャ綵≪域 + +bit field c() + +若c宴 ASSOP, PREINC, POSTINC.... -まぁ、 +障 BASSOP, BPREINC, BPOSTINC.... -でもいいんだけど。 +с Sun Jun 20 20:21:38 JST 2004 -どうも、mc-parse に、mc-codegen に相当する部分がかなり入り込んでいる -みたいだね。これを移すのはめんどくさいが... binop とか、もともと -mc-codegen にあるべきものなのか。 - -でも、これをしないと、構文に対応した構文木を取れないわけか。 -inline で、構文木を再評価する場合もあるからなぁ。再評価した -場合に、構文木レベルで変更するべきなのか、コード生成レベルの -木でやるべきなのか、という問題もあるわけか。 - -macro も分割した方が良いね。 +mc-parse mc-codegen 後ャ莨若с +帥腱祉... binop +mc-codegen 鴻 + +с罕絲上罕 +inline с罕荅箴<翫荅箴< +翫罕у眼鴻潟若 +с鴻馹 + +macro 蚊鴻 Mon Jun 21 00:29:12 JST 2004 -mc-tree は、もう時代遅れ。切り離した方が良い。 -conv も、だめなんじゃない? - -なんか、随分、変えちゃったな。動かすのが大変そう。 - -できるだけ static にするんだけど... - mc-codegen からだけ参照される mc-parse.c のextern -ってのが C では表現できない。一旦、extern すると使われてなくても -何にも言わなくなるから。 - -mc-codegen の使っている変数のうち、どれがstaticなんだが検出できない。 - -emit_data_closing の場所が変。 +mc-tree 篁i≪鴻 +conv ? + +紊<c紊у + +с static ... + mc-codegen с mc-parse.c extern +c C с茵憗с筝extern 篏帥 +篏荐 + +mc-codegen 篏帥c紊違<static罎冴с + +emit_data_closing 贋紊 Tue Jun 22 01:05:09 JST 2004 -ようやっとリカバリできたよ。 +cс local scope { int hoge; ... { int hoge;... }} for(int i=0; hoge...) -は、やらざるを得ないだろうね。 +緇 Tue Jun 22 06:49:55 JST 2004 -bit-field の alignment は、アーキテクチャによって任意って -感じだな。 +bit-field alignment ≪若cc篁紙c + MIPS @@ -5107,44 +5107,44 @@ 2:00000000 00000000 ffffffff ffffff00 00000000 00000000 00000000 00000000 2:00000000 00000000 00000000 00000000 ffffffff ffffff00 00000000 00000000 -実装は、mc-parse.c では決められないのか。 - -まず、 - boundary を含めて読み込み (必ず指定された型のサイズに収まる) -次に、 - 読み込んだ部分の指定されたbitを置き換え - まず 0 にして、置き換えと or を取る(?) -そして、 - 書込 -って感じですかね。64bit はめんどくさいな〜 - -ってことは、 - and mask をつくって、or mask をつくって、 - 逐次実行 -って感じですか。はぁ〜。 +絎茖mc-parse.c с羆冴 + +障 + boundary 茯粋昭 (綽絎泣ゃ冴障) +罨< + 茯粋昭絎bit臀 + 障 0 臀 or (?) + + 梧昭 +cс64bit + +c + and mask ゃcor mask ゃc + 罨≦茵 +cс -BIT_FIELD のsizeをやらないと、初期化ができない。 +BIT_FIELD sizeс Wed Jun 23 14:06:10 JST 2004 -(昨日は飲みすぎ...) - -emit_data は、mc-codegen にあるべきだよね。 - -bit_field の大域変数の初期化ができない。いったん、どっかに -貯めないとだめ。assign_data level? - -なんか、assign_expr の 引数 type が大域変数を上書きしてました。 -それが恥ずかしいバグの原因だったのか。 +(ャ蕋蚊帥...) + +emit_data mc-codegen 鴻 + +bit_field 紊у紊違сcc +莢assign_data level? + +assign_expr 綣 type 紊у紊違筝吾障 +ャ違c Fri Jun 25 00:00:46 JST 2004 -なんか、Union のテストコードを書いてない気がする。 -Union は、間違ってました。 - -bit field はできました。 - -なんか MIPS のgccは、bit field にバグあるみたいだね。 +Union 鴻潟若吾羂 +Union c障 + +bit field с障 + + MIPS gccbit field 違帥 Fri Jun 25 11:30:30 JST 2004 @@ -5163,17 +5163,17 @@ --- > free_lvar(cadr(n)); -なんだけど、lassop あたりでも問題ありそう。 - -bassop を呼び出す BPOSTINC で、post の処理をさぼってます。 - -っていうか、bassop は間違っているじゃん。 - -bassign だったら、読み出してbit replace で良いんだが、 -op をかけるんだったら、bit_field として読み出して、 -一旦、整数値にしてから計算しないとだめ。 - -post の処理は複雑なので専用のを書いた方が良い。 +lassop с馹 + +bassop 若喝冴 BPOSTINC сpost 若c障 + +cbassop c + +bassign c茯水冴bit replace ц +op cbit_field 茯水冴 +筝贋医ゃ荐膊 + +post 茲у吾鴻 if (simple) { tmp_var = bit_field @@ -5187,80 +5187,80 @@ } if (post) tmp_var; -ですかね。 +с Fri Jun 25 14:49:57 JST 2004 -もう少し複雑だった。でも、終りました。codegen level で -終るのは良いよね。 - -まぁ、bit-field も、 - - constant assign の時の最適化 (and/or mask の計算) - 1 bit の時の特別命令を使う? - bit.r == 1 を、and 0x100 にコンパイルする - -とかいろいろやることはあるけど、意味ないよな... +絨茲cс腟障codegen level +腟 + +障bit-field + + constant assign (and/or mask 荐膊) + 1 bit 劫ュ巡擦篏帥? + bit.r == 1 and 0x100 潟潟ゃ + +潟... Sat Jun 26 16:32:57 JST 2004 -で、local 変数の扱いだけど.... - - 大域変数、局所変数、タグ名、フィールド名、型名、ラベル - -とあるわけだよね。で、スコープを任意にしたいわけだ。 - - nptr を、局所->局所->大域 にlinkするようにすれば良い - -malloc するようにする? それともlinkするようにするか。 - -うーん、hash 計算無しで lsearch しているところがあるな。 -hash は別関数になってないし。 +сlocal 紊違宴.... + + 紊у紊違絮紊違帥医c若 + +с鴻潟若篁紙 + + nptr 絮->絮->紊у link域 + +malloc ? link + +若hash 荐膊< lsearch +hash ラ∽違c Sun Jun 27 10:58:04 JST 2004 -大した変更してないけど、ia32 code がバグった。 +紊с紊眼ia32 code 違c Sun Jun 27 14:52:59 JST 2004 -is_memory のバグでした。 - -そういえば、double register pair のparallel assignmentって -やってる? - -うーん、やっぱり、codegen が register pair を知ることが出来 -るように、list2(LREGISTER,high,low) みたいな形にしたいよね。 -なんで、だめなんだったっけ? +is_memory 違с + +違double register pair parallel assignmentc +c? + +若c宴codegen register pair ャ堺 +list2(LREGISTER,high,low) 帥綵≪ +сcc? list2(DREGISTER,list2(REGISTER2,high,low)) list2(LREGISTER,list2(REGISTER2,high,low)) list2(FREGISTER,list2(REGISTER,high)) -とか? +? list3(REGISTER,1,reg); list3(DREGISTER,2,reg,reg); list3(FREGISTER,1,reg); -かな。 - -いいんだけど、変更多くない? でも、use_reg とかの複雑さを考えると、 -そうした方がいいんじゃないかなぁ。 - -でも、変更多いよね。利点としては、regs[] を lregster 分取らなくて -すむことかな。でも、本当に簡単になるのかな? - -code_*() でレジスタを使っている部分を修正する必要があるから、 -かなり大きな変更になるのか。でも、code_*() に引き渡す変数と -構文木中の要素が同じになるのは重要だよね。 - -構文木でのレジスタ変数のユニークさを維持しないと、 + + +紊翫? сuse_reg 茲 +鴻 + +с紊翫鴻regs[] lregster +с綵膂≦? + +code_*() с吾鴻帥篏帥c篆罩c綽荀 +紊с紊眼сcode_*() 綣羝<紊違 +罕筝荀膣荀 + +罕с吾鴻水違若膓 if(r!=reg) printf("\tmr %s,%s\n",register_name(reg),register_name(r)); return; -みたいなのが困るね。ということは reverse poiner がいるってこ -とか。 - -overlap を見るときに、自分自身が overlap していても問題ない。 -ただし、重ならないようにコピーしないとだめ。そうしないと、 -巨大な構造体を二回コピーするはめになる。 +帥違 reverse poiner c + + +overlap 荀荳 overlap 馹 +潟若 +綏紊с罕篏篋潟若 |---||--------------| @@ -5270,35 +5270,35 @@ |--------------||---| -みたいな感じだね。これは、まだ実装してないんだよね。 +帥障絎茖 Sun Jun 27 21:06:28 JST 2004 -やっぱり、name/namebuf 関連は書き換えるんでしょ? - -まず、get_name/get_string は、cheap 上にコピーする。 -で、new_def でなかった時には cheap を元に戻す。 -name, namebuf は、なくす。 +c宴name/namebuf ∫c吾с? + +障get_name/get_string cheap 筝潟若 +сnew_def сc cheap 祉 +name, namebuf string hash (oblist) -> hash table -> nptr -> macro/reserve/local/global/typedef etc -となる。local nptr は、local_scope list に登録し、 -scope を抜けるときに消す。 - -get_name/string でt既に登録してしまう。gserach/lsearch/msearch -は、登録されたhash からのlinked list で良い。gsearch も linked -list にする必要がある。nptr には、next をつける? - -あぁ、ARM には fpp はないのね。いや、GBAにはないけど、 -Zaurus にはあるっていうパターン?! - -ってことは... MIPS と PowerPC を足して二で割ったような実装 -をしないといけないのか。うーむ。 - -macrobuf は、cheap で共有できるはず。そうすれば、linebuf 以外は -一つになる。linebuf も一緒にできるかな? それは、無理なんだけど... -cheap なんだけど、extendable にするためには... +local nptr local_scope list 脂蚊 +scope 羔 + +get_name/string t≪脂蚊障gserach/lsearch/msearch +脂蚊hash linked list цgsearch linked +list 綽荀nptr next ゃ? + +ARM fpp GBA +Zaurus c帥若?! + +c... MIPS PowerPC 莇潟篋у蚊c絎茖 +若 + +macrobuf cheap у掩с違linebuf 篁ュ +筝ゃlinebuf 筝膩с? ∞... +cheap extendable ... struct cheap { char *cheap; @@ -5306,73 +5306,73 @@ struct cheap *next; } -として、これへのポインタをcheapとして用いれば良い。cheapp とかが -あるので、やっかいだが.. +吾ゃ潟帥cheap域cheapp +сc.. Mon Jun 28 20:18:03 JST 2004 -あのさ、それをやっちゃうと、chptr も cheap を参照するんだから、 -そっちも、直さないとだめじゃん。 - -いや、それはない。mappend で、必ず cheap chunk に収まるはず -だから。結構、無駄が出る可能性もあるけど、別にいいんじゃない? -巨大に展開した macro の最後の方だけ cheap からはみでるとか。 -だからどうなの? 2M とかに展開されるわけでもないだろ? - -mappend で chunk boundary にかかると copy で append を -壊してしまう。どうせ、cheap rest してから、chptr を -切替えるんだからいいんだけどさ。 +c<chptr cheap с +c<眼 + +mappend с綽 cheap chunk 障 +腟罕♂冴醇сャ? +綏紊с絮 macro 緇鴻 cheap 帥с +? 2M 絮с? + +mappend chunk boundary copy append +紕障cheap rest chptr +帥 Tue Jun 29 17:36:36 JST 2004 #define car(a) heap[a] -だけど... +... typedef struct tree { int id; int next; } TREE; -として、 + #define as_tree(a) (TREE)(heap[a]) TREE t = tree(a); if (t.id == HOGE) {.... -っていうようにアクセスする手はあるよね。 +c≪祉鴻 #define tree(a) ((TREE)(heap[a])) if (tree(a).id == HOGE) {.... -でもいいか。 - -conservative に変えたいのか、drastic に変えたいのか -どっちだよ。 - - -name space は、tag, macro, その他? typename は重なっていてはいけない。 -field も別だけど。sc で区別するわけだけど... - -hash_search が返すのは name spcae assoc だよね。 - -巨大なname があると、 macro 展開された chptr を上書きする可能性がある。 +с + +conservative 紊drastic 紊 +c< + + +name space tag, macro, 篁? typename c +field ャsc у阪ャ... + +hash_search 菴 name spcae assoc + +綏紊сname macro 絮 chptr 筝吾醇с cheap->ptr chptr |--------|-name1-| |-name2-|pppppppp| cheap->ptr chptr |--------|xxxxxxx| |-name1-name2-|--| -先までコピーしてやればいいんだけど... +障с潟若違... chptr |--------|xxxxxxx| |-name1-name2-|pp| |pppppp| -でも、chptr は、boundary にかかることはないんだから、こういうことは -起きないんじゃないの? chptr はかからなくても、cheap->ptr は、かかる -可能性があるか。 - -これのコピーを実装して、mappend ではpage 転送しないようにすれば、 -mappend で reset_cheap しても良い。 +сchptr boundary +莎激? chptr cheap->ptr +醇с + +潟若絎茖mappend сpage 荵∫違 +mappend reset_cheap Thu Jul 1 20:28:49 JST 2004 { int hoge; { int hoge; ....} } -だけど。。。 - -異なるレベルだってのをどうやって見つけるの? define case は、 -わかるから大丈夫か。なんかオプションいるの? + + +違cc荀ゃ? define case +紊т紊激с潟? hash -> name_space -> nptr global (typename, global, function) @@ -5383,86 +5383,86 @@ tag field -であるべきだよね? +с鴻? Fri Jul 2 06:46:27 JST 2004 -こんなに変更しちゃって、動くわけないよね。 - -単体テスト書く? +紊眼<c + +篏鴻吾? cheap hash -ぐらい? - -やっぱり、大変だわ。あと、もう少しだとは思うけど。 +? + +c宴紊у絨 Fri Jul 2 23:38:14 JST 2004 -あと、もう少し.. - -セルフコンパイルのバグがとれないよ。 - -もしかすると、void fuga(b,d,e,f) { return hoge(a,b,c,e) ; } -っていうプログラムで完全に、tail recursion するなら、 -CbC と、おんなじなんじゃない? (条件は?) - -その方が簡単か? いや、関数呼び出しと互換性を維持しないといけない -ので、やっぱり、こっちの方が難しい。レジスタのセーブとかあるし。 - -そうか、I2C, I2S, U2UC, U2US が必要なみたいだね。それに応じて、 +絨.. + +祉潟潟ゃ違 + +void fuga(b,d,e,f) { return hoge(a,b,c,e) ; } +c違уtail recursion +CbC ? (>散?) + +鴻膂≦? ∽医若喝冴篋с膓 +сc宴c<鴻c吾鴻帥祉若 + +I2C, I2S, U2UC, U2US 綽荀帥綽 code_i2c code_i2s code_u2uc code_u2us -がいるのか。 - -endian 特有の問題なのか。じゃぁ、hash のバグとは関係ないのね。 - -K&R argument が redefined 扱いで、新しい変数になって -しまう。 + + +endian 号馹hash 違≫ + +K&R argument redefined 宴с違紊違c +障 Sat Jul 3 15:16:50 JST 2004 -ようやっと recovery できました。 - -global heap の拡張は難しいよね。特に、heap の使い方が -割りと雑な今は難しい。nptr,heap,local ともinteger で -アクセスするならともかく。 - -また、くだらん、gcc の拡張か... 使うなよ... __label__ - -やっぱり、型名は大域変数とは別な名前空間だよな。 - -まぁねぇ。 code が、結構、コンフリクトしているな。ま、そうだけど。 - -三項演算子の一部を省略できるのか。 - -いくつか問題はあるが、kernel source は、通りました。 +c recovery с障 + +global heap ≦宍c鴻heap 篏帥鴻 +蚊篁cnptr,heap,local integer +≪祉鴻 + +障gcc ≦宍... 篏帥... __label__ + +c宴紊у紊違ャ腥咲 + +障 code 腟罕潟潟障 + +筝羲膊絖筝ャс + +ゃ馹kernel source 障 Sun Jul 4 19:17:02 JST 2004 -arg の中に関数があって、それがさらに関数引数を持っていると、 -それがdefineされてしまう。それが使われるとEXTRN1になって、 -未定義関数になってしまう。 - -とりあえず、こんなものかな。 - -あとは、 +arg 筝∽違c∽医違c +define障篏帥EXTRN1c +絎臂∽違c障 + + + + inline c2cbc converter -ですね。 - -inline は高く付きそうだけど。 - -inline をマクロで実装するのは比較的簡単なんだよね。だけど、 -c2cbc を考えると、やっぱり、構文木で実装するべきでしょ? - -global heap は拡張可能じゃない? local heap がない時に、 -やばそうだったら拡張してしまう。realloc でいいし。 -pointer とっているのは scope だけじゃないか? - -うーん、やっぱり、global heap の拡張は、それほど単純じゃない -みたいね。 +с + +inline 蕭鋌 + +inline у茖罸莠膂≦ +c2cbc c宴罕у茖鴻с? + +global heap ≦宍純? local heap +違c≦宍障realloc с +pointer c scope ? + +若c宴global heap ≦宍祉膣 +帥 41c41,43 @@ -5488,25 +5488,25 @@ > if (!heap) heap = (int *)malloc(HEAPSIZE*sizeof(int)); > if (!heap) error(MMERR); -ぐらいではぜんぜんだめ。 - -別に問題なくできるじゃん。なにやってんだ? - -LDECL の中間 nlist って本当にいるの? こんなのがあるから、中 -間の nptr を一つ無駄にしているんだよね。make_local_scope だ -けで良いんじゃないかな。macro は、それで動いているわけだし。 - -なんか、struct が、ちょっとだめなみたいだな。type名がlocal -になってしまうから? - -なんか、type と tag をglobalにするので通ったけど... scope -に関しては、もう少しテストを書かないとだめだな。 +с + +ャ馹сc? + +LDECL 筝 nlist c綵? 筝 + nptr 筝ょ♂make_local_scope +цmacro у + +struct <c帥typelocal +c障? + +type tag globalчc... scope +≪絨鴻吾 Mon Jul 5 14:11:07 JST 2004 -local label ね。まぁ、簡単なんだけど... - -lazy flag で、 +local label 障膂≦... + +lazy flag с do if make l = listN(IF,cond,then,else) if(lazy) @@ -5514,79 +5514,79 @@ else eval_if l; eval_if -みたいな感じ? +帥? Tue Jul 6 17:46:50 JST 2004 -type と tag を大域にするんじゃなくて、tag だったら大域、 -type は、LTDECL のみで局所っていうようにするべきだよね。 - -static が global になっちゃってるな。 - -あ、いけない、なんか壊しちゃったよ。。。 - -bit field って +type tag 紊уtag c紊у +type LTDECL 帥уc鴻 + +static global c<c + +紕<c + +bit field c e4 = rvalue_t(e2,type); g_expr(assign_expr0(e2, list4(BFD_REPL,e4,e3,t), type,type)); -なんだけど、これだと、 - e2 を出力して、push して、 - e2 をもう一回読み込んで load - そして replace - pop して assign -って感じなんだよな。別にいいんだけどさ。 + + e2 阪push + e2 筝茯粋昭 load + replace + pop assign +cャ e2 load replace store -っていうようにしたいんだけど。 - -でも、この部分って long long も通っているから変更するとなると -量が多いんだよな。 - -GVAR + offset が、list2(INDIRECT,list2(ADD..)) に展開されるので、 -simple の方にもっていかれない。ということは、GVAR を GVAR + offset -という構成にした方が良いってことだよね。 - -list2(GVAR,nptr) なんだけど、これを、list2(GVAR,nptr,0) -にすれば良い? まぁねぇ。あんまり使われないとは思うけどね。 -実際、出るコードは変わらないし。 - -結構、複雑。複雑すぎるんじゃないの? +c + +сc long long c紊眼 +紊 + +GVAR + offset list2(INDIRECT,list2(ADD..)) 絮с +simple 鴻cGVAR GVAR + offset +罕鴻c + +list2(GVAR,nptr) list2(GVAR,nptr,0) +域? 障障篏帥 +絎冴潟若紊 + +腟罕茲茲? Wed Jul 7 23:19:35 JST 2004 -できたけど、mips の register usage がおかしい。もっと -レジスタを使えるはず。 - -save_stack で、regisiter を解放するのを忘れてました。 - -parallel_rassign では、一つ解放したら、そこを他の依存ループ -を解決するのに使うのが良い。けど... - -どうも、余計に extsb しているみたいだな。 - -本来は必要な時に変換するべきだよね。でないと、 +сmips register usage c +吾鴻帥篏帥 + +save_stack сregisiter 茹f障綽障 + +parallel_rassign с筝よВ障篁箴絖若 +茹f浦篏帥... + +篏荐 extsb 帥 + +ャ綽荀紊鴻с lbz extsb stb -しちゃうから。 +< Thu Jul 8 02:31:03 JST 2004 -ARMは、どうもadd, sub は、8bit 幅で定数を持てるみたいね。 - -table がmax-min を16bit だと仮定しているみたい。倍数を -含んでいるときは、その限りでない。 +ARMadd, sub 8bit 綛у違帥 + +table max-min 16bit 篁絎帥違 +сс Fri Jul 9 14:45:56 JST 2004 -LDECL は、disp < 0 - -const も実装しないといけないんだよな〜 - -arm は、大域変数を、 +LDECL disp < 0 + +const 絎茖 + +arm 紊у紊違 ldr r3, .L28+88 .... .L29: @@ -5598,25 +5598,25 @@ .word s2 .word us1 -みたいな形で間接参照するわけだけど、参照した順にリストに格納しないと -だめ? 変数表に格納したい所だが... make scope で出来ないかな? -linear list で持ってもいいんだけど。 - -ptr_cache の方でリストを持てば? - -なんか、add # の意味が良くわからないよ。別に常にメモリ -参照で問題はないんでしょ? - -良くわからないけど、 - 8bit 幅の定数で、シフトが2ずつ -みたいな感じ? - -でいいけど、どんなアルゴリズムで生成するんだよ。 - - 8bit mask を2ずつシフトして、 - 残りが取れるかどうかをみる - -えーと、16x8x8 ぐらいのオーダ? +帥綵≪ч・сс鴻主 +? 紊域;主... make scope у堺ャ? +linear list фc + +ptr_cache 鴻с鴻? + +add # 潟ャ絽吾<≪ +су馹с? + + + 8bit 綛絎違с激2 +帥? + +с≪眼冴х + + 8bit mask 2ゃ激 + 罧帥 + +若16x8x8 若? for(sign=-1;sign<=1;sign+=2) { if (sign==1) d = c; else d = -c; for(i=0;i<32;i+=2) { @@ -5639,13 +5639,13 @@ found: if (sign==1) emit_add(im,jm,km); else emit_sub(im,jm,km) -ですかね。1024 ループか。。。 const 毎に? - -しかも、その中で、もっとも短い命令を探さないとだめなのか。 - -pointer offset も、そうなのかな? (その可能性はあると思う) - -12*8*4 = 384 ぐらいか(最悪で) +с1024 若 const 罸? + +筝сc巡擦「 + +pointer offset ? (醇с) + +12*8*4 = 384 () sub mask8 { my ($d,$bit) = @_; @@ -5697,58 +5697,58 @@ else { print "emit const $c\n"; } } -ぐらいでした。 +с Sun Jul 11 12:54:26 JST 2004 -やっぱりlarge offset はうまく動いてないみたいね。 - -local global table は、12bit offset(+sign 1bit) だから4096/4 -で1000命令毎には出力する必要がある。しかも、既に出力されてい -るものは、前のを使う必要がある。なるほどね。っていうことは、 -テーブルにそういうフラグをつけないとだめか。(それぐらい -アセンブラでやってよ〜) - -すべてのprintfにcounter をつければ良いわけだけど、いくつかは -問題があるだろうな。ちょっと量多いしね。 - -ARMには short ってないのか。short を多用しているプログラムは -だめなのね。 - -(でも、どっちかって言うとテスト環境を作る方が難しそう) - -slとかipとか思い入れがありそうなレジスタの名前も大した意味がある -わけではないらしい。 - -ARMって、なんかsigned char とunsinged char の区別がないな。 - -lvar offset が、ちょっとめんどくさいかな。 -constant が決まってないから、せっかく作ったcode_add -が使えない。いや、決まるのかな? +c宴large offset 障帥 + +local global table 12bit offset(+sign 1bit) 4096/4 +1000巡擦罸阪綽荀≪阪 +篏帥綽荀祉c +若違ゃ( +≪祉潟сc) + +鴻printfcounter ゃ域ゃ +馹<c鎀 + +ARM short cshort 紊違 + + +(сc<c荐鴻医篏鴻c) + +slipャ吾鴻帥紊с潟 +с + +ARMcsigned char unsinged char 阪ャ + +lvar offset <c +constant 羆冴障cc鋎ccode_add +篏帥羆冴障? Sun Jul 11 20:37:20 JST 2004 -やっぱり、local variable のオフセットがその場で定数でないのは -まずい。 - - 負の値 +c宴local variable 祉眼у違с +障 + + 莢 fp <-------| +------+------------------+ <----lvar_offset---> -なのがまずいんだよね。 - - 負の値 +障 + + 莢 fp-------> | +------+------------------+ <----lvar_offset---> -にすれば良いだけだよね。なんけど、def で pre decrement しているが -まずい。が、<0 でないとまずいので、単純な post decrement でもだめ。 - -でも、これ修正量が多いよね。 - - 負の値 +域def pre decrement +障<0 с障с膣 post decrement с + +с篆罩i紊 + + 莢 fp-------> sp-----> +------+------------------+ callee <----lvar_offset---> caller @@ -5756,9 +5756,9 @@ <------> pre known offset ----> -と、直せば良い。 - -ん、だが.... +眼域 + +.... <------r1_offset------------------------------> <-lvar_offset-------> @@ -5768,18 +5768,18 @@ lvar>0 lvar<0 lvar>0x1000 0000 r30 r1 -とするのは、PowerPC では変更が大きすぎる。レジスタセーブする場所 -が良くわからないし。 - -もしかして、register save 領域は固定?! +PowerPC с紊眼紊с吾鴻帥祉若贋 + + +register save 阪?! Mon Jul 12 05:35:33 JST 2004 -うーん、やっぱり、難しいよな... 何故か、printf が local variable -を壊してしまう。 - -register save 領域は固定なわけきゃないだろ。最初からやり直して、 +若c宴c... 篏printf local variable +紕障 + +register save 阪眼 function call stack frame <-------r1_offset------------------------------> @@ -5790,30 +5790,30 @@ reg_save disp max_func_args*SIZE_OF_INT lvar>0 lvar<0 lvar>0x1000 0000 -ということになりました。frame の設定のところだけ無条件に32bit add -になったが仕方ないな。これだと、callee arg は不定オフセットにならざる -を得ない。reg_save が最後まで決まらないから。 - -はぁ。大変なのはPowerPCだけで、MIPSとia32 は、そのまま動くというのが -わかりました。 +障frame 荐絎≧>散32bit add +c篁鴻callee arg 筝絎祉 +緇reg_save 緇障ф浦障 + +紊уPowerPCсMIPSia32 障上 +障 Mon Jul 12 12:54:14 JST 2004 -が、結局、MIPSを $fp からの裸オフセットにするのは苦労したね。 - .frame $fp じゃなくて、 .frame $sp にすると動くのか。 -あと、goto 関連は、 +腟絮MIPS $fp 茖吾祉眼 + .frame $fp .frame $sp +goto ∫c code_environment code_fix_frame_pointer leave -の三つを直さないとだめなのね。 - -この変更は、ARMのオフセット計算を固定オフセットで行うために -やっているんだけど、ARMのレジスタセーブを固定領域にすれば、 -あるいは、どこかに追いやれば、callee arg も含めて固定に出来 -るはず。 - - -なんか浮動小数点レジスタは f4 だけみたいね。 +筝ゃ眼 + +紊眼ARM祉荐膊阪祉ц +cARM吾鴻帥祉若阪違 +菴純違callee arg 阪堺 + + + +羌絨亥鴻吾鴻帥 f4 帥 mov ip, sp stmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc} @@ -5823,9 +5823,9 @@ ldmea fp, {r4, r5, r6, r7, r8, r9, sl, fp, sp, pc} .Lfe1: -まるで、6809 の PSHS X,Y,D だね。PULS X,PC とか。 - -なんだけど、これだと、 +障с6809 PSHS X,Y,D PULS X,PC + + <-------r1_offset------------------------------> <------------lvar_offset0------> @@ -5835,73 +5835,73 @@ reg_save disp max_func_args*SIZE_OF_INT lvar>0 lvar<0 lvar>0x1000 0000 -にならざるを得ない。となると、どっちかは、不定オフセットだな。 -ま、callee 側でしょう。ま、これに習うか。あるいは、ポインタ -で指してもいいんだよね。ていうか、reg_save に関わらず決まった領域 -をとっちゃえばいいんじゃない? 大した量じゃないし。浮動小数点 -レジスタも一つだしね。 - -もう少しかかりそうだね。 +緇c<筝絎祉 +障callee 眼с障膺ゃ潟 +фreg_save ≪羆冴障c +c<違? 紊с羌絨亥 +吾鴻帥筝ゃ + +絨 Wed Jul 14 12:45:01 JST 2004 -やっぱり浮動小数点ありとなしを一緒に実装するのはめんどい。 - -あれ、? mc-code-mips.c の +c宴羌絨亥鴻筝膩絎茖 + +? mc-code-mips.c rexpr_bool(int e1, int reg) { int e2,reg0; int op = car(e1); return 0; -ってなんだ? せっかく作ったのに? - -ちょっとバグってました。でも、なんでだろう? logic miss がある? - -drexpr_bool for MIPS は作ってないみたいね。long long はさすがに -大変そうだし。 - -double/long long の定数だけどさ、 - local const table に連続して入れる - 大域領域に初期化して、そこへのポインタをlocal const table に入れる -でいいんだけど... 前者だと、searchがめんどい。後者だと、double load -になるので、なんか嫌。たまたま一致した0を使えないのもなんかね。 - -adr なんて言うのがあるのか。adr して ldmia ってなんか変。mvfs #0 -なんてのがあるのか。0,1,10 があるのがわかるけど... - -float の switch ってあるの? - -(はぁ、めんどくさい... 一週間かかってるし...) +c? c鋎c? + +<c違c障сс? logic miss ? + +drexpr_bool for MIPS 篏c帥long long +紊у + +double/long long 絎違 + local const table gャ + 紊у吾ゃ潟帥local const table ャ +с... search緇double load +с絆障鞘眼0篏帥 + +adr 荐adr ldmia c紊mvfs #0 +0,1,10 ... + +float switch c? + +(... 筝演c...) Sun Jul 18 20:45:48 JST 2004 -なかなか終らないね。GBAとLinux Zaurus と両方だからな。 -(やっぱ ARM に手をつけたのは失敗でした) - -alloca の引数が定数の場合をやってないね。 - -まだ、先長そう。でも、やりたかったんだから、仕方ない。 - -浮動小数点レジスタ一つっての嘘だな。レジスタは使うたびに、 -毎回セーブするみたいね。 +腟GBALinux Zaurus 筝≧鴻 +(c ARM ゃ紊掩с) + +alloca 綣違絎違翫c + +障激сc篁鴻 + +羌絨亥鴻吾鴻推ゃc吾鴻帥篏帥潟 +罸祉若帥 Wed Jul 21 13:51:56 JST 2004 -さて、inc_inst を、どうやっていれるか.... - -copmpile error は取ったけどさ。 +inc_inst c.... + +copmpile error c Fri Jul 23 13:28:24 JST 2004 -なんか頭が回らないな。 + Sat Jul 24 19:27:55 JST 2004 -うん。mc-arm で構文エラーがでるのは、なんかを壊しているから -なんだけど、それを直接にデバッグするのは、あんまり良い方法 -じゃないんだろう。この程度のエラーを自動的に見つけてくれるのが -欲しいよ。 +mc-arm ф若с紕 +贋・違障号 +腮綺若荀ゃ +罨蚊 Tue Jul 27 13:45:21 JST 2004 @@ -5920,93 +5920,93 @@ mov r8, sl .L163: -これねぇ。 - -まぁ、でも、なんとなく戻って来たか。 - -ぼろぼろだなぁ。論文も書かなきゃいけないのに。 + + +障с祉cャ + +若若茫吾 Thu Aug 12 14:15:40 JST 2004 -ちょっと間あいたね。ARMも、もう少しだけど、c2cbc の方を先に -しないと。C++ からの変換はどうする? cfront って動くのかな? - -(あんな論文書いちゃって...) +<cARM絨c2cbc 鴻 +C++ 紊? cfront c? + +(茫吾<c...) Mon Aug 16 17:27:17 JST 2004 -COND は、できるだけ CREG_REGISTER を使うようにしたけど、 -アドホックだね。(まぁねぇ) - -CONDのテストが入ってないなぁ。 +COND с CREG_REGISTER 篏帥 +≪(障) + +COND鴻ャc Tue Aug 24 15:39:27 JST 2004 -register 割当てが変。ほとんどをregister var に割り当てるように -なっているけど、もっとtmpがないと計算できないよね。 +register 峨紊祉register var 蚊綵 +cctmp荐膊с Thu Sep 2 20:46:56 JST 2004 -そういえば Input register をtmpに使わないのはなんで? - -順調にバグ取りは進んではいるんだけど... + Input register tmp篏帥? + +茯帥医蚊с... Sat Sep 4 18:04:40 JST 2004 -INPUT/REGISTER が double int register と float register -で一貫してない。 +INPUT/REGISTER double int register float register +т莢 Wed Sep 8 01:08:35 JST 2004 -lvar_offset_label, r1_offset_label っているの? fp を -使ってるんだから、いらない説もあるが.. - -局所変数を負のオフセットでアクセスし、関数呼び出しをsp オフセット -で積むなら、いらないはず。 +lvar_offset_label, r1_offset_label c? fp +篏帥c茯.. + +絮紊違莢祉с≪祉鴻∽医若喝冴sp 祉 +х Sat Sep 11 15:13:33 JST 2004 -やっぱり、CSE ぐらいやるべきじゃない? マクロで生成されるとねぇ。 +c宴CSE 鴻? х if (o==H1||o==H2|o==H3) -みたいなものね。まぁねぇ。 - -でも、そうすると、asm がなぁ。でも、そうすると elimination -もやりたいよね。 - -それよりは、inline が先か。 +帥障 + +сasm с elimination + + +inline Tue Sep 14 14:36:15 JST 2004 -arm lvar のlarge offset をなんとかしないと。lvar intro -でなくてもできるはずだよね。 - -だけど、ptr cache と const list -を一般的に一緒にできない? 両方ともconstだしねぇ。 - -そうか、ptr cache は外にでちゃっていて、nptr を前提にしている -ので、ちょっと難しい。uniq nptr を当てはめてやればよいみたい -だけど... +arm lvar large offset lvar intro +сс + +ptr cache const list +筝筝膩с? 筝≧鴻const + +ptr cache 紊с<cnptr +с<ccuniq nptr 綵違帥 +... str r1, [fp, #0+.L3] str r2, [fp, #4+.L3] -なんだけど、L3 が巨大なのでだめになってしまう。(まぁ、そうだよね) -まぁ、でも、L3 は巨大にはならないんじゃない? +L3 綏紊ссc障(障) +障сL3 綏紊с? Wed Sep 15 16:50:46 JST 2004 -basic のレジスタに載った引数をスタックに戻すところがおかしい。 - - -そうか、C++ のmaglegationをいれれば、C++ とは接続可能。 -だけど。 +basic 吾鴻帥莠c綣違鴻帥祉 + + +C++ maglegation違C++ ・膓純 + Wed Oct 13 21:06:31 JST 2004 -mvn は1's complement で、sub は2's complement なみたいね。 -なので、8bit const の時におかしくなる。 - -32bit word のalignmentは4でなくてはならないらしい。 +mvn 1's complement сsub 2's complement 帥 +с8bit const + +32bit word alignment4с 0x20005cc <code_lvar_address+216>: str r0, [r11, -#22] (gdb) p $r0 @@ -6021,7 +6021,7 @@ $17 = 0xfc39bfff <Address 0xfc39bfff out of bounds> (gdb) quit -うーむ。 +若 Fri Oct 15 08:46:59 JST 2004 @@ -6029,20 +6029,20 @@ stmfd sp!, {fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #16 - str r0, [fp, #-16] 引数1 - str r1, [fp, #-20] 引数2 - str r2, [fp, #-24] 引数3 - str r3, [fp, #-28] 引数4 + str r0, [fp, #-16] 綣1 + str r1, [fp, #-20] 綣2 + str r2, [fp, #-24] 綣3 + str r3, [fp, #-28] 綣4 ... - ldr r2, [fp, #4] 引数5 + ldr r2, [fp, #4] 綣5 add r3, r3, r2 - ldr r2, [fp, #8] 引数6 - -そうか。レジスタの引数分はメモリには取られないで、局所変数側 -におかれるらしい。spは、stmfd で自動的に調製されるから、sub sp -は局所変数分だけ。fp の#4は戻り番地だけ? - -でも、それだと va_next が困るんだけど。 + ldr r2, [fp, #8] 綣6 + +吾鴻帥綣医<≪с絮紊医 +spstmfd ц茯粋純sub sp +絮紊医fp #4祉違? + +с va_next 違 Fri Oct 15 20:51:19 JST 2004 @@ -6055,16 +6055,16 @@ ldmia r1, {r1-r2} @ double bl printf -ってわけで、またがったdouble/longは、半分だけレジスタに置かれる -みたいね。 +cс障cdouble/long吾鴻帥臀 +帥 Sat Oct 16 19:12:31 JST 2004 -ま、それは直ったんだけど、register は、input register 以外は -全部 save しているみたいだな。frame あわせがめんどくさい。 - -cmf f4,#0が、f4 が初期化されてないと落ちるみたい。illigal instruction -っていうけど、 f4 の値によるのか? +障眼cregister input register 篁ュ + save 帥frame + +cmf f4,#0f4 純<帥illigal instruction +c f4 ゃ? fdecl_struct(int fntype) { @@ -6075,63 +6075,63 @@ struct_return = list3(list2(LVAR,str_ret.dsp),sz,type); caddr(fnptr->ty) = glist2(POINTER,caddr(fnptr->ty)); -なんだけど、これって save_input_register されてLVARになるわけ -だよね。def した時にはレジスタに割り当てられる可能性もあるよね。 -そういうことはないのか。 - -で、mc-parse.c で、 +c save_input_register LVAR +def 吾鴻帥蚊綵醇с + + +сmc-parse.c с if (struct_return) { ... gexpr(list4(STASS,rvalue(car(struct_return)),e,e1),0); -ってなるわけだよね。 - -で、mc-code-arm.c では、引数のdspが変更されるからだめなわけね。(スタック -に割り当てられてないから) - -だから、struct_return を save_input_register で修正する必要がある。 - -ARMでは、register割り当て分がstackに取られてないので、struct_push -で、その分をregister にcopyしないとだめ。でも、そうすると、受け側 -はどうするの? +c + +сmc-code-arm.c с綣違dsp紊眼(鴻帥 +蚊綵) + +struct_return save_input_register т信罩c綽荀 + +ARMсregister蚊綵stackсstruct_push +сregister copyс +? mov ip, sp sub sp, sp, #8 stmfd sp!, {r4, r5, fp, ip, lr, pc} sub fp, ip, #12 sub sp, sp, #96 -あ、こんなことやってるし〜 +c Sun Oct 17 13:13:00 JST 2004 -なんか long long に関しては、gcc の方が結構、間違っているなぁ。 - -signed char に関しては、ldrsb ってのがあるみたいね。なんで、 -arm-linux-gcc ではでないんだろう? + long long ≪gcc 鴻腟罕c + +signed char ≪ldrsb c帥с +arm-linux-gcc сс? Mon Oct 18 00:15:05 JST 2004 -self compile が通らない。他のテストを優先するべきか。 +self compile 篁鴻鴻 Mon Oct 18 20:25:16 JST 2004 -emit_copy の offset の扱いが一貫してないらしい。 -あと、 powerpc でr3,r4,r5 を使った状態でmemmoveが呼ばれるみたい。 - -うーん、やっぱり構造体をレジスタに割り振るのってかなりめんどう -なのね。特にネストする関数では... - -構造体はstack上で必ず align されるらしい。 - -ARM の bitield なんだけど |---====|=====|====----| と三つにまたがるのが -許されるみたいだね。char でも |--===|===--| があるし。ってことは、かなり -変えないとだめだてことだなぁ。あなあきでなければ、割りと正しく動くんだけど。 - -残りは、stdarg と bitfield だけか。まぁ、いいんじゃない? stdarg は、 -stdarg.h を自分で作れば良いみたい。 +emit_copy offset 宴筝莢 + powerpc r3,r4,r5 篏帥c倶memmove若違帥 + +若c宴罕篏吾鴻帥蚊c +鴻鴻∽違с... + +罕篏stack筝у align + +ARM bitield |---====|=====|====----| 筝ゃ障 +荐宴帥char с |--===|===--| c +紊с違蚊罩c + +罧stdarg bitfield 障? stdarg +stdarg.h т域帥 Tue Oct 19 11:12:16 JST 2004 -また、? のエラーか。 +障? 若 ## mode=(s==STRUCT?GSDECL:GUDECL); # 1287: : creg=r4 freg=f0 ldr r4, [fp, #4] @@ -6146,157 +6146,157 @@ .L714: ldr r7, .L709+4 str r0, [r7, #0] -テストルーチンが必要だね。 - -(MIPSとかPowerPCとか、だいぶ壊しちゃったみたい...) - -C との呼出しがずれている(やっぱりレジスタ?) mc と gcc のオブジェクトを -混在させるとだめだね。 - -浮動小数点関係の Endian がおかしい +鴻若潟綽荀 + +(MIPSPowerPC九<c帥...) + +C 弱冴(c宴吾鴻?) mc gcc 吾с +羞桁 + +羌絨亥拷≫ Endian Tue Oct 19 19:07:57 JST 2004 stmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc} -ってわけで、r0-r3 がinput registerで、r4-sl がregister_var とtmp -を兼ねるわけだね。r4から全部をregister_var に割り振ると破綻するだろう。 - -ってことは、一時変数ではなく積極的にレジスタ変数を使った方が -良いわけだけど... - -save_stack で register var はsave する必要はない。けど... - -longlong_lib で creg は RET_LREG になっていたけど、その外で、 -emit_pop_free する時に、その一部がRET_LREGと重なっていて、 -一緒にfreeされてしまう。そうすると、次のemit_popで、上書きされてしまう。 -なので、RET_LREGにしないで、lmove してしまうのが良い。 - -align がおかしい +cсr0-r3 input registerсr4-sl register_var tmp +若r4register_var 蚊雁胸 + +c筝紊違с霣罐窮吾鴻水違篏帥c鴻 +... + +save_stack register var save 綽荀... + +longlong_lib creg RET_LREG c紊с +emit_pop_free 筝RET_LREGc +筝膩free障罨<emit_popс筝吾障 +сRET_LREGсlmove 障 + +align Sat Oct 23 23:33:11 JST 2004 -struct を使った interface をregister にmapするかどうか。まぁ、 -難しいけどね。 - -やっぱりarmのbitfieldを合わせるのは止めた方がいいんじゃない? -long long 以外は、型を大きくして対応できる。long long のはみ出し -は、ちょっと対処できない。 +struct 篏帥c interface register map障 +c + +c宴armbitfield罩≪鴻? +long long 篁ュ紊с絲上сlong long 水冴 +<c絲上с a:8 => a0:4<<4+a1:4 a:8 = hoge => a0:4 = hoge<<4, a1:4 = hoge; -というように分解する? +茹c? Sun Oct 24 14:19:13 JST 2004 -code_frame_pointer と code_environment は同じなんですけど... - -巨大な構造体を並列代入すると、 - -自分自身が重なっている +code_frame_pointer code_environment с... + +綏紊с罕篏筝篁eャ + +荳c |----------| |----------| -では、 +с |----------| --copy-> |----------| - 他のものを代入 + 篁篁e <-copy-- |----------| -ってことになる。 - -これは、ちょっと手間が大きい。 +c + +<c紊с |--|---|---| |--|---|---| -と分割する(分割が細かくならない?) +蚊(蚊膣違?) |---|--|---| |---|--|---| -分割はだめだね。自分自身しか重なってないのだったらoverappable copy -する。 +蚊荳ccoverappable copy + |----------|----------|----------| |----------|----------|----------| -circular dependency はrecursive callする必要はないね。 - -なんか、構造体が一度、スタックにあげられてから戻されているみたい - -RSTRUCT って、本当にいるの? - -なんか、「まだ、emit_copy が間違っている!」 - -PowerPC は、code のレジスタに割り当てられた分のスタック上の引数 -を割り当てているな。なので、 +circular dependency recursive call綽荀 + +罕篏筝綺鴻帥祉帥 + +RSTRUCT c綵? + +障emit_copy c! + +PowerPC code 吾鴻帥蚊綵鴻帥筝綣 +蚊綵с ## code carg6(int i, int j,int k,int l,struct arg args0) ## goto carg3(args0,args0,i,j,k,l); -で、args0 のcopyが余計に出るね。 しかもずれ方が変。(*) - -無害ではあるんだが... - -でも、それでバグを見つけたわけか。 - -だいぶ、enbug しちゃったよ... - -emit_copy でmemmove する時には、offset は無視する。address + offset -から、reverse に address までコピーするという意味だから。 - -memmove は、一時レジスタを壊してしまうので、parallel assignment -の一時には普通のレジスタは使えない。 - -PowerPC の code segment で、引数が、CALLER_ARG つまり、関数呼び出し -のスタックと重なっている。code_disp_offset では調整できないらしい。 -今までは、(*) のせいで余計に一時変数を取っていたので顕現しなかった -らしい。 - -うーん... 一応、直ったけど... - -他のがどんどん動かなくなる... +сargs0 copy篏荐冴 鴻紊(*) + +≦潟с... + +сс違荀ゃ + +吟enbug <c... + +emit_copy memmove offset ∴address + offset +reverse address 障с潟若潟 + +memmove 筝吾鴻帥紕障сparallel assignment +筝吾鴻帥篏帥 + +PowerPC code segment с綣違CALLER_ARG ゃ障∽医若喝冴 +鴻帥ccode_disp_offset с茯炊眼с +篁障с(*) т荐筝紊違cч憗c + + +若... 筝綽眼c... + +篁... Mon Oct 25 03:13:48 JST 2004 -codegen で、jump しているのだけど、そこでは、offset -1 で、 -局所変数となる。局所変数をそのままcode_segment の引数に -しているらしい。 - -code_segment側でも、同じoffsetで処理するが、ARMの場合は、 -offset 0- -xx までは、register save が入る。それを書き潰し -してしまうらしい。goto 時に。で、戻ったときにerrorとなる。 -register は全部、save するので、差はわかっているので、それを -足せば良いだけだけどね。(これ、前もやったな...) +codegen сjump сoffset -1 с +絮紊違絮紊違障code_segment 綣違 + + +code_segment眼сoffsetуARM翫 +offset 0- -xx 障сregister save ャ吾羹違 +障goto с祉cerror +register save с綏cс +莇潟域(c...) Mon Oct 25 19:36:16 JST 2004 -なんか、できた。 - -まだ、レジスタ分のオフセットがcode_segmentで取られるのは直してない。 -ARM の bit field の穴塞ぎもね。 - -あとは、 +с + +障吾鴻水祉code_segmentу眼 +ARM bit field 腥翫 + + inline CbC2C C2CbC -だけだね。 + Wed Oct 27 08:48:37 JST 2004 -MIPSのallocaは、$spを移動するので、j の後の、code segement の +MIPSalloca$sp腱糸сj 緇code segement lw $gp,$L_41($sp) -はまずい。が、通常は、 +障絽吾 lw $gp,$L_41($fp) -が出る。だから、alloca で$gpを移動する必要はない。しかし、code_segment -で alloca は使えない。$gp をswしなおせば? - -input interface 構造体の alignment を64にすれば、マッチする可能性が -ちょっと高くなる。 - -const がレジスタに既にあるかどうかをチェックする? ま、いらないか。 - -ARM の bitield +冴alloca $gp腱糸綽荀code_segment + alloca 篏帥$gp sw? + +input interface 罕篏 alignment 64違醇с +<c蕭 + +const 吾鴻帥≪с? 障 + +ARM bitield |---====|=====|====----| |--===|===--| -は、mc-codegen 側で対処しない? char/short/int は -> short/int/long -にすれば良いわけだよね。 - -問題は、long だけ。はみだすのはintだってわかっている。 +mc-codegen 眼у上? char/short/int -> short/int/long +域 + +馹long 帥intcc bit_filed bit_field(upper) << offset + bit_filed(lower) @@ -6307,137 +6307,137 @@ bassop .... -やっぱだめだめ。 - -bit_filed の前に、読み込みの段階で +c宴 + +bit_filed 茯粋昭帥罧級 upper2 << offset + (lower&mask >> 32-offset-size) -するか。 - -bit_field_repl,bit_filed_repl_const はそのままで、 -代入するときに、二回 replace する。 - -おんなじことか。 - -** そうではなくて、 - -long でintが余ったときの確保する場所(int)(bitfield_opt)をstack上に用意する。 -(new_lvarでしょうね) get_register_var でもいいけど... ARM では意味ない -だろうな。 - - mc-codegen:bit_field では、load する時に、bitfield_opt にもload - code_bit_field では、必要ならば、bitfield_opt から値を読む - - mc-codegen:bassign では、load する時に、bitfield_opt にもload - mc-codegen:bit_field_repl では、必要ならば、bitfield_opt も置換する - 代入時には、忘れずにbit_field_opt も書き込む - - mc-codegen:bassop では、tmp1 を読むときにbitfield_opt にもいれる - -でいいんじゃない? 虚しいが... + + +bit_field_repl,bit_filed_repl_const 障障с +篁eャ篋 replace + + + +** с + +long int篏c腆坂贋(int)(bitfield_opt)stack筝 +(new_lvarс) get_register_var с... ARM с潟 + + + mc-codegen:bit_field сload bitfield_opt load + code_bit_field с綽荀違bitfield_opt ゃ茯 + + mc-codegen:bassign сload bitfield_opt load + mc-codegen:bit_field_repl с綽荀違bitfield_opt 臀 + 篁eユ綽bit_field_opt 吾莨若 + + mc-codegen:bassop сtmp1 茯bitfield_opt + +с? ... Thu Oct 28 17:40:35 JST 2004 -それだと変更点が多すぎる。long long でバウンダリがまたがる時 -には、格納type を struct { int [3]; } として、一時領域に格納 -する。実際には、アドレスが帰って来ることになる。で、code_bit_ -replace_const などでは、アドレスに対して処理すれば良い。そう -すれば、codegen 側の変更は(ほとんど)なくなる。 - -でも、そうすると格納型と値型を区別しないとまずいね。 +紊雁鴻紊long long с潟障 +主type struct { int [3]; } 筝主 +絎≪鴻絽違cャсcode_bit_ +replace_const с≪鴻絲障域 +違codegen 眼紊眼(祉) + +с主ゅ阪ャ障 Fri Oct 29 04:19:58 JST 2004 -code-* 側にはtypeの内部構造とかを渡すのは良くない。 - -あとは、格納型>値型の時のbitの値の修正だな。 - -この手のbit-field って、本来なら、inline で *C* で記述されるべき -ものだよね。 +code-* 眼type罕羝< + +主>ゅbitゃ篆罩c + +bit-field cャinline *C* ц菴違鴻 + Fri Oct 29 20:30:41 JST 2004 -できたけど.... bassign の中のsassignでアドレスが狂うバグが -あるらしい。本来は、余計なコピーがあっても、害はないはず -なんだが、 +с.... bassign 筝sassignс≪鴻違 +ャ篏荐潟若c絎潟 + diff test/bitfield.gcc.out test/bitfield.mc-arm.out 1058c1058 < 2:00000000 00000000 00000000 def00000 56789abc 00000234 00000000 00000000 --- > 2:00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 -と言う形で、上書きしてしまう。 - -dum()をはさむと直ったしするのでレジスタのメンテナンスの -問題らしいが... - -大域変数のptr cacheが、jump のinput argument regsiter を -壊してしまう。ARM以外はどうして壊さない? 単にレジスタ -使用の順序の問題で、でる可能性はあるってことか。 -jump の中でusig_reg すれば良いんだけど。 - -get_input_register* でcodeの場合だけ using_reg しちゃったけど、 -いいのかな? - -あっと、goto の浮動小数点レジスタ渡しをあまりテストしてないね。 - -bitfield は、アドレス渡しで、代入しない方が良いね。 +荐綵≪с筝吾障 + +dum()眼cс吾鴻帥<潟潟鴻 +馹... + +紊у紊違ptr cachejump input argument regsiter +紕障ARM篁ュ紕? 吾鴻 +篏睡綺馹сс醇сc +jump 筝usig_reg 域 + +get_input_register* code翫 using_reg <c +? + +cgoto 羌絨亥鴻吾鴻炊検障鴻 + +bitfield ≪号検с篁eャ鴻 Sat Oct 30 17:48:18 JST 2004 -いいんだけど変更がきつい... +紊眼ゃ... a = b = c = 0 -で、a は定数代入にはならないのね? 通常はいいんだけど、bitfield -とかでは余り良くないね。 +сa 絎遺撮ャ? 絽吾bitfield +с篏 Sat Oct 30 20:39:34 JST 2004 -MIPS の$4,$5,$6,$7 は引数渡しに使われるわけだけど、 -6,7にlong long が入るときには、$5 には、$6 と同じ値が入る? -いや、bitfield1.c の printf の %lld が %d になっていただけでした。 - -ARM の lreg でregsiter が lost するのを止められない... -use_input_reg(int reg,int mode) ってやっぱり、おかしいよね。 - -なんか、直すのに5時間もかかったよ。 - -ARM では、use_int/use_longlong の繰り返しで lreg がlost する -らしいのだが、他のmips/powerpc では、そういうことは起きない。 -なんでだろう? +MIPS $4,$5,$6,$7 綣井検篏帥 +6,7long long ャ$5 $6 ゃャ? +bitfield1.c printf %lld %d cс + +ARM lreg regsiter lost 罩≪... +use_input_reg(int reg,int mode) cc宴 + +眼5c + +ARM сuse_int/use_longlong 膵違菴 lreg lost +篁mips/powerpc с莎激 +с? Wed Nov 3 18:31:28 JST 2004 -やっぱり構造体をint単位に分解すると並列代入は良くなるね。し -かし、それだと、巨大な構造体ではコンパイル時間がかかりすぎる -のと、コードがでかくなってしまう。 - -並列代入も、もう少し考えるべきだな。 +c宴罕篏int篏茹c筝篁eャ +綏紊с罕篏с潟潟ゃ +潟若сc障 + +筝篁eャ絨鴻 code f(int a,struct b) { goto g(b,a); } -みたいな場合だね。 - -分解してから、もう一度、memcpy にまとめるという手もあるけど... -代入ベースではなくて、swap base の置換にする? +帥翫 + +茹c筝綺memcpy 障... +篁eャ若鴻сswap base 臀? for(i) swap(a[i],b[i]); -みたいな感じ? +帥? code f(struct a,struct b) { goto g(b,a); } -みたいな場合は、そんなのが望ましいが... - -分解して巡回依存を解消して、address でsort すれば... memcpy -は検出できるはずだけど... - -あ、そうか、巡回依存は、基本的にswapで解決できるはず。 +帥翫障... + +茹c綏≦箴絖茹faddress sort ... memcpy +罎冴с... + +綏≦箴絖堺swapцВ羆冴с copy(a,b) swap(a,b) -の組合せで、最適な結果が得られるはず。そうすれば、saveとか -をしなくてすむ。 +腟с腟緇違save + (a,b,c) <= (b,c,a) -は、 + swap(a,b); swap(c,a); -となる? あれ? +? ? case triple a b c @@ -6445,7 +6445,7 @@ b c a |-----||---------||---| -うーん、 +若 circular_dependency => smallest dependent element singleton or not @@ -6456,29 +6456,29 @@ default: continue; // try another } -これだと、a がsave, b がsaveで、c がsignleton ということになる。 -いや、b もsingleton になるかな? b&c を一つのmemcpyにまとめる -のは、それほど意味はないが... - -これでも、 +a save, b saveсc signleton +b singleton ? b&c 筝ゃmemcpy障 +祉潟... + +с case eq a b |---------|---------| b a |---------|---------| -は、save code が出てしまう。また、上の場合でも、a がでかい場合 -があるよね。本来、 +save code 冴障障筝翫сa с翫 +ャ one integeter save -で全部できるはず。(お手玉swap) で、分解すればお手玉swap codeは出る。 - -memcpy するためには、その先を全部saveしないとだめ。だから、memcpy -とは両立しない。うん。だから、swap operation にするのが良い。が、 -case triple をswap operation で解決する方法が良くわからない。 +ус(swap) с茹c違swap code冴 + +memcpy savememcpy +筝∞swap operation +case triple swap operation цВ羆冴号 a b c |123||45678||9abcdefgh| |-23||45678||9abcdefgh| {1} |423||-5678||9abcdefgh| {1} -ってな感じかぁ。これは、space/operation trade off なの? +cspace/operation trade off ? a b c |123||45678||9abcdefgh| |-23||45678||9abcdefgh| {1} @@ -6500,31 +6500,31 @@ |45678||9abcdefgh||12-| {3} |45678||9abcdefgh||123| {-} b c a -で、できるにはできるんだが.... - -これと、memcpyとどっちが速いかはアーキテクチャとmemcpyによる。 - -だから、 - ある程度、小さい構造体は分解 - 大きなものは、singleton/smallest detection をまずやる - save が大きすぎるときには、circular dependent 内部でお手玉を出す -ってな感じですかね。 - -お手玉なんだけど、 +ссс.... + +memcpyc<≪若cmemcpy + + + 腮綺絨罕篏茹 + 紊сsingleton/smallest detection 障 + save 紊сcircular dependent с冴 +cс + + a b c |-||---||-------| 123456789abcdefgh - a b1 c b2 c_t + c_s をswap + a b1 c b2 c_t + c_s swap |-||||-------||-| 123459abcdefgh678 - b2 b1 c a a_t + b2 をswap + b2 b1 c a a_t + b2 swap |-||||-------||-| 678459abcdefgh123 - b c a b2,b1 をswap + b c a b2,b1 swap |---||-------||-| 456789abcdefgh123 -ってな感じで大きなものからswapかな。こうすれば自動的に分割される -ので、分解は必要なくなる? +cуぇswap域蚊 +с茹c綽荀? circular_dependency => smallest dependent element singleton or not @@ -6549,16 +6549,16 @@ st r1,(to++); if (cnt-->0) goto swap -って感じ? swap された最後が、どういうパターンになるかは、ちょっと -面白い問題だけどね。 +c? swap 緇帥若潟<c +∝純馹 Thu Nov 4 10:15:29 JST 2004 -あ、なんか long long の定数シフトで > 32 の場合を忘れているね。 + long long 絎違激 > 32 翫綽 Fri Nov 12 15:37:42 JST 2004 -やっぱり、record (taged union) は欲しいよね。 +c宴record (taged union) 罨蚊 struct { enum {hoge0,hoge1,hoge2} i; @@ -6574,21 +6574,21 @@ assert(a.i==hoge0); printf("%d\n",a.b.j); -うーん、あんまり良くないなぁ。これだったら、いらないよね。 +若障c Fri Nov 12 15:59:32 JST 2004 -Template あるいは型変数は入れたくないよね。入れるとしても、 -上位言語だろうなぁ。 +Template 紊違ャャ +筝篏荐茯 Sat Nov 13 11:05:06 JST 2004 main() { printf("%d,%d\n", -555>>3,-555/8); } -70,-69 -なるほどね。 - -なんか arm-linux-gcc がバグっているな... +祉 + + arm-linux-gcc 違c... ltosop_register() { @@ -6610,11 +6610,11 @@ stmia r7, {r2-r3} ldr r0, .L640+92 -なんでかね。 +с Sun Nov 14 15:59:33 JST 2004 -よし、inline やるか。 +inline inline function (or parsed tree) // list4(INLINE,name,type) @@ -6639,102 +6639,102 @@ list3(ST_LABEL,next,label) list3(ST_COMMENT,next,comment) (?) - いくつかはexprと重なるけど... (まずい?) RETURN, ASM + ゃexpr... (障?) RETURN, ASM (1) make inline tree (2) evaluate inline function (copy and partial evaluation) peval(inline_func,args) similar to the function call (with type check) - const いるのかなあ。 - builtin_constant_p かぁ。 - - partial evaluation しながら code 生成する? (難しい...) - partial evaluation してから code 生成する。まぁ、こっちでしょうねぇ。 - g_expr を変更しなくてもすむ + const + builtin_constant_p + + partial evaluation code ? (c...) + partial evaluation code 障c<с + g_expr 紊眼 Mon Nov 15 17:37:57 JST 2004 code hoge() { a; } code hoge1() { b; } -では、a-> b に、そのまま落ちるべきだろうね。ファイルが分離される -場合は少し困るが.... 型が合わない場合にエラーを出さないと。 - -if (0) hoge; でhogeが生成されてしまう。control で切っても出るね。 -いや、消えてました。ただ、jmp は生成されてしまうね。checkret -で、チェックするべきでしょう。 - -checkret は、control が生成されるところで呼ばれるわけだから、本来は -control=1 にするのは、checkret だけであるべき。 - jmp(hoge) は、pending_jmp -を設定して、checkret で、pending_jmp を生成するわけだが。 -で、pending jmp が設定したlabelに等しければ、pending_jmp は0に -設定される(しかしreferenceされたかも知れないからlabelは生成する?) -label にreferenceしたかどうかのflagを付けた方が良い? - -if (1) hoge else fuga ; で fuga が生成されてしまう。bexpr で -always jump かどうかを返したいところだが... +сa-> b 障乗純<鴻<ゃ≪ +翫絨違.... 翫若冴 + +if (0) hoge; hoge障control уc冴 +羔障jmp 障checkret +сс鴻с + +checkret control у若違ャ +control=1 checkret с鴻 + jmp(hoge) pending_jmp +荐絎checkret сpending_jmp +сpending jmp 荐絎label膈違pending_jmp 0 +荐絎(referenceャlabel?) +label referenceflag篁鴻? + +if (1) hoge else fuga ; fuga 障bexpr +always jump 菴... Mon Nov 15 21:25:15 JST 2004 -構造的にはさ、inline は、CbC の外で行われるべきものだよね。 -内部で処理してもいいんだけど、本来は外でやるべきものです。 - -gcov は面白い! +罕inline CbC 紊ц鴻 +уャ紊с鴻с + +gcov ∝純! Sat Nov 20 16:44:38 JST 2004 -古いswitchの実装が壊れている。lazy jump の影響らしい。 - -PowerPC が cmp immideate value を出力してない。このあたりは、 -積極的に落した気がするけどね。直すとめんどくさいかも。 -MIPS と ARM は、ちょっとしくじってるな。 - -あれ、複数のファイルをコンパイルするときの問題があったような -気がするんだが... あるね。 +ゃswitch絎茖紕lazy jump 綵演帥 + +PowerPC cmp immideate value 阪 +腥罐窮純羂眼 +MIPS ARM <cc + +茲違<ゃ潟潟ゃ馹c +羂... ./mc-hoge mc-*.c Sat Nov 20 22:00:36 JST 2004 -あぁ、なんかいろいろ破壊しているし〜 - -なんか、いろいろ残ってたね。ia32 の long eq/ne 。 int + unsigned が -unsigned になったり。 - -size < int のstruct の値の渡し方がおかしい +翫 + +罧cia32 long eq/ne int + unsigned +unsigned c + +size < int struct ゃ羝<鴻 Sun Nov 21 13:02:09 JST 2004 -gexpr に parse = list2(expr,parse); するオプションを付ければ、 -inline の手間は少なくてすむかも。 - -static でないと実体も出力する必要があるわけね。 - -const, volatile がないと大した最適化ができない。まぁ、あんまり -やらないつもりなんだけど。 - -const, volatile は型にするとめんどー。だけど、C にそうなら型だろう。 -storage class でいいなら簡単なんだけど。sc を bitmask にするか。 +gexpr parse = list2(expr,parse); 激с潟篁違 +inline 絨 + +static с絎篏阪綽荀 + +const, volatile 紊сс障障 +ゃ + +const, volatile 若C +storage class с膂≦sc bitmask extern (or static) extern used const -attr には、INLINE, CONST, VOLATILE がとりあえずはいる。 - -定数の大域変数と局所変数の初期化された値をどこかにとっておく必要がある。 -どこ? dsp? attr? - -address の引き算が間違ってる。 - -定数は .literal4 っていうのに割り振られるみたいね。 - -l.c がlocal typeの爆撃で壊れている。list3 にしたからだろうな。 - -macro.c に signed char の依存性がある? - -size_t に関しては少し調べた方がいいんじゃないの? +attr INLINE, CONST, VOLATILE + +絎違紊у紊違絮紊違ゃc鏆荀 +? dsp? attr? + +address 綣膊c + +絎違 .literal4 c蚊帥 + +l.c local typeуlist3 + +macro.c signed char 箴絖с? + +size_t ≪絨茯帥鴻鴻? ## struct temp temp3 = { ## .c = (int)&b, @@ -6743,116 +6743,116 @@ ## }; .globl _temp3 _temp3: - .long 0 はぁ? + .long 0 ? .space 4 .long 59997 .long -10 - space は? + space ? ## ## -いろいろあるな。 + Mon Nov 22 22:34:03 JST 2004 typespec if(mode==LDECL) return 0; // not a type t= INT; // empty typespec -だから、 + smode = mode; mode = STAT; checksym(LPAR); mode = LDECL; // typespec required this if((t=typespec(ctmode))==0) { mode = STAT; // too late for expression expr(0); -かぁ。 - -hash があんまり良くない。っていうか、compiler で20%、l.c で98%... -rehash は、ちょっと難しすぎる。せめて、オプションで設定できる -ようにするか。 + + +hash 障ccompiler 20%l.c 98%... +rehash <cc激с潟ц┃絎с + #define hash_value(hash,ch) (hash = (37*hash)^(11*(unsigned char)(ch))) // #define hash_value(hash,ch) (hash = (37*hash)^((unsigned char)(ch))) -なのかぁ。open hash だからか。 +open hash Wed Nov 24 13:21:03 JST 2004 -レジスタの +吾鴻帥 mov creg, regv add creg,$3 mov regv, creg -はなんとかしたいよね。 - -goto 文で、parallel assignment が、 + + +goto сparallel assignment i+1 -みたいな場合に、 +帥翫 mov creg,regv add creg,$1 store creg,lvar load creg,lvar -みたいなのを出してしまう。それは、i+1 がis_memory でないから。 -単純に、これを残すと、source list にi が入らないので、iをoverwrite -されてしまう。 - -で、is_contains_p1 で、source を列挙すると、parallel_assign が -止まらなくなる。(何故?) - -remove0(soruce) で含まれているsourceを全部落し切れないからだね。 -save したあと、source を書き換えるわけだけど、その部分が考慮されてない。 -うーん、ちょっと諦めた方が良いみたいだなぁ。 - -やっぱ、まじめに parallel assign かかないとだめなんじゃないの? - -えーと、 +帥冴障i+1 is_memory с +膣罧source list i ャсioverwrite +障 + +сis_contains_p1 сsource parallel_assign +罩≪障(篏?) + +remove0(soruce) у障source純 +save source 吾 +若<c茫鴻帥 + +c宴障 parallel assign ? + +若 i = i+1 -ってのがあると、i=i でないから消えないで残る。これを処理する方法が -ないわけね。でも、circular dependency にならないのは何故? +ci=i с羔ф号 +сcircular dependency 篏? Thu Nov 25 09:05:24 JST 2004 -progress で捕まえられているんだから、そこでなんとかする? - -dependency singleton を見つければ良いわけだよね。複数見つかっていれば -save しているはずなわけだから。 - -circlular dependency に渡されているのはsourceの「一つのメモリ」であって、 -式でない。だから、circular dependency ではoverlap を見つけられないわけ -だね。 - -うーん、やっぱり、adhoc なわりに複雑になってしまう。これだったら、CSE -を真面目にやった方がいいんじゃないかなぁ。 - -tmp1 は、違うエラーだな。code4 の中のprintf が j を壊しているね。 -なんで、r30 から負のoffset をcaller が爆撃するんだ? - -r1 を延ばして片付けたけど... そういえば、register の分を code -segement ではメモリに割り振らないって話はどうしたの? +progress ф障с? + +dependency singleton 荀ゃ域茲域ゃc +save + +circlular dependency 羝<source筝ゃ<≪сc +綣сcircular dependency сoverlap 荀ゃ + + +若c宴adhoc 茲c障cCSE +∝c鴻 + +tmp1 若code4 筝printf j 紕 +сr30 莢offset caller ? + +r1 綮吟違篁... 違register code +segement с<≪蚊c荅宴? list5(target,next, ty, source, source-dependency) -だよね。そうすると、source list から単純にremoveできない。他の -dependencyを削除しちゃうかも知れないから。なので、source は、 -やめて、list5 を直接使った方が良い? そうすれば、target を -remove すれば自動的にremoveされるので... - -progress でなんとかすると、やっぱり、全部 save されちゃうね。 -toplogical sort しないとだめか。 - -singleton が良い。multi ならば、どうせsaveするんだから。 -list5 はやらないとだめ。 +source list 膣removeс篁 +dependencyゃ<ャсsource +list5 贋・篏帥c鴻? 違target +remove 域remove... + +progress сc宴 save < +toplogical sort + +singleton multi 違save +list5 #define CHECK_HEAP(b) ({int _k=(int)(b);if(_k>heapsize)error(-1);_k;}) #define car(e) (heap[(int)(CHECK_HEAP(e))]) -は、いいんだけどさ、これのコンパイルが間違っているみたいね。 - -っていうか、expr() 中で docomp が実行されてコード生成されちゃうから -まずよな。何とか、する方法としては... (うーん、思い付かないな。 -だめなんじゃないの?) - -単独のサブルーチンを生成して、そこへの関数呼び出しにすれば? -code 生成系を足さないとできないか。 +潟潟ゃc帥 + +cexpr() 筝 docomp 絎茵潟若< +障篏号... (若篁 +?) + +泣若潟吾∽医若喝冴? +code 膤祉莇潟с b hoge haga: fuga @@ -6861,9 +6861,9 @@ hoge: bl haga value -まあ、いいんだけど、大半の場合は、必要ないんだよね。 - -あぁ、これだと、({ goto exit0; }) みたいなのがだめだ。 +障紊у翫綽荀 + +({ goto exit0; }) 帥 b L1 L2: fuga @@ -6874,13 +6874,13 @@ b L2 L3: value -ですかぁ? はぁ。 +с? Sat Nov 27 08:51:01 JST 2004 -({}) で、init_vars がnestする可能性があるのを忘れてました。 - -register stack が異なるので破綻しているみたい。 +({}) сinit_vars nest醇с綽障 + +register stack 違х雁胸帥 ## if (car(ns)==sc) { ## (heap[(int)(({int _k=(int)(ns);if(_k>heapsize)error(-1);_k;}))]) @@ -6893,7 +6893,7 @@ lwz r11,lo16(28+L_2206)(r30) b L_2216 -どうしようかなぁ。 + Sun Nov 28 02:41:11 JST 2004 @@ -6901,27 +6901,27 @@ > .indirect_symbol _code_postinc > .long 0 -なんだけど、PowerPC で、 - 関数として使われている is_function && sc==EXTRN1 - binding helper 必要 - non_lazy は不要 -と、 - 大域変数としてい使われている - binding helper 不要 - non_lazy のみ必要 -を区別する必要があるみたいね。これは parse.c で追加する必要がある。 - -もっとも、.long 0 が余計に出力されるだけだが。 +PowerPC с + ∽違篏帥 is_function && sc==EXTRN1 + binding helper 綽荀 + non_lazy 筝荀 + + 紊у紊違篏帥 + binding helper 筝荀 + non_lazy 水荀 +阪ャ綽荀帥 parse.c ц申綽荀 + +c.long 0 篏荐阪 Sun Nov 28 03:42:04 JST 2004 -float/double/longlong のcode segement argument のテストをしてない。 - -ia32 の ({}) がおかしい。 +float/double/longlong code segement argument 鴻 + +ia32 ({}) Sun Nov 28 15:49:54 JST 2004 -listn を object に変える? +listn object 紊? struct nodes { union { @@ -6939,38 +6939,38 @@ Mon Nov 29 11:55:14 JST 2004 -attr は、連想リストにするべきか。 - -partial evaluation を、どの段階で行うかっていう問題があるのか。 +attr f潟鴻鴻 + +partial evaluation 罧級цc馹 expr15 (function call) -inline 木作成の最中に展開すると繰り返し展開することになる。 -しなくても良いが... しかも、ST_* が expr の中に残ってしまう -ので、g_expr で、ST_* を扱うことが必須。ってことは変更が結構 -大きい。ここで展開すると binop の最適化にひっかかるので簡単。 -docomp と同じ扱いが必要? +inline 篏筝絮膵違菴絮 +... ST_* expr 筝罧c障 +сg_expr сST_* 宴綽c紊眼腟罕 +紊су binop 蚊cх亜 +docomp 宴綽荀? function (codegen) -ここで展開すると、代入とかが変数扱いしかしなくなる。手遅れ。 - -ってことは、expr15 で、partial evalucation はやる。inline -中は展開しないとして、残った ST_* は、g_expr で処理する -ってことですね。 - -static でもポインタを取られたりすると関数を生成する必要がある。 -extern なら、なおさら。それは、自分でやらないとダメ。まぁ、 -inline の関数リストを作るのが良いんだろうけど。 +у篁eャ紊井宴 + +cexpr15 сpartial evalucation inline +筝絮罧c ST_* g_expr у +cс + +static сゃ潟帥∽違綽荀 +extern с<障 +inline ∽違鴻篏 Wed Dec 1 18:40:37 JST 2004 -chk は、mc-code-*.c に現れるべきではない。 - -static で used っていう属性がないとちょっとまずい。compiler warning -だすべきだし。 - -switch(5) みたいな場合をone pathで取り扱うのは、ちょっと面倒。 +chk mc-code-*.c 憗鴻с + +static used c絮с<c障compiler warning +鴻 + +switch(5) 帥翫one pathу宴<c√ switch(5) for() { default: ... @@ -6978,111 +6978,111 @@ case 5: ... case 7: ... } -みたいな場合があるわけだよね。しかも、default があるかどうか -は、switch の場合ではわからないし。cslist をチェックすればわ -かるか。でも、default code を取り除けるかどうかは、default -を見つけた時点ではわかりえない。 - -pexpr では、もっと詳しい情報が得られるので、より簡単になる。 +帥翫default +switch 翫сcslist с違 +сdefault code ゃdefault +荀ゃ鴻с + +pexpr сc荅潟宴緇с膂≦ Thu Dec 2 12:06:22 JST 2004 -attribute ねぇ。見たくないねぇ。 - -inline は、あとは partial evaluator だけだね。 - -gexpr とおんなじ感じで、すべてをcopyする必要がある。lvar は、 -表引で入れ換え。disp は、その分、増加させる。register 宣言は、 -その時で探すことになる。pfdecl でもレジスタは再配分しないと -いけないんだけどね。 - -partial evaluator って思ったより量が多いなぁ。 +attribute 荀 + +inline partial evaluator + +gexpr с鴻copy綽荀lvar +茵綣уャdisp 紜register 絎h +ф「pfdecl с吾鴻帥 + + +partial evaluator cc紊 Fri Dec 3 12:47:50 JST 2004 -inline の引数を計算して、vartable に割り振る。pexpr で定数な -ら、そのまま定数に。変数だったら alias を避けないといけない -ので、new_lvar & copy 。変数でも、const (read only)なら、そ -のまま使って良い。このあたりは、const って宣言しなくてもコン -パイラの方で検出できるけどね。このコンパイラはさぼる方針なの -で。 - -複雑な式なら変数を確保(new_lvar)して代入する(式をparseに付け -加える)必要がある。なんだけど、一回しか使われてないなら、そ -のまま使っても良い。後で使われない可能性も高いので。この「一 -回」の意味は結構複雑。attr で評価されたどうかを覚えておく方 -が良い? ただし、副作用がある場合は、使われてなくても、一回は -評価する必要がある。f(k,i++) {ret k;} みたいな場合。しかも、 -f の前に評価する必要があるのか。i がその後使われないなら実行 -する必要ないし.... 副作用のあるなしや、evalられない場合を判 -定するのは難しいから、無条件生成でしょうね。でも、すぐにasm -に食わせる場合とかあるけど。 +inline 綣違荐膊vartable 蚊pexpr у違 +障上違紊違c alias 帥 +сnew_lvar & copy 紊違сconst (read only) +障鞘戎cconst c絎h潟 +ゃ鴻ф冴с潟潟ゃ若拷 +с + +茲綣紊違腆坂(new_lvar)篁eャ(綣parse篁 +)綽荀筝篏帥 +障鞘戎c緇т戎醇с蕭с筝 +潟腟罕茲attr ц箴<荀 +? 篏翫篏帥筝 +荅箴<綽荀f(k,i++) {ret k;} 帥翫 +f 荅箴<綽荀i 緇篏帥絎茵 +綽荀.... 篏eval翫 +絎c≧>散ссasm +蕋翫 vartable argument (-4) -> ptr local (0) local (4) -ってな感じ? argment size は、どうやって計算するんだっけ? - -あと、return value の返し方だけど... ない場合は簡単だけど、 -ある場合は、 - if()に使われる場合 - 代入される場合 - 使われない場合 -とあるよね。ST_COMPにすることは簡単なんだけど、余計な -変数が必要になる。COMMA でいいのか。 +c? argment size c荐膊c? + +return value 菴鴻... 翫膂≦ +翫 + if()篏帥翫 + 篁eャ翫 + 篏帥翫 +ST_COMP膂≦篏荐 +紊違綽荀COMMA с if() { retrun ...} else { return ... } -のような場合はどうする? COND に変換する? +翫? COND 紊? while() { return hoge; } -は? +? ({ while() { ret = hoge }; } ret;) -かな。全体的に、 +篏 ({hoge.... ret=hoge.... ; ret;}) -にする? hoge が構造体の場合は.... - -goto するっていう技もありか。 +? hoge 罕篏翫.... + +goto c { return exp; ... } => { exp; goto exit; ... exit: } -にする。こうすれば変数は不要。nest した時にだめか。いや、goto -しないとだめなのか。pexit_label ってのがあるわけね。 - -単純な場合を単純にするには? 単一で最後の時だけ特別扱いする? - -local 変数も使うものだけ生成した方が良いんだが... それには -2 pass 必要。rechability は2passでないとだめか。あ、めんどう。 -一旦展開した後、不要なコードを取り除くっていう感じですかね。 -そうでないと switch の不要コードを取り除けない? - -pcontrol みたいなので除去できない? pcontain みたいな感じで、 -直前のSTが実行される(かもしれない)コードを含んでいるかどうか -を判断する。pcontain = pcontrol のorみたいな感じ? +医違筝荀nest goto +pexit_label c + +膣翫膣? 筝ф緇劫ユ宴? + +local 紊違篏帥鴻... +2 pass 綽荀rechability 2passс +筝絮緇筝荀潟若ゃcс +с switch 筝荀潟若ゃ? + +pcontrol 帥чゅサс? pcontain 帥с +翫ST絎茵()潟若с +ゆpcontain = pcontrol or帥? Sat Dec 4 12:24:26 JST 2004 -問題は、is_readonly() だろ? (とりあえず)諦めちゃうっていう手 -もあるけど。is_readonly で、vartable に外のtreeをいれると、parse -tree に外のlvarが入り込む。それを識別する方法が必要になる。 -それは、まぁ、debug のためにも必要だから良いんだけど、type tree -の中に、list2(KONST,e) をいれると、他の型チェックが == では -すまなくなってしまう。has_type(INT,t) みたいな形? それは、う -っとうしすぎる。そもそもconst嫌いだし。でなければ、すべての -タイプに*Cみたいなのを作る? いきなり倍ですか。いやだめだね。 -compund type にもconstは付くはずだから。const struct hoge -みたいな? - -list2(LVAR,hoge,fuga) でhogeに足し算するようなコードはまずい。 -そういえば、大域変数の引き算とかはあんまりやってないな。 +馹is_readonly() ? ()茫<c +is_readonly сvartable 紊treeparse +tree 紊lvarャ莨若茘ャ号綽荀 +障debug 綽荀type tree +筝list2(KONST,e) 篁с == с +障c障has_type(INT,t) 帥綵? +cconst絆с違鴻 +帥ゃ*C帥篏? с +compund type const篁const struct hoge +帥? + +list2(LVAR,hoge,fuga) hoge莇潟膊潟若障 +違紊у紊違綣膊障c Sat Dec 4 13:18:05 JST 2004 -そうか、inline function のcontinuation っていう問題があるの -か。もちろん、外の関数に戻れば良いわけなんだけど、戻る場所が -異ってしまう。inline が生成されるかどうかによって異る。inline -の外に必ず戻るってのは、どちらかといえば容易に実現できる。こ -っそり、return/env を渡してやれば良いから。 - -goto で関数の任意の位置に戻れるってのは誘惑的だし、その方が -整合的ではあるんだけど... 構文が良くわからないな。setjump に -突っ込めるってのは一つの解決方法か。 +inline function continuation c馹 +<紊∽違祉域祉贋 +違c障inline c違inline +紊綽祉c<医号絎憗с +creturn/env 羝<域 + +goto ч∽違篁紙篏臀祉c茯鴻 +翫с... 罕setjump +腦h昭c筝ゃ茹f浦号 if (setjmp(hoge)==0) { goto f(&hoge); @@ -7092,42 +7092,42 @@ goto hoge(1); } -ですか? そういえば、code の中でlongjmp するとどうなるんだろう? -局所変数は壊してしまっているので、呼び出した関数には戻れないね。 -まぁ、やっぱり、それを戻れるようにするんじゃないの? setjmp 構文 -は、あんまり良くない。それをいうなら return/environmentも良くない -けどね。shift/reset みたいな構文が良いか? +с? 違code 筝longjmp ? +絮紊違紕障cс若喝冴∽違祉 +障c宴祉? setjmp 罕 +障 return/environment +shift/reset 帥罕? Sun Dec 5 18:14:05 JST 2004 -関数の引数のconstの情報をどこにとっておくかが良くわからない。 -やっぱり CINT とか作る? 結局、const って、すべての型に直交している -から、そういう風にしなければ、tree で持たないといけないよね。 -そうすると、あらゆるところで、pointer判断が入ってしまう。それは -うれしくない。それよりは、 +∽違綣違const宴c +c宴 CINT 篏? 腟絮const c鴻岩困 +蘂違tree ф +сpointerゆャc障 + #define TYPE(a) (a & 0xfffffffe) #define IS_CONST(a) (a & 1) -のがまし? じゃぁ、 +障? #define IS_UNSIGNED(a) (a & 2) -とかもいれる? - -それは、変更が大きいので、とりあえず、mc-inline.c のエラーを -とってからにするか。 +? + +紊眼紊ссmc-inline.c 若 +c Tue Dec 7 12:19:08 JST 2004 -lvar を二度置換するのはまずい。オフセットのタグを増やす方が良い。 -本来は不要だけどね。 +lvar 篋綺臀障祉帥違紜鴻 +ャ筝荀 Wed Dec 8 13:04:18 JST 2004 -うーん.... +若.... type tag -ねぇ。 + type tag 10bit -の属性か +絮с signed/unsigned 1bit size 4bit (double/float) const 1bit @@ -7135,25 +7135,25 @@ restrict 1bit assop 1bit arity (number of recursive tree) 4bit -属性で16bit とるべきでしょうね。 +絮с16bit 鴻с ATTR(tag,size,sign,assop,arity) (tag<<16)+sign+(size<<1)+(assop<<9)+(arity<<12) -CONV も ICONV,FCONV + source type (INT) とかがいいみたいだね。 - -んー、なんかいまいちだな。 +CONV ICONV,FCONV + source type (INT) 帥 + +若障< Thu Feb 17 13:07:36 JST 2005 -また、あいだが空いているよ。string と const の再利用がいまいちだね。 +障腥冴string const 障< Tue Mar 1 14:55:55 JST 2005 -arm なんだけど、post increment とかあるよね。さぼらずにやろう。 +arm post increment 若 ldrb ip, [r0, #1]! -あと、arm は、predication をちゃんとやらないとgccには勝てないね。 -まぁ、できないことはないんだろうけど、めんどくさそう。peep hole -的に? まぁ、inline mode でやるしかないでしょうね。 +arm predication <gcc +障сpeep hole +? 障inline mode сс sub ip, fp, #68 ldmia ip!, {r0, r1, r2, r3} @@ -7161,47 +7161,47 @@ ldmia ip!, {r0, r1, r2, r3} stmia lr!, {r0, r1, r2, r3} -これは.... memcpy なのか。 +.... memcpy Sat Jul 30 14:41:54 JST 2005 -あぁ、function の型のlist node にVOIDというprimitive型が入ってしまって -いるね。これは、なんか、やっちまった記憶があるが... どうも、もともと -あまりちゃんとしてなくて、type<0でも car(type)とかやってたみたいだね。 - -inline code ってのはありえるの? - -何か知らないが gcc が .s の#マクロの展開をするようになってるね。 +function list node VOIDprimitiveャc障c +c<障c荐吟... +障<type<0с car(type)c帥 + +inline code c? + +篏ャ gcc .s #絮c #include_next <stdarg.h> -ですかぁ?! +с?! ./mc1 -s -ob10.s mc-parse.c /usr/include/sys/cdefs.h:335:Macro syntax # error Unknown architecture -このエラーはなんかあったが... __ppc__ が定義されてないのがいけないのだよ。 -ifdef を見るときには EMPTY になってるな。 +若c... __ppc__ 絎臂 +ifdef 荀 EMPTY c ## nptr_pool->ptr += sizeof(NMTBL); ## 4074: gexpr_init: creg=r3 freg=f14 - lwz r3,0(r11) nptr_pool を読み込んで来る + lwz r3,0(r11) nptr_pool 茯粋昭фャ stw r3,lo16(-20)(r30) la r3,lo16(-20)(r30) la r10,lo16(-20)(r30) addi r10,r10,lo16(24) stw r10,0(r3) -これだな。 - -iassop の hoge += const の処理が間違っていたみたい。他のは?! -そもそも、この定数演算の処理ってだめだめだよね? - -いつどこで、こうなったのか... って、そもそも、ここに落ちるのが -変だよね。 - -lassop も同じ問題があったね。 + + +iassop hoge += const c帥篁?! +絎井膊c? + +ゃсc... c純< +紊 + +lassop 馹c /* new = &e2 */ /* *new = *new op e3 */ n = list3(LVAR,new_lvar(size_of_int),0); @@ -7209,45 +7209,45 @@ g_expr(assign_expr0(rvalue_t(n,INT), list3(op,rvalue_t(list2(INDIRECT,rvalue_t(n,INT)),t),e3),t,t)); free_lvar(cadr(n)); -そもそも、なんでこうなんだ? e2 が極めて複雑な場合なんだよね? -get_register_var しないの? - -なんで、この悪事が露見しなかったのかは謎だが... +с? e2 罐泣茲翫? +get_register_var ? + +с篋画c茗... Mon Nov 7 20:30:26 JST 2005 -MIPS で、 +MIPS с jal fptodp -で、呼出側の局所変数を壊すってのがまだあるらしい。 - -じゃないみたい。 - -> f50 では、引数は +с弱阪眼絮紊違紕c障 + +帥 + +> f50 с綣違 > $f12,$f14,$6,$7 -> というように4つ乗るらしい。(こまったもんだ...) - -なんだけど、int との混在状況ではそうならないらしい。 - -$4 が使われていると $f12 は使わずに $5 を使うという方針のようですね。 +> 4や(障c...) + +int 羞桁倶с + +$4 篏帥 $f12 篏帥 $5 篏帥拷с Tue Nov 8 20:20:29 JST 2005 -構造体の局所変数の初期化に式を書けない。全部、定数かどうかをチェックする必要あり。 - -goto で struct 一つだけを引数にとったときにうまく動作しない.. (っていうか、 -int 以外の引数じゃうまく動作しない )ってバグを直しました。 - -ia32 の emit_copy が無限ループ。 +罕篏絮紊違綣吾絎違с綽荀 + +goto struct 筝ゃ綣違c障篏.. (c +int 篁ュ綣違障篏 )c違眼障 + +ia32 emit_copy ♂若 Thu Nov 10 18:46:39 JST 2005 -ia32 のfloat drindirect のoffset - -構造体のalignmentをやってませんでした。 - -Unioon のdisp の計算、変じゃないか? +ia32 float drindirect offset + +罕篏alignmentc障с + +Unioon disp 荐膊紊? } else if (mode==GUDECL||mode==LUDECL) { // disp = ((disp+(size_of_int-1))&~(size_of_int-1)); @@ -7257,20 +7257,20 @@ sz = size(type); } fields = list4(type,fields,(int)(n->nm),0); - ^^^ disp じゃないの? + ^^^ disp ? .... case GUDECL: case LUDECL: if (disp < sz) disp = sz; return n; -と union だけdispが特別扱いのようですが... あんまりテストされてないなぁ。 + union disp劫ユ宴с... 障鴻 Sat Nov 26 09:53:48 JST 2005 -MIPS で、 -code segment 中の float/double conversion の後で大域変数にアクセスすると -code dump する件ですが... +MIPS с +code segment 筝 float/double conversion 緇уぇ紊違≪祉鴻 +code dump 篁吟с... l.s $f12,16($11) jal fptodp @@ -7297,65 +7297,65 @@ $4 = (void *) 0x0 -わかりました。code segment の中では jal じゃなくて +障code segment 筝с jal la $25,fptodp jalr $25 lw $gp,$L_7($sp) -しなきゃいけなかったんだ。なんでそうかは忘れた。($fp を使われちゃうからなのね) +cс綽($fp 篏帥<) Sun Nov 27 15:04:31 JST 2005 -code じゃなくて _code にすれば? - -function call を code segment 自体で書ければ、mc-code-xxx.c の負担が減る -んだけど。asm と併用で? でも、その部分自体が system 依存だからなぁ。 - -S式構文を導入する? mc-parse.c のコード生成部分を分離しないと。 - -recursive type の拡張がいるよね。でないと code segement の型の正確な -定義が出来ない。 +code _code ? + +function call code segment 篏ф吾違mc-code-xxx.c 莢羝 +asm 篏窮? с篏 system 箴絖 + +S綣閝絨ャ? mc-parse.c 潟若≪ + +recursive type ≦宍с code segement 罩g∈ +絎臂堺ャ typedef hoge(arg) { ...; } hage; -で、hage をhogeの中で使えるようにすると C と意味が変わってしまうし、 -one path compile しにくい。 +сhage hoge筝т戎 C 潟紊c障 +one path compile Sun Dec 4 14:16:24 JST 2005 -構造体の初期化で、構造体のネストとか配列を無視して、ずらずら、 -並べるってのがるらしい。 +罕篏с罕篏鴻∴ +筝鴻c sturct hoge { int a; double b[3]; } = {1,2,3,4}; -みたいな。今は、エラーになるけどね。その方がいいと思うけど。 +帥篁若鴻 Sat Dec 10 19:24:59 JST 2005 -partial evaluator だと、やっぱりフロー解析しないとだめだよな〜 -途中で malloc したり中間変数で取った構造体を消さない限り、 -本当は inline は意味ない。static の扱いで別に害はないんだけどさ。 - -難しい割りに使えない機能の一つだね。 - -const は無視するって技もあるな。変数についた変数の値に -対するconst は ctmode で判るはずだよね。 - -enter_scope は連想配列ベースだから、上のレベルの変数は -見えるはず。だから、partial evaluation 中の値の書き換え -は、enterscope してやればいいんじゃないの? +partial evaluator c宴取В +筝 malloc 筝紊違уc罕篏羔 +綵 inline 潟static 宴уャ絎潟 + +c蚊篏帥罘純筝ゃ + +const ∴c紊違ゃ紊違ゃ +絲障const ctmode уゃ + +enter_scope f渇若鴻筝紊違 +荀partial evaluation 筝ゃ吾 +enterscope 違? Sun Dec 11 18:18:04 JST 2005 -もしかして、inline 用なら attribute でいいんじゃないの? type check -しないんでしょ? - -attribute は変数にしかつかない。関数の型にconstを入れるとすれば、 -ANSI-Cとの互換性を考えても type system に入れるべきでしょう。 - -emit_data で、型だけ見て処理してました。値の型を見ないとね。 -address 以外は型検査で落していたらしい。 +inline attribute с? type check +с? + +attribute 紊違ゃ∽違constャ違 +ANSI-C篋с type system ャ鴻с + +emit_data с荀障ゃ荀 +address 篁ュ罎祉ц純 int a0(); int a5(); @@ -7370,130 +7370,130 @@ 0, }; -なるほど、long long ではエラーを出して良いらしい。 +祉long long с若冴 unsgined i = -5; -で、昔は 0xff...ffa が入ったけど、今は、0が入るみたい。うーん。 -これを区別するためには、CONSTと UCONST を区別する必要があるね。 -まぁ、やるべきなんだろうけど... +с 0xff...ffa ャc篁0ャ帥若 +阪ャCONST UCONST 阪ャ綽荀 +障鴻... Mon Dec 12 21:53:38 JST 2005 -type system にいれると primitive type (intなど)もリストにしない -とだめなのか。それも、ちょっとなぁ。まぁ、qualifier があった -時点で、list3(ATTR,type,attribute) とするという手もあるけど。 -それが合理的かな〜 - - -局所変数のalignmentを def と new_lvar の二箇所でやってました。 -しかも、間違ってました。 +type system primitive type (int)鴻 +<c障qualifier c +鴻сlist3(ATTR,type,attribute) + + + +絮紊違alignment def new_lvar 篋膊сc障 +c障 Fri Dec 16 12:57:46 JST 2005 -まぁ、type に attribute を入れるのが良いとは思う。でも、たぶん、 +障type attribute ャс吟 if (type<0) { switch (type) { case INT: .... -みたいなコードがたくさんあるはずなので、その前に attribute を -取り除くコードを入れないといけないらしい。ちょっと影響が大きい -ので、気が重い。 - -attribute の情報は構文木には入らない。変数には attr field -があるので入る。関数の引数の情報はtypeに入るはずなので、そ -れでだいじょうぶ? 引数のリストは構文解析中しかないので、型 -に入れるしかない。structのfieldに入る場合もあるしね。それを -実際にチェックするかどうかはコンパイラの方針だけど。代入時 -にチェックすることは面倒だが可能。 +帥潟若с attribute +ゃ潟若ャ<c綵演帥紊с +с羂 + +attribute 宴罕ャ紊違 attr field +уャ∽違綣違宴typeャс +с? 綣違鴻罕茹f筝с +ャstructfieldャ翫 +絎с潟潟ゃ拷篁eユ +с√純 list(ATTRIBUTE,type,value) -ですか? value はint = (ctmode)? +с? value int = (ctmode)? type = set_type_attr(type,ctmode); get_type_attr(type) -かな。type_value みたいなのもいるかも。 +type_value 帥 Fri Dec 16 20:57:40 JST 2005 -うーん、やっぱり、結構変更が大きいなぁ。しかも、テストルーチンが -あんまり用意されてないし。 - -correct_type のエラーかぁ。 +若c宴腟罕紊眼紊с鴻若潟 +障 + +correct_type 若 Sat Dec 17 13:45:17 JST 2005 -function() が複雑すぎ。codegen の方に共通部分を収納した方が良くない? -可能だとは思うが、難しいね。IA32 の方が古すぎる。 - -さすがに4つも書いたので共通化できるはずだが。 - -そういえば、mc-tree も動かなくなってるんだよな。 - -gen_inline で vartable を使っているけど、enter_scope でいい -んじゃないの? 新しい変数を使うときは、new_lvar すれば良いし。 -同じ変数名で置き換えをするときがちょっと気まずいか。いや、macro_ -function と同じで、既に値は計算してあるんだろ? っていうか計 -算してからdef & assignするわけだよね。def しないといけない -ところがあれだが... def する方が整合性は高いが、その必要は -ないはず。ということは、enter_scope でいいのかな。getsym -しないから、だめか。 +function() 茲codegen 鴻演膣鴻? +純cIA32 鴻ゃ + +4ゃ吾у演с + +違mc-tree c + +gen_inline vartable 篏帥center_scope с +? 違紊違篏帥new_lvar 域 +紊医х舟<c羂障macro_ +function с≪ゃ荐膊? c荐 +膊def & assigndef +... def 鴻翫с蕭綽荀 +enter_scope сgetsym + Wed Dec 21 16:52:40 JST 2005 -PowerPC のprintf でfloatが混在する場合が「まだ」おかしい。 - -来年は64bit version だな。 - -今の実装でできるの? - -あぁあぁ、PowerPCのprintfがぼろぼろじゃん。っていうか、 -dots & freg の扱いが間違ってるな。 - -ia32 の cond の float も間違ってる。 +PowerPC printf float羞桁翫障 + +ュ拘64bit version + +篁絎茖сс? + +PowerPCprintf若若c +dots & freg 宴c + +ia32 cond float c Thu Dec 22 11:48:39 JST 2005 -cond のテストルーチンを入れたので、まぁ、いろいろバグが取れました。 - -ia32 の方では dreg が不必要にuseされている場合があるらしい。 - -printf もなんとか。assign_expr でのtype checkが変だった。 +cond 鴻若潟ャс障違障 + +ia32 鴻с dreg 筝綽荀use翫 + +printf assign_expr сtype check紊c Fri Dec 23 00:24:38 JST 2005 -inline の引数のpoinetrとったらどうするの? エラー? - -inline function のLVARのオフセットはあまり意味がない。 -index にするか? それともオフセットの連想配列にするか。 - -IVAR とか IRVAR とか作るのかな。type は入らない? LVAR とかと混在すると思うので -いるんだろうなぁ。 - -parital evaluator では、pexpr を再帰呼出ししないといけないわけね。 - -recursive inline の検出はやらないといけないわけね。 - -(あぁ、なんかやっちゃったみたい.... また、風邪拾っちゃったよ〜) +inline 綣違poinetrc? ? + +inline function LVAR祉障潟 +index ? 祉f渇 + +IVAR IRVAR 篏type ャ? LVAR 羞桁 + + +parital evaluator сpexpr 絽医弱冴 + +recursive inline 罎冴 + +(c<c帥.... 障蘂障c<c) Fri Dec 23 19:37:42 JST 2005 -ST_* 系列は、先に、cadr(e) を評価しちゃうのでif とかswitchとかの -スコープが狂ってしまう。 - -st_* のcadr(e)の評価は g_expr0 でやっているのでst_*側でやる -必要はないらしい。pexpr のネストが深いのは気になるが、直し方が -わからず。大域変数を使うのが良いらしいが。 +ST_* 膤糸cadr(e) 荅箴<<if switch +鴻潟若c障 + +st_* cadr(e)荅箴< g_expr0 сcst_*眼с +綽荀pexpr 鴻羞宴羂眼鴻 +紊у紊違篏帥 pwhile(int in) { out = list2(out,pexpr(in)); return cadr(in); } -みたいな感じ? +帥? Wed Dec 28 00:31:30 JST 2005 -違うね。 + pexpr() { e1=cadr(e); @@ -7504,44 +7504,44 @@ } parse = reverse0(parse); -みたいな感じか。 +帥 Sat Dec 24 21:00:17 JST 2005 -pfdecl で、inline を生成するんだけど、そこで引数のn->dspが arg_register -などで破壊されてしまう。すると、inline がinlineを含んでいた時に破綻します。 -なのでコピーを作ることで対処。 - -inline return は、まだ、ちゃんとつくってないね。代入になる -場合があるから、ret_var みたいなので取っておけば良いか。 -(これは、いまだにさぼり) - -gen_inline なんだけど、最初は、partial evaluation だけやるつもり -だったみたいだね。g_expr_u したのは間違いなのか。(そもそも、_u -じゃないし) 部分的なpartial evaluation は、やってもやらなくても、 -どっちでもいいはず。 +pfdecl сinline у違n->dsp arg_register +х翫障inline inlineс雁胸障 +с潟若篏у上 + +inline return 障<ゃc篁eャ +翫ret_var 帥уc域 +(障若) + +gen_inline partial evaluation ゃ +c帥g_expr_u (_u +) partial evaluation c +c<с Sun Dec 25 16:26:03 JST 2005 -あぁ、確かに goto のラベルは、inline の中ではlocal なscope -にしないといけないのであった。で、どうすれば良いわけ? - -うまく直せない。scope 関係を見直せば良いんだけど.... enter_top_scope とか。 -マルチレベルscopeになるわけね。 - -ではなくて、parse してしまえば、single level scpe になるので、 -enter_scope して、st_label では、make_local_scope すれば良いらしい。 +腆冴 goto inline 筝сlocal scope +сcс域? + +障眼scope ≫荀眼域.... enter_top_scope +scope + +сparse 障違single level scpe с +enter_scope st_label сmake_local_scope 域 ## 65: } while ( k < j); la r11,lo16(-20)(r30) la r10,lo16(-24)(r30) cmpw cr2,r10,r11 -なので、rvalue が取れてないみたいね。そう言われてみると、 -IVAR のravalue とかは無視してましたが、RVALUEみたいなのが -いるってこと? - -RINDIRECT で逃げようと思ったが、 +сrvalue 帥荐帥 +IVAR ravalue ∴障RVALUE帥 +c? + +RINDIRECT чc ## 40: if (i>j) return j; li r11,-3 @@ -7554,124 +7554,124 @@ lwz r10,lo16(0)(r10) ## 41: else return i; -const でreplaceする時がまずいな。RIVARみたいなのを作ると、 -ちょっとcaseが増えすぎるが... pindirect でいんちきするか。 - -(で、あとで、やっぱりだめで、const replace を諦めてるし) - -const で置換したIVARのアドレスを取られると気まずいなぁ。 - -このあたりはマルチパスでないとできない。まぁ、parse tree を -持っているので可能ではあるけど。 +const replace障RIVAR帥篏 +<ccase紜... pindirect с< + +(ссc宴сconst replace 茫) + +const х舟IVAR≪鴻羂障 + +鴻сс障parse tree +cу純с Sun Dec 25 20:24:02 JST 2005 -さて、return を作らないとだめか。 - -なに、結局、 - - return value がないときは jump - return value がある時には、g_expr でjump - -にする? とりあえず。 - -pfdecl で struct_return は、なんとかしてるの? - -やっぱ、ret() で、 code_set_return_register(1); -は、だめじゃん。if 文の分岐で値を同じレジスタ -に置くためには.... ?: と同じ方法か。 - -code_get_fixed_creg ねぇ。 +return 篏 + +腟絮 + + return value jump + return value g_expr jump + +? + +pfdecl struct_return ? + +c宴ret() с code_set_return_register(1); +if 絏уゃ吾鴻 +臀.... ?: 号 + +code_get_fixed_creg t = code_get_fixed_creg(USE_CREG,d); gen_jmp(e3=fwdlabel()); fwddef(e2); t1=g_expr0(cadddr(e1)); code_set_fixed_creg(t,1,d); -ですか。 +с Mon Dec 26 10:54:29 JST 2005 - .cstring とかのデータモードとglobalラベルが変。 - -これねぇ。string をconstに置くかどうかは arch によるわけだから、 -mc-code-*.c で解決するのが正しいわけだけど、emit_data に分散して -しまっているね。 + .cstring 若帥≪若global紊 + +string const臀 arch +mc-code-*.c цВ羆冴罩cemit_data c +障c Mon Dec 26 22:57:49 JST 2005 -引数中の関数型の定義があまり正確でないらしい。型宣言のない -code segment の呼び出しで、間違った値を送ってしまう。 - -大きな構造体二種類を含む parallel assignment が 無限ループ -する。分割を小さくすると通る。 - -register のtargetがoverrapしている場合に、registerを free -してからsave_targetしているので同じregisterが再利用されて -しまって無限ループしているらしい。save_target で register -overlap を見るようにしたけど、ad-hoc じゃない? (ま、 -もともと今の実装が ad-hoc だし) - -ASSIGN_STRUCT_DIVDE ってDIVDEする大きさのlimitなのか。 -大きいのは逆にdivdeしないのか。 +綣遺賢∽医絎臂障罩g∈с絎h +code segment 若喝冴сcゃc障 + +紊с罕篏篋腮蕁 parallel assignment ♂若 +蚊絨 + +register targetoverrap翫register free +save_targetуregister +障c♂若save_target register +overlap 荀ad-hoc ? (障 +篁絎茖 ad-hoc ) + +ASSIGN_STRUCT_DIVDE cDIVDE紊сlimit +紊сdivde Mon Dec 26 23:18:06 JST 2005 -そもそも、仮引数のユーザに名前と大きさを決めさせているんだ -から、順序はこっちで決めれば良い。その代わり、異なる名前で -仮引数を受けるのは許さないってのがいいかもね。とすると、code -segment の引数のdefault とかを考えるとかなり、不思議な感じ。 -なんか整合性の良い interface ってあるんだろうか? stack を含 -めて? +篁綣違若吟紊с羆冴 +綺c<ф浦域篁c違 +篁綣違荐宴ccode +segment 綣違default 筝茘違 +翫с interface c? stack +? goto hoge(i=1,j=3,...) -みたいな? +帥? Tue Dec 27 18:17:55 JST 2005 -inline をstaticとして扱うoptionがあった方がいいかもね。 - -あ、そうか。inline で new_lvar したら、あとでfreeしないと。 -ということは、keep track しないとまずいのね。 +inline static宴optionc鴻 + +inline new_lvar free +keep track 障 ## 94: i += k; la r3,lo16(-32)(r30) lwz r3,lo16(0)(r3) li r11,3 -当然、const arg でないとconstantに置き換えてはいけないわけね。 -address を取られた場合も同様。ということは、has_address みたいな -attribute も必要なわけだ。 - -ま、それはあとで。 +綵吟const arg сconstant臀 +address 翫罕has_address 帥 +attribute 綽荀 + +障с Wed Dec 28 17:29:59 JST 2005 -skipspc() で、inmode の時に、cheap に書かれてしまうので、 -cheap 上の string をterminate しないうちに、skipspc() -してはいけないわけね。 - -なんだが、"hoge" "ahoge" のcaseに、inmode の ST_COMMENT -が干渉してしまうわけね。それは、まずいか。 - -やっぱり、STRING は、"" で一つにして、複数つながる -っていう構文にした方が良いね。 +skipspc() сinmode cheap 吾障с +cheap 筝 string terminate <skipspc() + + +"hoge" "ahoge" caseinmode ST_COMMENT +綛我障障 + +c宴STRING "" тゃ茲違ゃ +c罕鴻 list(STRING,value,continue) -みたいな感じ。でも、それだと変更が多い(何故か nptr にいれてた...) -ので、やっぱり、append しました。 +帥с紊眼紊(篏 nptr ...) +сc宴append 障 Thu Dec 29 09:59:38 JST 2005 -PowerPC の get_lregister が失敗するのが、まだ、微妙に残ってる。 -足りないはずないんだけどね。input register も探させちゃうか。 -そういえば、最初は input register は使わない方針だったけど、 -今は使ってもいいんじゃないの? +PowerPC get_lregister 紊掩障緇絋罧c +莇潟input register 「< +違 input register 篏帥拷c +篁篏帥c? Fri Dec 30 16:31:33 JST 2005 -IVAR の置換だけど、 +IVAR 臀 453 int lvar; 454 if (car(lvar=cadr(e))==IVAR) { @@ -7681,29 +7681,29 @@ 457 case LVAR: 458 return rvalue_t(lvar,cadddr(e)); -だと、やっぱり、LVAR のindirect と干渉してしまう? - -indirect の型は、その場のtypeでは型変換が終ってしまっている -ので、その前のでないとだめ。そもそも型を渡さずに、 -UCINDIRECT とかを見るべきだよね。逆か? RINDIRECTを -一つにして型を持ち歩いた方がいいのか? - -配列のADDは、inline でどこに消えちゃったの? - (indirect で消しているみたいね) -って、あと一つまでいったか。 - -やっぱり offset がうまく動いてませんでした。 - -お疲れ様。 - -あぁ、-D が動いてないね。 - -ia32 は inline のregister_varをfreeしたことがなかったみたいだね。 +c宴LVAR indirect 綛我障? + +indirect 眼typeс紊腟c障c +сс羝< +UCINDIRECT 荀鴻? RINDIRECT +筝ゃ≧鴻? + +ADDinline с羔<c? + (indirect ф帥) +c筝ゃ障сc + +c宴 offset 障障с + +蚊罕 + +-D + +ia32 inline register_varfreec帥 Sat Dec 31 10:34:44 JST 2005 -code_return_struct で、一時構造体がinlineの場合にうまく -とられない。 +code_return_struct с筝罕篏inline翫障 + .data .globl foo @@ -7727,92 +7727,92 @@ popl %eax ret -とかで stack のぶっこわしを検出できます。 + stack 吟c罎冴с障 Sat Dec 31 17:08:08 JST 2005 -decl_data で ADECL をチェックしてないから、引数の初期化が -あるな。C++ では、確かあったような気もするが... - -arg offset のネストを「まだ」処理してなかったのか.... 引数の -中の引数宣言は「名前をつけない」ってのが普通だったからなぁ。 - -## の廻りのスペースを取る方法がわからない。なのと、; を一つ余計に食ってしまう。この手のバグは取りにくいよ。 - -## の次の置き換えの繰り返しに対してもspaceを取らないといけないので、 -depth first には解決できないね。## で mconcat のflag を立てて、 -mappend した後、## を取り除くのが良いのではないか? (もっさいが...) +decl_data ADECL с綣違 +C++ с腆冴c羂... + +arg offset 鴻障c.... 綣違 +筝綣医hゃcc + +## 綮祉鴻若鴻号; 筝や荐蕋c障違 + +## 罨<臀膵違菴絲障spaceс +depth first 茹f浦с## mconcat flag 腴 +mappend 緇## ゃс? (c...) Sun Jan 1 10:59:19 JST 2006 -inlucde_next で、重複したinclude_pathにひかかってしまって、 -同じのを開けてしまう。 - -#include の時にchptrsave stackは? top_init でclearするのは -変だとしても。#define \n hoge \n #include とか? 冗談だろ。 - -decl_data のINTの場合にcorret_typeするとsigned/byteの情報が -失われてしまう。 - -local struct init の場合に式を使うことができない。やっぱり、まずいか。 -local struct static を切ればいいんだけど。式があったら、 -代入するようにすれば良いんだが。(ま、いいか?) - -inline でも、 +inlucde_next с茲include_path蚊c障c +障 + +#include chptrsave stack? top_init clear +紊#define \n hoge \n #include ? 茫 + +decl_data INT翫corret_typesigned/byte宴 +紊宴障 + +local struct init 翫綣篏帥сc宴障 +local struct static 違綣c +篁eャ域(障?) + +inline с adpt_ps2/adpt_libps.c(.text+0xb0c): undefined reference to `ot_Init_node' adpt_ps2/adpt_libps.o: In function `GsClearOt': -ちゃんと extern 付けてくれれば、動くのになぁ。 +< extern 篁違 adpt_ps2/adpt_libps.c: ot_Init_node(); adpt_ps2/ot.c:ot_Init_node( void ) adpt_ps2/ot.c: ot_Init_node(); adpt_ps2/ot.h:inline char ot_Init_node( void ); -あぁ、ひどい。inline っていう嘘をつくことが可能なのか。しかも、 -Warning さえ出ないのか。でも、動いてはいるのか。 - -n->sc にFUNCTIONが入るのは間違い? - -linux が通らなくなってるね。struct field のネストね。通したはずなんだが。 - -getsym で構造体のデータがlocal defineされてしまう。SFDINIT modeか。 -LDECL だけで定義するんじゃないのか? 大域変数の場合もあるけどね。 - -decl_data で、構造体の中身の代入には assign_data で代入文が -出てしまうらしい。でも、それでもemit_dataに飛ぶ理由は不明だな。 +蚊inline cゃ純 +Warning 冴с + +n->sc FUNCTIONャ? + +linux cstruct field 鴻 + +getsym ф篏若帥local define障SFDINIT mode +LDECL у臂? 紊у紊違翫 + +decl_data с罕篏筝荳篁eャ assign_data т撮ユ +冴障ссemit_data蕋句宴筝 Tue Jan 3 15:39:54 JST 2006 -あぁ、なんか、union のdispの問題が今ごろ明らかになっているらしい。 - -いや、そうではありませんでした。decl_data が LVAR のdspを -いじっているせいでした。 - -statement expression ({int x; x+1}) だけど、inline でも、 -call してregister save した方が良いのだが.... +union disp馹篁c + +с障сdecl_data LVAR dsp +cс + +statement expression ({int x; x+1}) inline с +call register save 鴻.... parse = list3(ST_COMP,parse,expr(0)); -とすると、expr(0)で生成されたparseは失われてしまう。(何故かわかる?) +expr(0)хparse紊宴障(篏?) Wed Jan 4 09:41:39 JST 2006 -そろそろ mc-tree を作り直す時か... - -ST_COMPがネストしすぎ。ST_COMPじゃんなくてlistをデフォルトに -すればいいんだよな。append, reverse0 がたくさんでるけど。 - -やっぱり、statement expression が後ろに廻されてるね。 + mc-tree 篏眼... + +ST_COMP鴻ST_COMPlist +違append, reverse0 с + +c宴statement expression 緇綮祉 if ({hoge,i}) .... -を、 + hoge; if (i) ... -とcompileしていいのか? LCALL の代わりに「SAVE_REGISTER」みたいな -ことはできないの? - -素直に list3(STATEMENT,statement,value)とすれば? one path では出来ないか。 +compile? LCALL 篁cSAVE_REGISTER帥 +с? + +膣眼 list3(STATEMENT,statement,value)? one path с堺ャ goto exit0; printf("#0051:2nd inner %d %d %0x\n",i,k,&&exit1==exit); @@ -7824,98 +7824,98 @@ k++; exit0: -やっぱり、label のネストはあるのか... enter_scope しないで -なんとかする方法ないの? pvartable にkeepすればいいんじゃない? -だから、new_lvar すればいいんじゃないか? (いいんだけど、 -変更が大きい...) - -p_goto が、なんか二重に呼ばれている。まぁ、害はないんだが... - -硬いなぁ。scope.c が全然通らない。このコンパイラも複雑すぎる。 -また、simple に戻すのをやらないといじれなくなってしまう。 - -mode,stmode の関係が炸裂してるね。mode,stmode,ctmode と -必要なのか。一つにできないの? - -あぁ、なるほど。local_table でstaticを出力するんだけど、こ -のstatic は、inline で共有しないといけないわけね。別々にコ -ードが生成されても単一のコードを呼ぶのと同じでないといけな -いから。だから、毎回local_tableを出すのはまずい。 -使わないstaticのreferenceを出すわけにもいかない。 -local_table をinline code にいれるか? - -LLDECL は変。LDECL でtypeを見てやれば十分なはず。 +c宴label 鴻... enter_scope +号? pvartable keep違? +new_lvar 違? ( +紊眼紊с...) + +p_goto 篋若違障絎潟... + +隋scope.c 狗潟潟ゃ茲 +障simple 祉c障 + +mode,stmode ≫梧mode,stmode,ctmode +綽荀筝ゃс? + +祉local_table static阪 +static inline у掩ャ +若筝潟若若吟с +罸local_table冴障 +篏帥staticreference冴 +local_table inline code ? + +LLDECL 紊LDECL type荀医 801 if (inmode && mode==LDECL) { 802 parse = list4(ST_DECL,parse,(int)n,list2(stmode,ctmode)); 803 } -こんな間違いしているし。 - -inmode でも lastexp があるので、checkret は必要じゃん。 + + +inmode с lastexp сcheckret 綽荀 Thu Jan 5 14:10:10 JST 2006 -ようやっと scope は通りました。 - -doif, p_if, st_if と三段階に同じ処理をするのか。それがずれると、 -特に、pxxx で IVAR の置換が残ってしまうらしい。 - -local variable のKONST attribute に式が入る場合があり、 -それが pexpr されてないらしい。でも、ここに式が入ると、 -毎回計算されるので、結局、うれしくない。なので、 -本当の定数の場合だけセットする方が良い。 - -微妙に embug してるな。 +c scope 障 + +doif, p_if, st_if 筝罧級 +鴻pxxx IVAR 臀罧c障 + +local variable KONST attribute 綣ャ翫 + pexpr с綣ャ +罸荐膊с腟絮с +綵絎違翫祉鴻 + +緇絋 embug Thu Jan 5 18:14:45 JST 2006 -構造体の初期化なんだけど、 +罕篏 {1,2,3,4,{5,6},7} {1,2,3,4,(struct hoge){},7} {1,2,3,4,struct_hoge,7} {1,2,3,4,5,6,7} -を区別できないんだけど。 - -もしかして、expr(0) してから判断するのかな。 - -つうか、{} を一旦、リストに格納してからコード生成するのか。 -その方がいいか。 - -でも、adhoc にtypeid があったら構造体のコピーということに -しました。 - -bit field をinline するなら、bit field value を計算するのを -やらないとだめだね。code_bit_replace とかに interpreter mode -をつければいいんだよな。 +阪ャс + +expr(0) ゆ + +ゃ{} 筝鴻主潟若 +鴻 + +сadhoc typeid c罕篏潟若 +障 + +bit field inline bit field value 荐膊 +code_bit_replace interpreter mode +ゃ違 Thu Jan 5 22:18:50 JST 2006 -linux kernelは一応、通りました。IA32 でinlineで関数の引数の -呼ばれる順序が変わる。あと、scope.c のinlineがだめだな。 -なにか、まずいことをやっているのか? signed? +linux kernel筝綽障IA32 inlineч∽違綣違 +若違綺紊scope.c inline +障c? signed? return list3(COMMA,pexpr(e1),pexpr(e2)); -みたいなことをやると、IA32では引数の呼び出し順序が異なるので、 -p_decl とかがずれるみたいだね。この手のを全部取らないとダメだ。 - -IA32のis_writableに RLVAR が入るのは何故? - -xreg と creg を変更するコード生成があると、 -emit_pop_free で creg が regs[creg]=0 されちゃうときがある。 -emit_copy の後とかね。すると code_set_fixed_creg で、creg が切替えられてしまう。 -そして、値が伝わらない。 - -ia32 では emit_pop_free で creg かどうか見てるみたいね。それでも -いいんだけど... +帥IA32с綣違若喝冴綺違с +p_decl 帥< + +IA32is_writable RLVAR ャ篏? + +xreg creg 紊眼潟若 +emit_pop_free creg regs[creg]=0 < +emit_copy 緇 code_set_fixed_creg сcreg 帥障 +ゃ篌 + +ia32 с emit_pop_free creg 荀帥с +... Fri Jan 6 13:31:32 JST 2006 -gen_inline で、peval してstatementがない時には、生成しないんだよね。 -ということは、argument のgexpr もなんとかしないといけないわけね。 - -argument のreplaceは、lvalue でやらないと話がわやになってしまう。 -ってことは、de_ravlue っていうか lvalue() あるいは、paddress -を通さないとダメなのね。 +gen_inline сpeval statement +argument gexpr + +argument replacelvalue с荅宴c障 +cde_ravlue c lvalue() paddress +< ## spview[counttag]=spview[enemyfaste];^M @@ -7937,37 +7937,37 @@ move $4,$6 jal memmove -あーぁ、やってるよ。$6 にものの見事に上書きか。parallel assign している -はずなんだけどね。 - -emit_copy がparallel assign してませんでした。ARM を作ったときに -いれたと思ったんだけどね。 +若c$6 荀篋筝吾parallel assign + + +emit_copy parallel assign 障сARM 篏c +c Fri Jan 6 19:19:16 JST 2006 -MIPS のfloat register の save_stackが間違ってました。 - -PowerPC の math.h のinlcude がうまくいきません。 +MIPS float register save_stackc障 + +PowerPC math.h inlcude 障障 Sat Jan 7 01:33:01 JST 2006 -switch(c) で c が定数の場合は、別に作らないとだめか。 -式を持ち歩けば良いんだよね。今はレジスタを持ち歩いている -わけだけど。 - -pexpr で処理するのは、statementにcontrolがあるかどうかを -判断しなければならないので難しい。 - -inline は const をいれない状態だと、ほとんど部分計算は -ないね。flow 解析しないと。 - - -えーと、volatile const ってのは、 - 自分では書かないが、 - 誰かが変更する可能性があるので、 - 常に読みにいかないとだめ -ってことだよね。is_readony==1 だけど、is_const はfalse なのか。 -inline local の場合でもそうなの? +switch(c) c 絎違翫ャ篏 +綣≧域篁吾鴻帥≧ + + +pexpr уstatementcontrol +ゆ違чc + +inline const 倶祉荐膊 +flow 茹f + + +若volatile const c + с吾 + 茯違紊眼醇сс + 絽吾茯帥 +cis_readony==1 is_const false +inline local 翫с? const int i = 3; switch(i) { @@ -7976,32 +7976,32 @@ case 2: printf("#0036:2\n"); break; case 3: printf("#0037:3\n"); break; -これで、case 2(=default) が選択されるのか。ってことは、 -default が来たら、残りは全部無視して良いわけ? - - -インタフェースの順序を大きい順にすると、コピーの -被害が少ないが.... - -string の共有はやらないの? hash table にまで、いれたのに。 -set_attr が出来たので楽勝でした。 - -まぁ、でも、そろそろ封印だな。 - -あぁ、そうか。ST_COMMENT がgetcでinrement_cheapと干渉するのは、ST_COMMENT -の方がまずいよ。でも、直せないな。負けた、string のところだけ? -わかった。ST_COMMENT が別な「cheap pointer」を使えばいいのか。 - -UTF-8 使えるようにする? ascii を拡張すれば良いだけだよね。 - - -なんか、macro の history のcheckをしてないな。 +сcase 2(=default) 御c +default ャ罧∴? + + +ゃ潟帥с若鴻綺紊с潟若 +茴絎潟絨.... + +string 掩? hash table 障с +set_attr 堺ャфソс + +障с絨違 + +ST_COMMENT getcinrement_cheap綛我ST_COMMENT +鴻障с眼莢string ? +cST_COMMENT ャcheap pointer篏帥違 + +UTF-8 篏帥? ascii ≦宍域 + + +macro history check Sat Jan 7 20:34:12 JST 2006 -しかし、ここまで作っておいてなんだけど... +障тc... function(arg) { @@ -8009,7 +8009,7 @@ calling_function(arg) } -でもいいんじゃない? だめ? レジスタ渡しのargがないけどね。 +с? ? 吾鴻炊検arg extern printf(const char *,...); @@ -8039,7 +8039,7 @@ } } -これを以下のように変換するわけだ。 +篁ヤ紊 struct interface { @@ -8080,102 +8080,102 @@ L5: b _g -結構、ちゃんとでるじゃん。でも、printf を混ぜたりすると、結 -構、わけわからんコードが出るね。戻って来るっていう前提があ -るから、やっぱりレジスタのsaveがきついんだよな。 - -レジスタの引数渡しは絶対にでないけどね。(とは限らないか?) - -引数をすべて同じにするというのが肝なのか。 - -でも、これだったら比較的簡単にCに変換できるんじゃないか? +腟罕<ссprintf 羞激腟 +罕潟若冴祉cャc +c宴吾鴻帥saveゃ + +吾鴻帥綣井検腟九障с(?) + +綣違鴻 + +сc罸莠膂≦C紊с? CbC to C -ってわけだね。 - -そういう意味では一種の「プログラミングスタイル」なんだよな。 - -さすがに、構造体を引数にすると、こんなに簡単なコードは -出ないみたいだね。ということはポインタにせざるを得ない -のか。 - -スタック関係のコードを抑圧出来れば、mc でも悪くないか。 - -つまり、gcc で、 - tail recursion しか「無理に」しない制約 (__code) -を導入して、それを実現するcallを +c + +潟с筝腮違潟違鴻帥ゃ + +罕篏綣違膂≦潟若 +冴帥ゃ潟帥緇 + + +鴻帥≫潟若у堺ャ違mc с + +ゃ障gcc с + tail recursion ∞句 (__code) +絨ャ絎憗call __goto f(hoge); -にしてやれば良いわけだ。 - -あと、構造体をコピーしないモードだね。call semantics が違うから -これは必要なのか。pointer でもいいんだけどさ。違うのはここか。 - -4.0なら、比較的簡単に実現できるのではないか? - -pointer の方がinterfaceの切替えも楽だし。 +域 + +罕篏潟若≪若call semantics +綽荀pointer с + +4.0罸莠膂≦絎憗сс? + +pointer 鴻interface帥罐純 Mon Jan 9 19:29:06 JST 2006 -なんか、-E も -Cc も「ぜんぜん」動きません。mc-tree.c が -ぼろぼろだからだな。 まぁ、そうだよな。 - -ここら辺がconverterにするつもりだったんだけど、簡単には出来ない -かも。まぁ、今は、inline mode があるから、tree を作ってから -印刷するっていう技もあるけどね。 - -bitfield で、丁度、範囲がbyte/word boundary に一致した -時には普通の代入ですむんだけど、それを考慮してない。 -make_mask の時にチェック可能。(まぁ、やる必要ないけどさ) - -あと、if (hoge.bb) とか if (!hoge.bb) ぐらいは処理したい -よね。if (hoge.bb==0x1) とか if (hoge.bb!=0x1) も。 -この場合はshift しないで and または or ですむから。 - -ltosop で、オペランドの一つがint の時もやった方が良いかな。 - -それよりは、64bit対応かな。 - -fdecl, code_decl で、一旦、tree を生成してから、コード生成 -するオプションがあった方が良い。その方が最適化が可能。 -それをdefaultにするべきか? - -inline のst_switch は、もっと賢くあるべき。 +-E -Cc 障mc-tree.c +若若 障 + +莨冴converterゃc膂≦堺ャ +障篁inline mode tree 篏c +医激c + +bitfield с筝綺膀蚊byte/word boundary 筝眼 +篁eャс +make_mask с純(障綽荀) + +if (hoge.bb) if (!hoge.bb) +if (hoge.bb==0x1) if (hoge.bb!=0x1) +翫shift and 障 or с + +ltosop с潟筝ゃint c鴻 + +64bit絲上 + +fdecl, code_decl с筝tree 潟若 +激с潟c鴻鴻純 +default鴻? + +inline st_switch c莖≪鴻 Tue Jan 10 11:30:33 JST 2006 -parse tree base で変換するなら、binop を通すのはまずい。 - -binop では、式と型の組みで持たないとだめ? その方が -良いはず。 - -う、あっさり、converter も動いたか。 - -あとは、parse tree mode と source generator from parse tree を -作れば良いわけね。 - -まぁ、converter は one path なんで限界はあるんだよね。もっと -簡単に出来るかと思ったけど、実際に動かしてみると、結構、 -だめだめ。-E は、簡単に作れるから作ってみたけど、やっぱり -変だよね。本体を2 pass にすることも可能だが、いろいろ -面倒か。と考えると、parse tree が結局楽か。 +parse tree base уbinop 障 + +binop с綣腟帥ф? 鴻 + + +cconverter + +parse tree mode source generator from parse tree +篏域 + +障converter one path чc +膂≦堺ャc絎帥腟罕 +-E 膂≦篏篏c帥c宴 +紊篏2 pass 純 +√parse tree 腟絮罐純 Wed Jan 11 13:58:03 JST 2006 -ARM の定数テーブルの溢れを修正、freg_arg のバグ。 - -a0+a1+a2+.... で、局所変数から局所変数へのコピーが出るのは -ダサイ。が、そのためには、 +ARM 絎違若羣≪篆罩cfreg_arg 違 + +a0+a1+a2+.... с絮紊違絮紊違吾潟若冴 +泣ゃ gexpr(e1); emit_push(); -ではなくて、 +с emit_push(e1); -にしないとだめだね。直しても対した量ではないが... - -emit_push() では、register_full かどうかを見てないから、 -get_register() のところで、stack のclearが出るわけか。 -あぁ、そんなコードが出てるね。 - -machineop のところで、なんとか出来ないの? emit_pop -では free_lvar しているしな。 +眼絲障с... + +emit_push() сregister_full 荀 +get_register() сstack clear冴 +潟若冴 + +machineop с堺ャ? emit_pop +с free_lvar void machinop(e1) @@ -8194,28 +8194,28 @@ oprt_div(op,e3); return; -昔は、やってたみたいだね。 - -あぁ、そうじゃないよ。tosop の前のgexpr では RGVAR とかが -くれば良いんだが、それはbinop でやっていて、mc-inline.c -では、binop は呼ばれないから、最適化がかからないわけね。 -IVAR level で binop を呼んでも意味がない。 -ということは、mc-inline.c でbinopを呼べば良いから、やっぱり、 -list(op,e1,t1,e2,t2) という形でないとだめなわけね。 - -でも binop は type を変えてしまうので、それを保存するように -直さないとだめ。 - -これだと、parse tree を正確に保存することはできない。 -type を含めた変換をしないと構文解析できないし。 - -long long のEQ/NEQ が、long long を返しているようですが。 - - -O99 だと、mc1 が落ちて、mc2 は落ちない。ってことは、 -なんか余計なレジスタが干渉しているらしい。 - - PowerPC で -O99 だと、cmpflag 4 が保存されることを gcc4 -が要求するらしい。 +c帥 + +tosop gexpr с RGVAR +域binop сcmc-inline.c +сbinop 若違 +IVAR level binop 若с潟 +mc-inline.c binop若鴻域c宴 +list(op,e1,t1,e2,t2) 綵≪с + +с binop type 紊障с篆絖 +眼 + +parse tree 罩g∈篆絖с +type 紊罕茹fс + +long long EQ/NEQ long long 菴с + + -O99 mc1 純<mc2 純<c +篏荐吾鴻帥綛我 + + PowerPC -O99 cmpflag 4 篆絖 gcc4 +荀羆 +leo+kono time ./mc mc*.c ./mc mc*.c 0.93s user 0.11s system 93% cpu 1.105 total @@ -8223,26 +8223,26 @@ ./mc1 mc*.c 1.21s user 0.11s system 93% cpu 1.406 total +leo+kono time ./mc2 mc*.c ./mc2 mc*.c 1.19s user 0.12s system 84% cpu 1.542 total - gcc 最適化なし + gcc +leo+kono time ./mc mc*.c ./mc mc*.c 1.34s user 0.12s system 93% cpu 1.556 total -コンパイラぐらいだとgcc4 の -O99 の20%ぐらいの速度差らしい。gcc の最適化なし -よりは速いのか。 - - -O99 の初期化してないっていうエラーメッセージに対処するために -いろいろ初期化を入れちゃったけど、本当は必要ない。 +潟潟ゃgcc4 -O99 20%綺綏gcc + + + -O99 c若<祉若吾絲上 +ャ<c綵綽荀 Thu Jan 12 13:03:12 JST 2006 -あぁ、そうか。 + binop(...) { int e = binop0(...); if (inmode) return list3(op...); else return e; } -とすれば良かったわけね。まぁ、pexpr でひっかかりまくる -可能性はあるが.... +域c障pexpr с蚊c障 +醇с.... Thu Jan 12 22:28:32 JST 2006 @@ -8268,70 +8268,70 @@ hoge(); // bad } -最初の方のエラーを出せないな。 - -なんか、エラーにすると正しいものもエラーになってしまう。 - -function として使われたかどうか、code として -使われたかどうかのフラグが必要か。attribute? - -一回、goto f(); では function として処理しちゃっている -から、構文解析レベルではチェックできないな。 -mode を変えないと。stmode? - -codegen level では構文エラーを出さない方針が良いらしい。 +鴻若冴 + +若罩c若c障 + +function 篏帥code +篏帥違綽荀attribute? + +筝goto f(); с function <c +罕茹fссс +mode 紊stmode? + +codegen level с罕若冴拷 Fri Jan 13 09:34:10 JST 2006 -inmode を fdecl の最後でクリアすると、fargtype が -変になるらしい。local heap 上に取られてしまうから -なんだろうけど。でも、fdecl でinmode をクリアしないのは -おかしい。 - -local struct の型情報は local heap に取られるけど、 -global_table で参照される可能性がある。global に -置いてもいいんじゃないの? - -もともと global に置いていたが、decl_data の関係で -mode を入れ換えているうちに、間違えてしまった -みたいだね。あとは、inmode が甘かったので、 -global heap に残すものをあまり気にしてなかった -みたい。 +inmode fdecl 緇с≪fargtype +紊local heap 筝障 +сfdecl inmode ≪ + + +local struct 宴 local heap +global_table ус醇сglobal +臀? + + global 臀decl_data ≫ +mode ャ<障c +帥inmode cс +global heap 罧障羂c +帥 Sat Jan 14 22:58:45 JST 2006 -goto with environment だけど、code segment の中からの切替えは可能らしい。 -しかし、通常の関数からのgoto with environment はうまく動かない。 -これは何故だろう? - -そうか、env を設定したときは、構造体はコピーしないといけない -わけね。それは、code segment からでも同じ。 - -逆にメモリのoverrap は気にしなくて良いのか。通常の関数に戻 -る場合は、引数一つと決まっているからな。 +goto with environment code segment 筝帥純 +絽吾∽違goto with environment 障 +篏? + +env 荐絎罕篏潟若 +code segment с + +<≪overrap 羂絽吾∽違 +翫綣遺ゃ羆冴障c Sun Jan 15 09:24:58 JST 2006 -return がない時には、retlabelを生成しないほうがいい。 - -env を設定したら、jump のtargetをenv へのindirect + offset に -変えないとダメ。 - -goto with env は r1 しか変更してない。それは、code segment では、 -stack top に過ぎない。r30 の方を変更しないと。 -(いや、これは PowerPC 版だけの問題なのか...) - -code_set_frame_pointer が実はstack top しか設定してない。 - -env が設定されている場合は、メモリ上のinterfaceは、 -そのままコピーを実行すれば良く、並列代入する必要はない。 - -stack tpo はcode segment では frame pointer から計算される。(無駄?) -から、設定する必要は実はない。function に戻るときは必要。 - -new_environ のメモリ構成は... - - * gotoを呼び出した関数のr1 ! r1(goto前のr1) +return retlabel祉 + +env 荐絎jump targetenv 吾indirect + offset +紊< + +goto with env r1 紊眼code segment с +stack top r30 鴻紊眼 +( PowerPC 馹...) + +code_set_frame_pointer 絎stack top 荐絎 + +env 荐絎翫<≪筝interface +障障潟若絎茵域筝篁eャ綽荀 + +stack tpo code segment с frame pointer 荐膊(♂?) +荐絎綽荀絎function 祉綽荀 + +new_environ <≪罕... + + * goto若喝冴∽違r1 ! r1(gotor1) # * r30 <---r1_offset---------> r1 r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -8339,9 +8339,9 @@ f20-f31 <-my_func_args--><--disp-----><-max_func_arg-> *SIZE_OF_INT *SIZE_OF_INT -と書いてあるが、 +吾 disp = -args; -とか、 + /* reverse all argument offset (with size) */ arglist = fnptr->dsp; for(t=arglist;t;t=cadr(t)) { @@ -8349,99 +8349,99 @@ if(n->sc==LVAR) n->dsp = -n->dsp-cadddr(t); } -とかやっているので、lvar>0 ってのは存在しないらしい。つまり、 -全部、local variable 扱いになります。inline code ってのも -面白いけど、この辺を考慮しないとだめだね。 - -ってことは、fp はenvironment の一番下(つまり environment の -指しているところそのまま、で良いってことか? やっぱり -関数呼び出しに比べてなんて簡単なんだ。 - -R1SAVEして、frame pointer = environment でないのは、 -PowerPC 版だけか。ということは、PowerPC 版の R1SAVE -を解消することから始めないとだめなみたい。 - -基本的に、stack pointer は、save しておくか、frame -pointer から計算すれば良いらしい。どうして、R1SAVE -することにしたのかは不明。 +cсlvar>0 c絖ゃ障 +local variable 宴障inline code c +∝純莨冴 + +cfp environment 筝筝(ゃ障 environment +障障цc? c宴 +∽医若喝冴罸鴻膂≦ + +R1SAVEframe pointer = environment с +PowerPC PowerPC R1SAVE +茹f紮帥 + +堺stack pointer save frame +pointer 荐膊域R1SAVE +筝 function has return value but reached to the end -なんだけど、reachability のcheckが while(1) の -時とかやってないので、結構、うるさい。 +reachability check while(1) +cс腟罕 Sun Jan 15 16:06:29 JST 2006 -code_fix_frame_pointer って何をやっているのだろう? -arm/mips では、何もしてない。powerpc,ia32 でも、 -消去できるのでは? - -でさ、env をさっさと計算して get_register_var に入れてしまう -のが良いと思う。で、INDIRECT+offset にして代入すれば良い。 - -PowerPC, IA32 では、disp_offset ==0 には、原理的に出来ない。 -互換性の問題だから。code_segment の code_disp_offset を disp_offset -に合わせることは出来るはず。そうすれば、mc-codegen の方で -disp_offset を見ることはないんじゃないの? - -そもそも、そうでないと parallel assignment がうまく動かない -はずだよね。 - -というわけで、disp_offset==code_disp_offset は必須ということに -なりました。これで、code_fix_frame_pointer はなくなりました。 - -non destructive creg ってのは、あっても良いかも。 +code_fix_frame_pointer c篏c? +arm/mips с篏powerpc,ia32 с +羔サсс? + +сenv c荐膊 get_register_var ャ障 +сINDIRECT+offset 篁eャ域 + +PowerPC, IA32 сdisp_offset ==0 堺ャ +篋с馹code_segment code_disp_offset disp_offset +堺ャ違mc-codegen 鴻 +disp_offset 荀? + +с parallel assignment 障 + + +сdisp_offset==code_disp_offset 綽 +障сcode_fix_frame_pointer 障 + +non destructive creg cc Sun Jan 15 23:16:10 JST 2006 -あーぁ、ia32 のレジスタ変数がloopでは、virtualがずれるので -うまく動かない。jmp では、標準に直すべきなのか。ってことは、 -ia32 ではレジスタはやっぱり禁止か。か、あるいは、virtual -を止めるかだね。esi/edi はvirtualしないっていう風にすれば -いいか。lreg は? - -いや、だめですね。check_virtual みたいな方法だと、もっと、 -いろいろ変更しないと動かない。use_data_reg() とかは、 -根本的にだめってことじゃないか? (いまさら?) - -use_register(reg,REG_EAX) などが、 reg = use_register(reg,REG_EAX); -という形式ならば、rename し切れなかった時に、別なレジスタを返せる。 - -通常は register はcopy して使うわけだから、rename はされな -い。setup_edx とか、get_register で esi/edi が返されて rename -されてしまった時がまずいわけだけよね。 その時だけ check_virtual -すれば? - -esi/edi をget_regsiter しないと、assop などで、致命的に足り -ないことになる。 - -rname しないとすると、use_data_reg したら、必ず後で戻す -みたいな実装か? - -get_register では data_registerが取れて、get_pointer では、 -esi が取れて、それは、use_data_reg/setup_edx では、使われない -みたいな感じかなぁ。 +若ia32 吾鴻水違loopсvirtual +障jmp с罔羣眼鴻c +ia32 с吾鴻帥c宴胼罩≪virtual +罩≪esi/edi virtualc蘂 +lreg ? + +сcheck_virtual 帥号c +紊眼use_data_reg() +号c? (障?) + +use_register(reg,REG_EAX) reg = use_register(reg,REG_EAX); +綵√違rename cャ吾鴻帥菴 + +絽吾 register copy 篏帥rename +setup_edx get_register esi/edi 菴 rename +障c障 check_virtual +? + +esi/edi get_regsiter assop с翫順莇潟 + + +rname use_data_reg 綽緇ф祉 +帥絎茖? + +get_register с data_registerget_pointer с +esi use_data_reg/setup_edx с篏帥 +帥 Mon Jan 16 08:42:16 JST 2006 -やっぱり ia32 は、設計が悪い。 - - rname, dreg は廃止 - use_data_reg は、use_int などと同じ形式に - setup_edx などは止め、parallel_rassign を使用する - -とすれば、register を復活できるのではないだろうか? -mc-code-mips とかから再構成する? +c宴 ia32 荐荐 + + rname, dreg 綮罩 + use_data_reg use_int 綵√ + setup_edx 罩≪parallel_rassign 篏睡 + +違register 緇羇祉сс? +mc-code-mips 罕? Mon Jan 16 09:03:27 JST 2006 -というわけで、 - -cbc - 環境/インタフェースの切替え - -やっぱり、そのままでは動きませんでしたが、付けてみました。 -うまく使うと、POSIX Thread 的に使うことも可能。 - -例題は CbC_project/device/test/throw.c にあります。 +с + +cbc - 医/ゃ潟帥с若鴻帥 + +c宴障障с障с篁帥障 +障鋎帥POSIX Thread 篏帥純 + +箴蕁 CbC_project/device/test/throw.c 障 code throw(interface1 arg,int i,int j) @@ -8452,28 +8452,28 @@ goto throw1(arg,i,75),space; } -こんな感じで使います。space (切替えるべき環境)は、stack な -のでメモリ領域の一番下を指しているようにしてください。context -とか呼ぶ人もいるだろうな。大きさ的にどれくらいいるかは、 -状況による。64Kbyteはとるべきでしょう。 - -でも、常に interface がコピーされるのでは、あまり意味がない -のか。interface をコピーしないで保存するモードがあれば良い -のかな。 +т戎障space (帥鴻医)stack +с<≪筝筝context +若銀査紊с +倶64Kbyte鴻с + +с絽吾 interface 潟若с障潟 +interface 潟若т絖≪若域 + goto throw1(),space; -みたいな感じ? env が最後を指しているのが不便だが。 +帥? env 緇筝箴帥 code hoge(interface &hoge) {}; -みたいな? もともと参照だしね。引数のずれを防ぐのも考えないと。 -struct に64byteのalignment を入れるか。 - -やっぱり、特定の型を作って、 +帥? с綣違蚊 +struct 64bytealignment ャ + +c宴劫篏c __env env = new_env(size); goto throw(env); -みたいな感じの方がいいのかな。 +帥鴻 int main1() @@ -8485,52 +8485,52 @@ goto throw1(arg,-6,77),space; } -ってな感じで、Cの環境から呼ぶことも可能。 - -space が一番下ってのも変だが、stack だから仕方がない? こういう風に -実装するなら、下向きに延ばすことも可能だが.... C のスタックと干渉 -するから、だめか。 +cсC医若吟純 + +space 筝筝c紊stack 篁鴻? 蘂 +絎茖筝綮吟違純.... C 鴻帥綛我 + Tue Jan 17 10:56:08 JST 2006 -一応、ia32 から rname と dreg は落しましたが.... - - get_register が必ず成功するようにする - register_var をセーブするような手法が必要かも? - free_register で戻す - でも、save されたって言う保証がない? - dreg を使っていたところを get_register に直す - use_data_reg0 を書き直し - -というわけで、結構あるなぁ。(こんなのより論文書いたら?) - -なんか creg=0 をemptyだと思っているみたいだけど、-1 だろ? - -酒飲んでないけど、頭が廻らん。 +筝綽ia32 rname dreg 純障.... + + get_register 綽 + register_var 祉若羈綽荀? + free_register ф祉 + сsave c荐篆荐若? + dreg 篏帥c get_register 眼 + use_data_reg0 吾眼 + +с腟罕(茫吾?) + + creg=0 emptyc帥-1 ? + +蕋蚊с綮祉 Wed Jan 18 11:42:18 JST 2006 -あと、もう少し。code-stringの後の .text のalignはいらんだろ。 - -なんか、creg に reg_var を割り振るように直してしまったが、 -だいたい動いているんだけど、かなり怪しい。その方がコード -は良いんだが.... これは read only creg なんだよね。 - -終りました。tosop は、いい加減だが、あんなもので動くのか。 -要は「tosop に入る前に確保するレジスタは emit_push で確保する」 -「use_register では、code_save_register で使うレジスタを確保する」 -ってことだね。 - -register は0からでなく1から始める。code_gexpr では、creg に -レジスタが入っている場合は、creg を clear。free_register する -場合には、register variable かどうかをチェック。 - -他のも、これにする方が正しそう。 +絨code-string緇 .text align + +creg reg_var 蚊眼障c +鴻潟若 +.... read only creg + +腟障tosop 羝у +荀tosop ャ腆坂吾鴻帥 emit_push х∈篆 +use_register сcode_save_register т戎吾鴻帥腆坂 +c + +register 0с1紮code_gexpr сcreg +吾鴻帥ャc翫creg clearfree_register +翫register variable с + +篁鴻罩c Wed Jan 18 14:47:39 JST 2006 -register の順序を変えると動かなくなるってのは、コードの信頼性が -低いってことなんだよな.... +register 綺紊c潟若篆♂惹с +篏c.... Thu Jan 19 16:49:23 JST 2006 @@ -8538,173 +8538,173 @@ #if 0 { -とかで、type が、おかしくなるらしい。ありそうな話だ。 - -これといい、原因といい、くだらんバグだった。初期化してない -変数を使ってたのにwariningでないのは最適化をかけないからか。 - -register stack overflow ってなかなかでないのね。ローカル -変数をレジスタにマップしない限りレジスタって意味ないのか。 +сtype 荅宴 + +違c +紊違篏帥cwariningс + +register stack overflow cс若 +紊違吾鴻帥吾鴻帥c潟 Fri Jan 20 16:48:01 JST 2006 -なんか ARM の code segment の方のoffset がぼろぼろだ。 -つじつまはあっているんだろうけど。 - -disp_offset==0 のシステムはいいんだよね。ARM だと、 -fp を設定してからregisterをsaveするので、不定の -オフセットが存在する。jump with environment した -時には、その分がずれてしまう。 - -通常のfunction からの goto でも、このずれは存在する -ので、fp の修正はいずれにせよ必要。 - -だけど、jump はcodegenにあるので、汎用に修正しない -といけない。 - -fp を jump/leave 時に offset_label の分だけずらすことに -しました。code_fix_frame_pointer で処理します。 -env を設定したときには、environment は、修正されたfp -を持っているので、fix しないようにします。 - -いずれにせよ、environment は、設定した環境の中で不定の -場所に陣どるので注意が必要。 + ARM code segment 鴻offset 若若 +ゃゃ障c + +disp_offset==0 激鴻ARM +fp 荐絎registersaveс筝絎 +祉絖jump with environment +障 + +絽吾function goto с絖 +сfp 篆罩c綽荀 + +jump codegenс羆篆罩c + + +fp jump/leave offset_label +障code_fix_frame_pointer у障 +env 荐絎environment 篆罩cfp +cсfix 障 + +environment 荐絎医筝т絎 +贋cф絵綽荀 Sat Jan 21 18:06:10 JST 2006 -tosop のつまらないoptimizeのおかげでかなりはまりました。 -これよりは、assignment の方の +tosop ゃ障optimizeс障障 +assignment 鴻 creg = hoge op hoge; *lvalue = creg; -を、 + *lvalue = hoge op hoge; -とする方をやりたいが.... - -converter が、うまくないのは、1 pass だからだよね。multi-path -通るようにできないかな? - -goto hoge(),env; で、env が 0 だったら、fp の切替えをしない -って方が良くない? 出力コードは複雑になるが... +鴻.... + +converter 障1 pass multi-path +с? + +goto hoge(),env; сenv 0 cfp 帥 +c鴻? 阪潟若茲... Mon Jan 23 13:52:32 JST 2006 -あ、なんか、converter すごいかも。やっぱり、このままで、 -c2cbc,cbc2c が楽勝で書けるみたい。なんで 1 pass じゃだめだ -と思ったんだろう? +converter c宴障障с +c2cbc,cbc2c 罐遵ф吾帥 1 pass +c? Wed Jan 25 12:42:57 JST 2006 -c2cbc は、式の途中の関数呼び出しを分解しないといけないので、 -先読み抜きで変換するのは出来ない。だから、expr tree のprint -が必要。逆に言えば、それを作りさえすれば良い。 - -で、expr16 で、strop, binop とかやっているので、それを -parse tree に変更しないとダメ。ってことは、これようの、 -tree id が必要だってことか。逆に言えば、それだけか? - -cbc2c は、code 宣言、goto 文だけを変換すれば良いので、 -可能じゃないか? +c2cbc 綣筝∽医若喝冴茹cс +茯炊у堺ャexpr tree print +綽荀荐違篏域 + +сexpr16 сstrop, binop cс +parse tree 紊眼<c +tree id 綽荀c荐違? + +cbc2c code 絎hgoto 紊域с +純? Wed Jan 25 19:58:40 JST 2006 -cbc2c で、env 切替えはどうやってコンパイルするの? +cbc2c сenv 帥c潟潟ゃ? Thu Jan 26 23:42:18 JST 2006 -やっぱり、strop/array をいじると動かなくなるね。 - -本来、parse tree にtypeは入るべきではないんだよね。 -syntax tree だったら tree にそってparseすればtypeは決まる。 -parse tree だったら、node でtypeは決まっているはず。 - -binop にtypeが二つついているあたりが中途半端な矛盾に -なっているんだよな。 - -そうか、rvalue では、ARRAY/PERIOD/ARROWに RINDIRECT を付けないとダメ。 -ということは、RARRAY/RPERIOD/RARROW/RIVAR があった方が、 -構文木が保存されるから、そっちがいいわけね。 - -確かに、RINDIRECTで、IVAR の先読みをするのはおかしいものな。 - -bitfield と RSTUCT は、なんか変だよ。rvalue の扱いがあまり -consistent でないらしい。 - -問題は、RIVAR の導入でどれくらいバグが出るかだな。 +c宴strop/array + +ャparse tree typeャ鴻с +syntax tree c tree cparsetype羆冴障 +parse tree cnode type羆冴障c + +binop type篋ゃゃ筝腴障 +c + +rvalue сARRAY/PERIOD/ARROW RINDIRECT 篁< +RARRAY/RPERIOD/RARROW/RIVAR c鴻 +罕篆絖c< + +腆冴RINDIRECTсIVAR 茯帥 + +bitfield RSTUCT 紊rvalue 宴障 +consistent с + +馹RIVAR 絨ャс違冴 RIVAR = INDIRECT + IVAR RARRAY = INDIRECT + ARRAY RPERIOD = INDIRECT + PERIOD RARROW = INDIRECT + ARROW -で、良いわけなんですが... - -これで、expr のtreeから、構文木を生成できるはずだが。 +сс... + +сexpr tree罕с Fri Jan 27 20:47:00 JST 2006 -PowerPC で、r1 の下の方を呼び出した関数がいじってしまうのは、 -なんでなんだろう? register save 分かとも思うが、生成された -コードにはそういうのはないんだよな.... - -RIVAR = INDIRECT + IVAR にすると、CRIVAR とかを作らない -といけないらしい。type を持ち歩けば、そのあたりは不要な -わけなんだけど。むしろ逆にRINDIRECT only でもいいわけね。 - -typecheck だけど、goto 文の中で local 変数へのpointer を -持ってたら warning を出すのが望ましい。 - -で、expr のconvert ですが、どうするの? inmode 入れちゃって、 -一気にプリントが簡単ですが.... statement level? なんか、 -構造がまったく変わっちゃうな。時間かかるかも。 +PowerPC сr1 筝鴻若喝冴∽違c障 +с? register save +潟若.... + +RIVAR = INDIRECT + IVAR CRIVAR 篏 +type ≧違筝荀 +RINDIRECT only с + +typecheck goto 筝 local 紊違吾pointer +c warning 冴障 + +сexpr convert с? inmode ャ<c +筝羂潟膂≦с.... statement level? +罕障c鎀c< Mon Feb 6 20:31:48 JST 2006 -statement expression とかがあるので、結局は、全部 -印刷しないとだめ。ってことは、tree_parse を書き直さない -とだめだね。 - -cast とかが落ちる可能性もあるので、正確には元に戻せない。 - -あと、type_print mode との切替えをするかどうかだな。 -切替えはするんだと思うんだけど.... うまく出来るかどうか -が問題。しない方が簡単だが、そうすると、conv/*.c の -整合性が良くないか。それもいいけどさ。 - -gen_inline なんかで、 +statement expression с腟絮 +医激ctree_parse 吾眼 + + +cast 純<醇сс罩g∈祉 + +type_print mode 帥 +帥.... 障堺ャ +馹鴻膂≦conv/*.c +翫с + +gen_inline с Fri Feb 10 21:18:41 JST 2006 -gcc のinclude path を Makefile (じゃなくて、mc-code-*.c か) -に取り込む仕組みが必要だね。 +gcc include path Makefile (mc-code-*.c ) +莨若篁腟帥綽荀 Sat Feb 18 20:45:46 JST 2006 -そうか local_struct_init だけど、式での初期化があるから、 -memcpy で実装するのは良くないわけね。もちろん、式があった -どうかを判断することは出来るんだけど... + local_struct_init 綣с +memcpy у茖<綣c +ゆ堺ャ... Sun Mar 5 20:05:41 JST 2006 -やっぱり、print_expression とか、print_statement とか -作るじゃない? +c宴print_expression print_statement +篏? Fri Mar 17 18:33:16 JST 2006 gcc -print-search-dirs -ってのがあるのか。 +c Mon Mar 27 12:08:08 JST 2006 -64bit support と、SSE3 とかの対応を入れた方がいいかな。 -本当に、浮動小数点処理にSSE3を使うのが普通なのかどうかは -知らんけど。 - -Intel のコンパイラを見るべきなのか? +64bit support SSE3 絲上ャ鴻 +綵羌絨亥劫SSE3篏帥 +ャ + +Intel 潟潟ゃ荀鴻? Tue Mar 28 23:59:57 JST 2006 -C_FUNCTION の get_name を見た後、nptr->dsp を設定するべきか? +C_FUNCTION get_name 荀緇nptr->dsp 荐絎鴻? *cheap->ptr = 0; cheap = increment_cheap(cheap,&name); @@ -8713,34 +8713,34 @@ // if we already have this, hash_search will reset cheap nptr->dsp = i; -再利用を考えると、これじゃないか? (また、時間があったら、直そう...) +? (障c眼...) Sun Apr 16 17:41:36 JST 2006 -やっぱり、list の実装が見えるのは良くない。GC を入れても良いし。 -そういう意味では、そろそろ捨ててもいいし、作り直しても良いんだよな。 - -list のタグで要素の型がわかる方がいいけどね。ということは、 -Object で構成するってこと? Java で書き直してもいいけど。 -まぁ、いいろいろイキヅマリガあるよな。 +c宴list 絎茖荀GC ャ +潟с篏眼 + +list 帥違ц膣鴻 +Object фc? Java ф吾眼 +障ゃ Wed Apr 19 14:37:36 JST 2006 -list を必ずtag付きにして、型を決め打ちすれば良い。gettree を -任意のベクタにすると良いね。 - 型 expression +list 綽tag篁羆冴<域gettree +篁紙帥 + expression int double long double long long NMTBL xx extension -3bit x n ぐらいか? +3bit x n ? 9 bit tag 4 bit type tag (singed, long long, float, double, char, short) 3 bit length - 15 bit (3*5) 型リスト -ぐらい? + 15 bit (3*5) 鴻 +? #define GSYMS (8192*32) #define HEAPSIZE 120000 @@ -8748,27 +8748,27 @@ #define LBUFSIZE 4096 #define STRSIZE 4096 -ここら辺も初期値をオプションで指定できた方が良い。 +莨冴ゃ激с潟ф絎с鴻 Mon May 29 02:52:40 JST 2006 -そうか... sse2 をサポートしないと、やっぱりだめなのね。 -Pen 4 以上では。 +... sse2 泣若c宴 +Pen 4 篁ヤс Wed Jun 21 14:58:17 JST 2006 -64bit 対応とかいろいろあるよな。 -SPU は比較的容易にサポート出来そう。 - -でも、それより先に、 - statement を含むparse tree のprint - statement を含むparse tree のS式表現のprint - S式表現のparser -を書かないと。 +64bit 絲上 +SPU 罸莠絎号泣若堺ャ + +с + statement parse tree print + statement parse tree S綣頫憗print + S綣頫憗parser +吾 Wed Sep 6 16:42:43 JST 2006 -gcc の C99 だと、 +gcc C99 __builtin_fabsf(__x) // float __builtin_fabs(__x) // double @@ -8776,17 +8776,17 @@ __builtin_inf() __builtin_inff() -とかいうのがあるみたいだね。 - -cheat するより、実装するのが簡単か? +帥 + +cheat 絎茖膂≦? __DBL_MIN__ 1.17549435e-38F __DBL_MIN__ 2.2250738585072014e-308 __LDBL_MIN__ 2.00416836000897277799610805135016e-292L -も内蔵なのか。まぁ、これは書けば良いだけだが。 - -long double ねぇ。こんなのやるのやだ ... +泣障吾域 + +long double ... int foo asm ("myfoo") = 2; @@ -8799,50 +8799,50 @@ extern func () asm ("FUNC"); -こんな brain dead があるのか。困ったものだ。 - -これ、どうやって実現するのかな。attribute でしょうね。ASM_NAME か、なんか? -とりあえず無視? - -__asm になっているからだめなので、__asm も 処理すると「無視する」モードに -なっていることがわかりました。 + brain dead 違c + +c絎憗attribute сASM_NAME ? +∴? + +__asm cс__asm ∴≪若 +c障 Thu Sep 7 10:41:54 JST 2006 -attribute だと、毎回チェックがうざい。nptr->nm を直接変える方が望ましいが... -key と表示のポインタを分ければ簡単に実現できるんだけど。 - -Intel Mac は、relocatable code なので、ptr_cache を実装する必要が -あるらしい。register 変数を破棄すれば可能かも。 - -offset pointer は、使う直前で取得するのでもOk。ループの中だと嫌だが... -そうすれば大域変数を使用しないルーチンでは、取得ルーチンを省ける。 -SSE2 を含めて、PowerPC スタイルに変更した方が合理的なんだろうな。 - -でも、時間的にはけっこうかかってしまうみたい。 - -もう一つの、goto hoge(a,...); だけど、結局、stack を実装することに -なるんじゃないの? 大域的なsyntax sugar だと考えることも可能では -あるが、コードが共有されるところが異なる。.... の部分がメモリ -に乗るというのを保証して、それ以外を別なところにあるというのが -確定しないとまずい? - -もう少し考えてみないと実現できるかどうかわからない。 +attribute 罸сnptr->nm 贋・紊鴻障... +key 茵腓冴ゃ潟帥亥亜絎憗с + +Intel Mac relocatable code сptr_cache 絎茖綽荀 +register 紊違贋医純 + +offset pointer 篏帥翫у緇сOk若筝絆... +医ぇ紊違篏睡若潟с緇若潟 +SSE2 PowerPC 鴻帥ゃ紊眼鴻 + +сcc障帥 + +筝ゃgoto hoge(a,...); 腟絮stack 絎茖 +? 紊уsyntax sugar 純с +潟若掩違.... <≪ +箙篆荐若篁ュャ +腆阪障? + +絨帥絎憗с Sun Sep 10 11:46:30 JST 2006 -return がないとかのwaringを出した方が良いね。 -それほど難しくないはず。 +return waring冴鴻 +祉c Sun Sep 10 22:05:38 JST 2006 -test/i3.c がひどい... +test/i3.c 蚊... Wed Sep 27 13:47:47 JST 2006 -PowerPC の 構造体の引渡しが int とかと混在すると、gcc と整合しないらしい。 +PowerPC 罕篏綣羝< int 羞桁gcc 翫 .globl _main01 _main01: @@ -8864,83 +8864,83 @@ stw r10,132(r30) lwz r0,108(r30) -あぁ、integer の要素の場合は、先頭のいくつかは、レジスタに -マッピングされるみたいだね。 - -これは、なんかあったな。ARM は、そういう仕組みになっていて -対処しているみたいだね。なんでだろう? - -あ、そうか。Intel Mac の対応があるんだった... しくしく。 - -filep の overflow をチェックしてない。(こういうの多そう...) +integer 荀膣翫ゃ吾鴻帥 +潟違帥 + +cARM 篁腟帥c +絲上帥с? + +Intel Mac 絲上c... + +filep overflow с(紊...) Sat Oct 7 13:41:13 JST 2006 -inline のswitchの展開ぐらいいれた方がいいが... +inline switch絮鴻... 0x19d9c <__i686.get_pc_thunk.bx>: mov (%esp),%ebx 0x19d9f <__i686.get_pc_thunk.bx+3>: ret -ですか。 - -string は、ebx でPC相対で取って来るわけね。(ださ〜) ということは、 -やっぱり、一つレジスタを潰さないとだめか。 - -しかも、EBX なわけ?! - -大域変数は、 +с + +string ebx PC後障уcャ() +c宴筝ゃ吾鴻帥羹違 + +EBX ?! + +紊у紊違 leal L_uc1$non_lazy_ptr-"L00000000006$pb"(%ebx), %eax movl (%eax), %eax movb $-56, (%eax) -だから、やっぱり、レジスタ一つ EBX とは別に潰すことになる。 - -ということは、デフォルトでレジスタが二つ潰れるわけね。 - -で、ptr_cache は使うの? ううーん... 使っても害はないはず。 -ptr_cache は get_register() が絶対失敗しないことに依存している -んだよね。 - -そして、浮動小数点の計算は、すべて mmx(sse2) らしい。ぶぅ。 -mmx は 8 個レジスタがあるわけね。 - -もしかすると、修正は以外に少ないかも。 +c宴吾鴻推 EBX ャ羹違 + +с吾鴻帥篋ゆ衆 + +сptr_cache 篏帥? 若... 篏帥c絎潟 +ptr_cache get_register() 腟九上け箴絖 + + +羌絨亥鴻荐膊鴻 mmx(sse2) 吟 +mmx 8 吾鴻帥 + +篆罩c篁ュ絨 Tue Oct 10 02:15:24 JST 2006 -む。先ながそ。 - -Intel Mac の global_table() がめんどくさい.... + + +Intel Mac global_table() .... Tue Oct 10 22:13:24 JST 2006 -define されたfucntion へのcallはstub を経由する必要はない。 -ってことは、defined されたかどうかの attribute があった -方がいいね。 - -あぁ、なんか「関数呼び出す引数の分だけ、スタックを取っておいて、 -関数呼び出し時にスタックを調整するようなことはしない」 -なのか。 - -おっと、stack は 16byte alignment でなければならないわけね。 - -あ、そうか。ebp が-12 offset だと、16byte alignment に一致しない。 - -use_data_register() と ptr_cache() の相性が良くないらしい。 - -偶然動いたりするのか... しくしく。 - - -use_data_reg() で初期化してない変数を使ってました。 - -"hoge" "hage" を #ifdef で挟むと動かない... (ふーん...) - -escape() 内部で処理したのが間違いだったみたいだね。 -このコードは呼ばれないはずなので取り去るべき。 +define fucntion 吾callstub 腟宴綽荀 +cdefined attribute c +鴻 + +∽医若喝冴綣違鴻帥c +∽医若喝冴鴻帥茯炊眼 + + +cstack 16byte alignment с違 + +ebp -12 offset 16byte alignment 筝眼 + +use_data_register() ptr_cache() 御с + +句九... + + +use_data_reg() у紊違篏帥c障 + +"hoge" "hage" #ifdef ф... (泣若...) + +escape() уc帥 +潟若若違уサ鴻 Thu Oct 12 00:05:15 JST 2006 -switch 文で、行き先がおなじ分を「まとめる」ってのを -してない。range にまとめられるなら、それが有利か。 +switch с茵障c +range 障 Thu Oct 12 12:08:36 JST 2006 @@ -8957,9 +8957,9 @@ goto cont(i,j,...); } -の実装なんだけど.... fix typed stack あるいは、bounded stack かな? - - * gotoを呼び出した関数のr1 ! r1(goto前のr1) +絎茖.... fix typed stack bounded stack ? + + * goto若喝冴∽違r1 ! r1(gotor1) # * r30 <---r1_offset---------> r1 r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -8967,277 +8967,277 @@ f20-f31 <-my_func_args--><--disp-----><-max_func_arg-> *SIZE_OF_INT *SIZE_OF_INT -長さが知り得ないので、code local variable をどこに取っていいか -わからないという問題がある。ふん。 - -呼び出されたときのstack (っていうのかな?) top を見れば良いのかな? -local variable 分も入っているようですが.. まぁ、r30 使っても -いいんだけど。 - -ということは、「隠れて、code segment argument の長さを持ち歩く」 -ってことだね。その方が良い。 - -あぁ、でも、PowerPC とかだと、local variable は、r30 からの -固定オフセットで取っているのか。いや、そんなことないな。 -r1 からアクセスしているようですね。 - -いや、関数呼び出しの時の引数をr1から積んでいるらしい。 -これは変更しないとだめだね。 - -i386 でも、%ebp からアクセスしているな。 +激ャ緇сcode local variable c +馹泣 + +若喝冴stack (c?) top 荀域? +local variable ャcс.. 障r30 篏帥c + + +code segment argument 激≧ +c鴻 + +сPowerPC local variable r30 +阪祉уc +r1 ≪祉鴻с + +∽医若喝冴綣違r1腥с +紊眼 + +i386 с%ebp ≪祉鴻 | frame pointer | stack pointer v----> argument local <--------v -という形にしないとだめか。stdarg を使うためには、順序を関数呼び出しに -合わせないとだめだが... - -つまり、local variable を CALLER ARG 上にとってやれば -良いらしい。問題は、stack をずらしたとき(alloca)に、 -pointer がずれるってことだが... (それはcopyするか...) - -逆に言えば、これをやれば、動きます。ということだね。メモリの -アクセス範囲は | frame pointer --> <--- stack pointer | -に閉じるわけか。 - -意味的には、全体を展開してしまえば、全部固定長になるので、 -問題はない。 - -ちょっと、修正が多いかな... +綵≪stdarg 篏帥綺∽医若喝冴 +... + +ゃ障local variable CALLER ARG 筝c +馹stack (alloca) +pointer c... (copy...) + +荐違違障<≪ +≪祉合蚊 | frame pointer --> <--- stack pointer | + + +括篏絮障違阪激с +馹 + +<c篆罩c紊... Wed Oct 18 21:35:36 JST 2006 -GVAR の dsp は(initialization のフラグ以外) 空いているので、 -ここに、asm("alias") の属性を入れるのは構わない。まぁ、毎回、 -attribute チェックしてもいいんだけど。そんなけちる意味もな -いので、alias field をNMTBL に足してもいいんだけどね。 - -function の場合は、属性に入れるんでしょ? +GVAR dsp (initialization 遺札紊) 腥冴с +asm("alias") 絮сャ罕障罸 +attribute с<潟 +сalias field NMTBL 莇潟 + +function 翫絮сャс? Tue Oct 31 20:16:16 JST 2006 -関数の引数に固定長の配列を渡すと破綻するらしい。 (test/ps2.c) -gcc には可変長配列ってのもあるにはあるんだよな。 - -構造体と同じ扱いにしたが。 - -いや、違うな... ARRAY は integral なんじゃないのか? -単なるpointerだろ? 違うの? - -大域変数の倍 +∽違綣違阪激羝<雁胸 (test/ps2.c) +gcc 紊潔c + +罕篏宴 + +... ARRAY integral ? +pointer? ? + +紊у紊違 array + array -引数の場合 +綣違翫 pointer -> array + pointer -> array -引数の配列は、ポインタとして扱うわけだが、typedef されている -場合もある。 - -typedef されてなくても、多次元配列の倍数がずれるというバグが -あるらしい。 - -わかった。引数の配列型は、ポインタ型に変換されるのだが、そ -れは、typedef される場合もあるので、def() で行う必要がある。 -また、adecl や decl で処理すると、多次元配列の場合に二回処 -理されてしまう場合があるらしい。 - -これに関連して、a[1][1]だと、(e+1)+1 みたいなコードがでて、 -これは、binop で最適化出来ないね。 +綣違ゃ潟帥宴typedef +翫 + +typedef 紊罨≦違違 + + +c綣違ゃ潟水紊 +typedef 翫сdef() ц綽荀 +障adecl decl у紊罨≦翫篋 +障翫 + +∫ca[1][1](e+1)+1 帥潟若с +binop ф堺ャ Wed Nov 1 23:23:41 JST 2006 -そうか、push_struct で、ARMのcodeを入れてやれば、PowerPC 版 -も簡単に出来そう。 - -callee 側は、どうせスタックに書き戻しているんだから別に -良いわけね。 - -ARM のpush_struct を全部持って来た方がいいらしい。 +push_struct сARMcodeャ違PowerPC +膂≦堺ャ + +callee 眼鴻帥吾祉ャ + + +ARM push_struct cャ鴻 Sat Nov 4 19:40:49 JST 2006 -なんか、i3 のエラーを直してないね。見送りにしたわけ? +i3 若眼荀? Sat Nov 4 22:47:13 JST 2006 | frame pointer | stack pointer v----> argument local <--------v -なんだけど、これだと、local variable のoffsetが、その場で -定数にならないという問題があるんじゃないの? - -いや逆か。sp からなら、必ず定数になるわけね。 - -subroutineから、code を呼び出す時に、parallel assignment -が使えないが、この場合は、sp の値は決まっているはず。 -というか後で合わせれば良い。caller_arg を sp からの -オフセットで書き込む必要がある。 +local variable offset眼 +絎違馹? + +sp 綽絎違 + +subroutinecode 若喝冴parallel assignment +篏帥翫sp ゃ羆冴障c +緇у域caller_arg sp +祉ф吾莨若綽荀 | frame pointer | stack pointer v----> argument local <--|-----v caller_arg -というわけかな。 - -caller_arg は、関数の最後でないと決まらないので、large offset -では、やっぱり、困る。(だから、local var を fp からにしたの -だったが...) + + +caller_arg ∽違緇с羆冴障сlarge offset +сc宴違(local var fp +c...) | frame pointer | stack pointer v----> argument local <--|-----v caller_arg -にすればいいんだろうけど... 許されるのか? いくつかのアーキテクチャ -では、そうなっているらしいが。 - -まぁ、MAX caller arg を決めるっていう手もあるけどね。その方が -楽か.... +違... 荐宴? ゃ≪若 +сc + +障MAX caller arg 羆冴c鴻 +罐純.... Sun Nov 5 14:21:19 JST 2006 -expr16 で statement expression をparseしようと思うと、 -IVARが生成されてしまうので気まずい。pexpr するのは、 -少しおかしい。 - -やっぱり parse してからcompileするモード作る? そうすると、 -いろいろ出来るようになる。inmode=PARSE とかいうのを作るか。 - -細かい問題があるみたいだね。 +expr16 statement expression parse +IVAR障ф障pexpr +絨 + +c宴 parse compile≪若篏? +堺ャinmode=PARSE 篏 + +膣違馹帥 Mon Nov 6 21:00:47 JST 2006 -asm("name") の属性の処理をしないと。急ぐのか? - -asm/attribute の区別が必要。 - -n->nm は、そここで使っているので、やっぱり、search 用の名前と -表示用の名前と分けた方が良い。一旦、hash を引いてしまえば、 -表示用の名前の方でいいんじゃないか? orignal へのポインタは -用意するとして。n->nm, n->name と二重にする手もあるけどね。 -そっちのが方が断然やさしいが。 +asm("name") 絮сャ? + +asm/attribute 阪ャ綽荀 + +n->nm т戎cсc宴search +茵腓榊鴻筝hash 綣障違 +茵腓榊鴻с? orignal 吾ゃ潟帥 +n->nm, n->name 篋 +c<鴻吟 Fri Nov 17 19:04:49 JST 2006 -local variable のalignment を、mc-codegen.c の def() で -制御する必要がある。stack のalignment 以上には制御できない -わけだけどね。 - -attribute に出て来るidentifierって予約語じゃないんだよな。 -どう処理しようかな。最初の1文字とか... (本気か?!) - -まぁ、name space を専用に作るのが普通だろうとは思うが... - -順調に進んでいるけど。 - -typedef されたsymbol に付いているattribute を引き継ぐ必要が -ある。それは、どこで... +local variable alignment mc-codegen.c def() +九勝綽荀stack alignment 篁ヤ九勝с + + +attribute 冴ャidentifierc篋膣茯 +1絖... (羂?!) + +障name space 絨篏... + +茯帥蚊с + +typedef symbol 篁attribute 綣膓綽荀 +... Sun Nov 19 14:10:54 JST 2006 -なんか、ia32/gcc 2.9 の時のvarargs が壊れているらしい。 - -ARMのスタックalignmentは、ずれているようだ... stack top -自体がalignされているべきだと思うので、直すんだろうな。 +ia32/gcc 2.9 varargs 紕 + +ARM鴻帥alignment... stack top +篏align鴻с眼 Tue Nov 21 05:06:37 JST 2006 -struct のaligned(16) (引数無しもあるらしい...) だけど、 -nptr に set_attribute してしまってはだめらしい。関数の -arugment もそう。 - -typedef された attribute は、どうする? もともと、タイプ -の方に attribute してやれば、こんな問題は出ないのだが... -hoge *p; では、hoge のattribute を引き継いではだめ。 - -ってことは、set_attr は要らないってこと? (かもね...) +struct aligned(16) (綣亥<...) +nptr set_attribute 障c∽違 +arugment + +typedef attribute ? 帥ゃ +鴻 attribute 違馹冴... +hoge *p; сhoge attribute 綣膓с + +cset_attr 荀c? (...) Sun Nov 26 13:15:39 JST 2006 -code segment のvariable interface を許すためには、Intel の -stack code を直した方が良い。 - -alloca のgexpr は、binopされてないので、最適化されない... - -あぁ、ia32 は、lvar_intro とかも使ってないわけね。 -offset は、結構複雑になるので、直す方が良いらしい。 - -時間かける価値あるの? 少しかかりそうだな... +code segment variable interface 荐宴Intel +stack code 眼鴻 + +alloca gexpr binopс... + +ia32 lvar_intro 篏帥c +offset 腟罕茲с眼鴻 + +箴≦ゃ? 絨... Fri Dec 1 22:45:28 JST 2006 -long double の実装ねぇ。 +long double 絎茖 Mon Dec 25 22:02:12 JST 2006 f((struct arg){.fuga = 3}); -が、うまくうごかない。init_vars は、いつどこで評価されるべきなの? +障init_vars ゃц箴<鴻? decl_str_init -あたりなみたい。 - -うーん、結構、壊して来ちゃった。 +帥 + +若腟罕紕ャ<c f((struct arg){.fuga = g()}); -みたいな場合もあるよね? +帥翫? flush_local_static_struct() -あたりをちゃんと直さないと。 +<眼 Sat Jan 13 18:52:37 JST 2007 -emit_init_vars() は ad-hoc にしちゃだめ。どこで出て来るかわからない -んだから。 - -あと、式のcarに0を入れるのは反則なはず。 - -tmp7.c が通らないぞ。 +emit_init_vars() ad-hoc <у冴ャ + + +綣car0ャ + +tmp7.c Sun Jan 14 20:01:03 JST 2007 -やっぱり、ちょっと変更が大きいけど、タグに木の大きさを入れるべきだな。 - -あぁ、そうか。 +c宴<c紊眼紊с帥違紊сャ鴻 + + ## f((struct arg){.fuga = 3,.aho=5}); -とかだと、構造体はstackに積めば良い。だが、exprの中で、emit_init_vars -してしまうと、それは出来ない。deleyed みたいな扱いをすればいい? -実際に使われるところでemit_init_vars() するみたいな? +罕篏stack腥域expr筝сemit_init_vars +障堺ャdeleyed 帥宴違? +絎篏帥emit_init_vars() 帥? Wed Jan 24 14:12:20 JST 2007 -get_register_var を使った後、free してない例が多いみたい。 +get_register_var 篏帥c緇free 箴紊帥 Sat Apr 28 21:00:15 JST 2007 -どうも、code_dassop のテストをしてないらしい。 - -i387 の演算で、use flag を間違えると、387 のstack overflow -が出るらしい。g_expr は use flag を1にするので注意。 +code_dassop 鴻 + +i387 羲膊сuse flag 387 stack overflow +冴g_expr use flag 1ф絵 Sun Apr 29 23:59:16 JST 2007 -mc-ia32 では、function callをpush を使わないように直さないとだめ -らしい。浮動小数点もSSE2に直すべきでしょう。結構、めんどくさい。 - -long double もいるのかなぁ。 - -mc-powerpc for PS3 は、なにがこけるのかよくわからん。 - -mc-spu も、まだまだ、やることはあるらしい。この三つをいつ片付けるの? -一緒にか? - -まぁ、のりの問題だがな。 - -64bit 対応をどうするんだろう? +mc-ia32 сfunction callpush 篏帥眼 +羌絨亥鴻SSE2眼鴻с腟罕 + +long double + +mc-powerpc for PS3 + +mc-spu 障障筝ゃょ篁? +筝膩? + +障馹 + +64bit 絲上? Fri May 4 20:07:59 JST 2007 -なるほど。PS3 だと、register に乗った引数の分は、スタックが -取られてない。だから、bl regsiter_save する前に、stack を -移動する必要がある。 +祉PS3 register 箙c綣違鴻帥 +bl regsiter_save stack +腱糸綽荀 Breakpoint 3, 0x1000068c in i50 () (gdb) x/20x $r1 @@ -9248,36 +9248,36 @@ 0xff9e0130: 0x00000016 0x00000017 0x00000018 0x00000019 (gdb) q -そうすると、浮動小数点の場合は... +羌絨亥鴻翫... Sat May 5 03:32:27 JST 2007 -dofor で、docomp で、RC を読んだときに、{...} k++; で、k を -既に読んでしまっている。その後に、leave_scope しても、current nptr -は、update されない。なので、leave_scope 中で、nptr を書き換える必要がある。 - - -PS3 ppc の make diff が通らない... -code-gen-all の inline も - -PPCで、inc_flag をしないと、long long の比較でしくじる - -PS3 ppc は、レジスタ2が予約らしい (library で使うとアウト) - -bitfield がずれている。 +dofor сdocomp сRC 茯{...} k++; сk +≪茯с障c緇leave_scope current nptr +update сleave_scope 筝сnptr 吾綽荀 + + +PS3 ppc make diff ... +code-gen-all inline + +PPCсinc_flag long long 罸莠с + +PS3 ppc 吾鴻2篋膣 (library т戎≪) + +bitfield Sat May 5 13:10:05 JST 2007 -ia32 のidiv/imull の符号の扱いがおかしいらいが.... - -いや、これは引数の呼び出し順序の問題ですね。これを -変えるのは不可能ではないのだが... - -ia32 のmake diff が通らないのは、「まだ」stack frame がずれ -ているからだ。%edi を壊しているね。 +ia32 idiv/imull 膃垩宴.... + +綣違若喝冴綺馹с +紊筝純с... + +ia32 make diff 障stack frame +%edi 紕 (gdb) x/20x $r1 0xff909150: 0xff909180 0x00000000 0x00000000 0x00000001 @@ -9292,18 +9292,18 @@ 0xff9091d0: 0x0000001a 0x0000001b 0x0000001c 0x0000001d 0xff9091e0: 0x0000001e 0x0000001f 0x00000020 0x00000021 -PS3 のPPC は、やっぱり引数の上に、なんか乗っているんだな。それが普通なのか。 -だったら、そうするか。(stdarg を内蔵関数以外で実現することが出来なくなるが) +PS3 PPC c宴綣違筝箙c +c(stdarg 級∽遺札紊у憗堺ャ) Sun May 6 09:31:46 JST 2007 -Ps3のPPCはできたけど、開いている穴の大きさが8と16の差がある。r1_offset の制御が -出来てないみたいだね。 +Ps3PPCс腥眼紊с816綏r1_offset 九勝 +堺ャ帥 Sun May 6 17:47:59 JST 2007 -statement expression が関数の引数の中で呼ばれると、 +statement expression ∽違綣違筝у若違 b L1 L2: @@ -9316,25 +9316,25 @@ L1: ......... saved input in register var %esi - b L2 (a) が起きて、%esi を壊す + b L2 (a) 莎激%esi 紕 L3: value -となって、esi を壊してしまう。complex argument のsaveと衝突するわけ -だ。 - -これは、他のarchitecure でも起きる問題なのか。ちょっと、 -根が深いな... - -statement expression の中で、temp として使ったregister var -のlistを覚えておいて、それを LCALL でsave restore してやれ -ば良い。 - -あるいは、LCALL の時点で使っているレジスタ変数をすべて -save/restore すれば良い。こちらの方が簡単だが量が多い。 - -そうすると、statement expression の中で変更された -レジスタ変数をoverwriteしてしまうので、だめ。 +cesi 紕障complex argument save茵腦 + + +篁architecure с莎激馹<c +鴻羞宴... + +statement expression 筝сtemp 篏帥cregister var +list荀 LCALL save restore +域 + +LCALL 鴻т戎c吾鴻水違鴻 +save/restore 域<鴻膂≦紊 + +statement expression 筝у眼 +吾鴻水違overwrite障с b L1 L2: @@ -9347,82 +9347,82 @@ ......... saved input in register var %esi save_register %esi - b L2 (a) が起きる + b L2 (a) 莎激 L3: restore register %esi value -というタイミングか。それよりは、その時点でparse treeを展開した方が -まだ、ましか... - -あるいは、docomp する時に、全てのレジスタ変数を使ったことに -しておくか... それでも、ia32 ではだめだけど。 - -inmode==INLINE+1 の時に、若干展開が異なる。gen_inline() -する方がいいのか? - -うーん、それも、いろいろ面倒なようだね。どうせ、やらなきゃ -いけないんだが。 - -とりあえず、ad-hoc に直したが、あとで、ちゃんと直さないと。 -(get_input_arg AS_SAVE で、register variable を使わなければ良い...) - -展開するしかないんだろうなぁ。 - -実は Sun Jan 1 10:59:19 JST 2006 の時点で気づいていたのだが、 -忘れてしまったらしい.... - -resgister save すると、({ goto hoge; .... }) で、かなり困る。 +帥ゃ潟違鴻parse tree絮鴻 +障障... + +docomp 吾鴻水違篏帥c +... сia32 с + +inmode==INLINE+1 ュ慌絮違gen_inline() +鴻? + +若√ + + +ad-hoc 眼с<眼 +(get_input_arg AS_SAVE сregister variable 篏帥域...) + +絮 + +絎 Sun Jan 1 10:59:19 JST 2006 鴻фャ +綽障c.... + +resgister save ({ goto hoge; .... }) с違 Fri May 25 19:12:04 JST 2007 -関数をparse する時に、inmode == INLINE でcompileして pfdecl して -やれば、parse tree base になる。 - -fdecl/doif などで !inmode のコードは通らなくなるので、全部、 -取り除いてしまって構わない。mc-inline.c の st_if などは、 -むしろ、codegen.c にあるべきだったのか。こうなると、mc-parse は、 -parser のみになるので、その意味でも正しいね。 - -こうすると、大抵のものはglobal heap に置かれてしまうので、GCが -必須になる。もともと、getfree は複雑すぎるので... local heap -stack を縮めるのは止めて、 +∽違parse inmode == INLINE compile pfdecl +違parse tree base + +fdecl/doif !inmode 潟若с +ゃ障c罕mc-inline.c st_if +codegen.c 鴻cmc-parse +parser 帥с潟с罩c + +紊ф泣global heap 臀障сGC +綽getfree 茲... local heap +stack 膰罩≪ (1) - 全部local heapにとり、関数をcompileして、pfdecl したあと、 - 型宣言とかinline funcitonのみを global heap にコピーする。 + local heap∽違compilepfdecl + 絎hinline funciton帥 global heap 潟若 (2) - 汎用のGCを書いて、statement のtop levelで、それを読んでやる。 - あるいは、スタック上のlocal heapを含めて任意の時点で GC する - (こちらの方が正統的だが、遅そうだ...) - -という手があるね。まぁ、そのままでも kernel compile とかしない -限りは、だいじょうぶだとは思うが... - -parse tree を取った後の、最適化に関しては、まぁ、いろいろ可能だが、 -そんなに無理してもしょうがない。 - -arg_register は、もっと頭が良い方がいいが... - -UDPCL 側に影響が出る可能性を否定できないが... コード生成は、 -st_if 側に限るんだろうな。 - -GC やるんだろうなぁ。変更的には、結構大きくなるが... - -code_decl 用の pcode_decl を書く必要があるようだね。 + 羆GC吾statement top levelс茯с + 鴻帥筝local heap篁紙鴻 GC + (<鴻罩g輝...) + +障障障с kernel compile +吟... + +parse tree c緇≪障純 +∞ + +arg_register c鴻... + +UDPCL 眼綵演帥冴醇с絎с... 潟若 +st_if 眼 + +GC 紊雁腟罕紊с... + +code_decl pcode_decl 吾鏆荀 Fri Jun 8 13:53:53 JST 2007 -まぁ、それは置いておいて、mc-spu の方をやるか。is_int_reg とかが -あるので、 +障臀mc-spu 鴻is_int_reg +с REGS_MAX = 128*3 -ぐらいにする? +? Tue Jul 31 13:33:59 JST 2007 -delc_data は inline tree にならない。これは、良くないので、 -一旦、parse tree に落す必要がある。 +delc_data inline tree с +筝parse tree 純綽荀 list(ST_DECL,next,nptr,type,(mode,smode,stmode),initialize) initialize @@ -9430,282 +9430,282 @@ list(ARRAY,next,e); ={1,2,3} list(CAST,next,type,e); ={(struct hoge){..}) -かな? - -decl_data_*は、offset を返すのではなくて、式を返す。 - -その式を解釈する assign_data シリーズを新しく作る。 - -(いろいろ書いているけど、進まないね〜) +? + +decl_data_*offset 菴с綣菴 + +綣茹i assign_data 激若冴違鋎 + +(吾蚊障) Fri Aug 3 18:06:49 JST 2007 -CAST/DECL_DATA は、あとは、コード生成を書くだけか。 - -結局、inmode only にして書き直すのかな〜 +CAST/DECL_DATA 潟若吾 + +腟絮inmode only 吾眼 Wed Sep 12 19:53:33 JST 2007 -DECL_DATA のコード生成が全然書いてないじゃん〜 - -つうか、でたらめかも... もう少し考えないとだめだ。 +DECL_DATA 潟若倶吾 + +ゃс... 絨 Mon Sep 17 16:56:54 JST 2007 -print_operator も書いてないのか。 +print_operator 吾 Fri Sep 28 07:04:00 JST 2007 -やっぱり、pexpr 内部で、type 大域変数にアクセスするのは、 -まずいだろ? +c宴pexpr сtype 紊у紊違≪祉鴻 +障? Sat Sep 29 12:48:30 JST 2007 -デバッグが果てしない... +違... Sat Sep 29 14:25:41 JST 2007 -なんか、むちゃくちゃ難しいよ... +<<c... Mon Oct 1 18:10:30 JST 2007 -decl_data は、いちおうできた。 - -あとは、code segement も pexpr から生成するようにして、 -default で inmode になるようにすれば良い。 - -今の逐次生成モードは残すのか? 出来ることと出来ないことが -かなり違うからなぁ。 - -これで、parse tree から、元のソースを復活できるようになった -ので、c2cbc が書けます。 - -でも、まぁ、spu やるか? +decl_data <с + +code segement pexpr +default inmode 域 + +篁罨∞≪若罧? 堺ャ堺ャ + + +сparse tree 純若鴻緇羇祉сc +сc2cbc 吾障 + +с障spu ? Tue Oct 2 17:49:09 JST 2007 -いろいろ微妙に動かない。 - -scope のinline が動かない。 - -fact-a の print のnptr の扱いが変。 - -code segment の宣言の扱いは不便すぎる。(2 path を書くか?) +緇絋 + +scope inline + +fact-a print nptr 宴紊 + +code segment 絎h宴筝箴帥(2 path 吾?) Fri Oct 5 16:47:49 JST 2007 -Intelのnested function call order は直しました。 - -CAST を pexpr で展開しないと、contains_p でCONVがひっかからない。 - -あとは、 - fact-a の print のnptr の扱いが変。 -ここだけ。 +Intelnested function call order 眼障 + +CAST pexpr уcontains_p CONV蚊c + + + fact-a print nptr 宴紊 + void print( void (*print)() ) { } -とした時にまずい? - -これは、local_scope の中で enter_scope するかどうかの問題 -だったようです。 - -関数定義の時のnptr は、def していないようだ... +障? + +local_scope 筝 enter_scope 馹 +cс + +∽医臂nptr def ... Sat Oct 6 15:47:41 JST 2007 -ようやっと出来たよ... - -COMPの構文を保存してない。 - -fdecl を pfdecl を呼び出すようにする。(直接生成はoptionで残す?) +c堺ャ... + +COMP罕篆絖 + +fdecl pfdecl 若喝冴(贋・optionф?) Sun Oct 7 17:43:42 JST 2007 -parse tree を導入するのだったら、one path mode は、切ってしまった -方が、mc-parse.c が小さくなる。どうせ、debug しなくなるだろうし。 -case 文の逐次比較モードと同じか。 +parse tree 絨ャcone path mode c障c +鴻mc-parse.c 絨debug +case 罨≧莠≪若 goto(fuga(ab,c)) -みたいな構文にすれば、#define で reflection 可能。まぁねぇ。 -でも、通常、引数の拡大が必要 (meta state)。やっぱり、汎用の -reflection 構文が必要なんじゃないかな〜 +帥罕違#define reflection 純障 +с絽吾綣違≦ぇ綽荀 (meta state)c宴羆 +reflection 罕綽荀 __code goto(fname,args,...) { goto(); } -を定義すると、goto そのものの意味が変わるというのが良い? - -anchor も考えてないしな〜 - -そうか、ia32 を sse2化するっていうのも残っているのか。 -どこで mmx register を save する? caller 側? +絎臂goto 潟紊? + +anchor + +ia32 sse2c罧c + mmx register save ? caller ? Mon Oct 8 00:24:58 JST 2007 -main のinline化で、まだ、通ってないものがたくさん。float が -若干おかしいらしい。varargs/alloca がだめらしい。 - -あぁ、そうか。エラーメッセージの表示場所がわからなくなってしまう。 -これは、あれをやるしかないのか? +main inlineс障cfloat +ュ慌varargs/alloca + +若<祉若吾茵腓阪贋c障 +? Mon Oct 8 14:13:57 JST 2007 -inline されたlocal 変数のscope は? top level だけ変? +inline local 紊違scope ? top level 紊? Wed Oct 10 13:46:49 JST 2007 -cast は、(float)1 みたいなのだと、correct_type は、rvalue する。 - -(hoge *)p みたいな場合でも、ravlue するべき? 左辺のcastの -場合は、rvalue してはまずい。右辺では? RSTRUCT では? - -うーん、やっぱり RCAST が必要なみたいだな。correct_type では、 -int/long などの時には、rvalue している。これは正しい。 -CAST は、rvalue されない。ravlue では、CASTは no touch。 - -わかりました。 +cast (float)1 帥correct_type rvalue + +(hoge *)p 帥翫сravlue 鴻? 綏莨冴cast +翫rvalue 障勈昇с? RSTRUCT с? + +若c宴 RCAST 綽荀帥correct_type с +int/long rvalue 罩c +CAST rvalue ravlue сCAST no touch + +障 1422 type = cadddr(e1); 1423 return correct_type(pexpr(e2),caddr(e1)); -で、pepxr(e2) が type を書き換えている。prindirec で、間違った -type を返しているのがまずい。両方直すんだろうな。 +сpepxr(e2) type 吾prindirec сc +type 菴障筝≧合眼 Wed Oct 17 18:36:23 JST 2007 -だいぶ破壊しちゃったよ... RSTRUCT が一貫してない。mc-code-*.c -を直すのは本末転倒。-r scope-fix までだと、変更が多すぎる。 - -はぁ〜 ちょっと頭痛い。酒か、血圧か? 血圧計が欲しい... - -まぁ、順調に進んではいるんだけどねぇ。 +句翫<c... RSTRUCT 筝莢mc-code-*.c +眼荵√-r scope-fix 障с紊眼紊 + + <c茵с? 茵ц罨蚊... + +障茯帥蚊с Wed Oct 24 01:15:25 JST 2007 -PowerPC の方が diff が通る。微妙になんか残っているようだが... - -IA32 は、diff が通らない。何故だ? - -あぁ、switch のparse mode がぜんぜん通ってないよ... -non parse mode の inline は、通っているのに。 +PowerPC 鴻 diff 緇絋罧c... + +IA32 diff 篏? + +switch parse mode c... +non parse mode inline c Wed Oct 24 08:33:49 JST 2007 -switch をparse mode で二回 inline 展開すると破綻するらしい。 +switch parse mode т inline 絮雁胸 Wed Oct 24 11:06:55 JST 2007 -parse mode は出来ました。長かった... - -macro / inmode の干渉が macro_if で起きるとは意外でした。 - -pexpr で、stack がどんどん深くなるのは良くない... - -pexpr は、parse にappend するべきなんでしょう。reverse がうるさいが。 - -adhoc に code_save_register_stack とか使ったけど、本当は、 -削除出来るんだろ。 +parse mode 堺ャ障激c... + +macro / inmode 綛我 macro_if ц儀鎀с + +pexpr сstack 羞宴... + +pexpr parse append 鴻сreverse + +adhoc code_save_register_stack 篏帥c綵 +ゅ堺ャ Thu Oct 25 08:19:20 JST 2007 -Mac OS X も、LP64 なので、 +Mac OS X LP64 с http://www.unix.org/version2/whatsnew/lp64_wp.html -このcompilerも、int->long に書き換える必要がある。 -ということは... +compilerint->long 吾綽荀 +... #define int long -でも、いいんだけど... +с... int i; printf("%d\n",i); -で、こける。 +с int i; printf("%ld\n",i); -でないとだめ。 - -やっぱり、pointer が入る部分だけ、long に書き直すのが良いのかな。 - -ふーん.... PPCの書き換えは、それほど大変ではなさそうだが... - -むしろ、long double の実装の方がなぁ... - -switch で、long long ってのもありみたいだね。まぁ、64bit のみで -実装と言うのが良いんでしょうけど。 - -long を64にするのは、難しくないが、int がshort と同じ扱いになるの? -extend するのもあれだが... +с + +c宴pointer ャlong 吾眼 + +泣若.... PPC吾祉紊ус... + +long double 絎茖鴻... + +switch сlong long c帥障64bit 帥 +絎茖荐с + +long 64cint short 宴? +extend ... Fri Oct 26 12:41:38 JST 2007 -pointer の書き換えはいいんだけど、bug を取りにくい。 -mc-macro で、car にstring pointer を入れているのは、 -どうする? +pointer 吾bug +mc-macro сcar string pointer ャ +? Sat Oct 27 13:30:55 JST 2007 -けっこう、スムースだな... macro のと、ST_DECL あたりに、 -なんか残っているらしい。 +c鴻若鴻... macro ST_DECL +罧c Thu Nov 8 21:16:12 JST 2007 -switch 文が const で inline された時の処理が間違っているようだ.... +switch const inline c.... Sun Nov 11 22:24:59 JST 2007 -cslist がなんだか思い出せないが、直りました。 +cslist 冴眼障 Wed Nov 14 13:03:42 JST 2007 -で、SPU だけど.... cross compiler と binutil いれるか... - -128 のレジスタを三つ持つのもなんなので、そのまま。ということは、 -use_int とかは必要ない? is_int_reg とかは、必要ないわけね。 -じゃぁ、このままいくか... - -SPU のほとんどの演算は vector 演算なのか。このコンパイラって、 -そういう新しいデータを構造を増やすのに向いてないんだよね。 +сSPU .... cross compiler binutil ... + +128 吾鴻帥筝ゆゃс障障 +use_int 綽荀? is_int_reg 綽荀 +障障... + +SPU 祉羲膊 vector 羲膊潟潟ゃc +違若帥罕紜 8bit, 16bit, 32bit, 32bit x 4 -かぁ。vector type を足すんだろうなぁ。vector_add とかはださいが... - -あぁ、そうか。関数呼び出しでも16byte単位でスタックに積むわけね。 -printf は、どうしようもなく stack に積むらしい。 - -byte を書き込むってことは出来ないらしい。ふーむ。 - -これは、local/global memoryを使うこと自体、禁止という感じのようですね。 - -まぁ、とりあえず動かすことを考えて、vector 型とかは、あとで導入しよう。 +vector type 莇潟vector_add ... + +∽医若喝冴с16byte篏с鴻帥腥 +printf stack 腥 + +byte 吾莨若c堺ャ泣若 + +local/global memory篏帥篏胼罩≪с + +障vector уャ Wed Nov 14 18:42:42 JST 2007 -PS3 powerpc が動かなくなってるよ。 - -argment/local variable の alignment は、当然、system 依存か... - -size_of_int と size_of_pointer を区別しないと... - -parallel assign でレジスタをsaveしているけど、size_of_int だと -足りない。なので、get_register_var に変えるべきでしょう。 -(もったいないけどね) -memmove との干渉があるので、get_register は使えない。 - -target のsize_of_int と compiler の size_of_int も別にしないと。 -なるほど。 - -new_lvar 自体を直した方がよさそうだな〜 たくさん使われているし。 - -get resiter var すると、save code が出ちゃうので、微妙に -痛しかゆしなんだよな。まぁ、それに文句言うなら、もっと、 -ちゃんと、register assignment しないといけないわけだけど。 - -データ型を拡張しやすくするのは重要だよね。C++ じゃないけどさ。 +PS3 powerpc c + +argment/local variable alignment 綵吟system 箴絖... + +size_of_int size_of_pointer 阪ャ... + +parallel assign с吾鴻帥savesize_of_int +莇潟сget_register_var 紊鴻с +(c) +memmove 綛我сget_register 篏帥 + +target size_of_int compiler size_of_int ャ +祉 + +new_lvar 篏眼鴻 篏帥 + +get resiter var save code 冴<с緇絋 +障ヨc +<register assignment + +若水≦宍荀C++ #define FASS (FOP+ASS) #define FCMPGE (FOP+CMPGE) @@ -9715,110 +9715,112 @@ #define FCMP (FOP+CMP) #define FMINUS (FOP+MINUS) -とか、かっこわるいし。type 自体に、処理メソッドへのポインタを -設けるんだろうなぁ。 ちょっと修正が多いけど。少し考えてみないと。 +ctype 篏<純吾ゃ潟帥 +荐 <c篆罩c紊絨帥 Tue Nov 20 15:22:43 CET 2007 -SPUはかならず16byte でアクセスして、その後で、shuffle byte -で処理する形らしい。なので、char でも、16byte load して、 -変更して書き込みという形になる。 - -local 変数に関しては、16byte alignment で処理して、shuffle -byte を避けるので良いと思う。ただ、pack されたstruct とか -はだめ。でも、lvar だったら、offset を見れば良い。 - -でも、配列とかのアクセスだと、 +SPU16byte с≪祉鴻緇сshuffle byte +у綵≪сchar с16byte load +紊眼吾莨若帥綵≪ + +local 紊違≪16byte alignment уshuffle +byte 帥цpack struct +сlvar coffset 荀域 + +с≪祉鴻 lqd $2,176($sp) cbd $3,0($sp) shufb $2,$4,$2,$3 stqd $2,176($sp) -が必須となる。まぁ、そうでしょうね。 - -大域変数の場合も同様? 16byte alignment を仮定して良いらしい。 - -pointer の場合はだめで、shuffle byte が必須。 - -ptr_cache は、SPU の場合は、使わない方が良いらしい。256k -しかメモリがないので、オフセットで足りてしまうらしい。 -16bit(64k) + 2bit alignment というわけですか。 - -code もそれに含まれる? +綽障с + +紊у紊違翫罕? 16byte alignment 篁絎 + +pointer 翫сshuffle byte 綽 + +ptr_cache SPU 翫篏帥鴻256k +<≪с祉ц恭障 +16bit(64k) + 2bit alignment с + +code 障? Sat Nov 24 11:19:15 CET 2007 -mc-code-spu.c をどんどん破壊しているなぁ。 +mc-code-spu.c 翫 Sun Nov 25 12:21:26 JST 2007 -メモリ上に取られる局所変数は、spu ではほとんどないと思って良い。 -アドレスを取られているか、構造体か、どちらか。 - -構造体もできるだけレジスタ上に置いた方が良い。それは、st_* で -処理する? どういう条件で、構造体をレジスタにマップ出来るかは、 -結構、複雑らしい。 - -かなり限定した場合だけにしてもいいんじゃないか? - -だとすれば、メモリ上の局所変数へのアクセスは、あまり効率 -良くなくても良いということ。だから、常にpackされていると -仮定して良い。 +<≪筝絮紊違spu с祉c +≪鴻罕篏< + +罕篏с吾鴻推臀鴻st_* +? >散с罕篏吾鴻帥堺ャ +腟罕茲 + +絎翫? + +違<≪筝絮紊違吾≪祉鴻障合 +絽吾pack +篁絎 Sun Nov 25 21:07:43 JST 2007 -REGISTER.field の形式のみの時に、register にmapする? -別にそうでなくても良いんだけど。 - -address を取られてなければ、register にmapして良い。 - -register 上にpackして、構造体を置く。でも、SPUの -場合は、pack した方が良い場合と、そうでない場合を -識別する必要がある。それは難しいだろ? (不可能じゃ -ないだろうが...) +REGISTER.field 綵√帥register map? +ャс + +address 違register map + +register 筝pack罕篏臀сSPU +翫pack 鴻翫с翫 +茘ャ綽荀c? (筝純 +...) Sun Nov 25 22:07:53 JST 2007 -char で16byte取るのも良いんだけど、char a[10] とかで、 - *(a+1) = 3 とかやられると、だめ。こいつは、連続している -必要がある。(逆に言えば、SPUでは、そんなことをしては -いけない...) - -でも、毎回、shuffle byte するのは(32bit int でも、 -おこなう必要がある)ちょっと... - -いずれにせよ、一般的なbyte(8-32bit)アクセスを書く必要は -ある。で、それが曖昧だからだめだめなんだよね。subroutine -call してもいいんじゃないか? - -sp が16byte alignment だってのは仮定していいの? (おそらくは...) -じゃぁ、cbd 8(sp)ってのが意味不明。 +char 16bytechar a[10] с + *(a+1) = 3 ゃg +綽荀(荐違SPUс +...) + +с罸shuffle byte (32bit int с +綽荀)<c... + +筝byte(8-32bit)≪祉鴻吾鏆荀 +ссsubroutine +call ? + +sp 16byte alignment c篁絎? (...) +cbd 8(sp)c割 Wed Nov 28 12:32:13 JST 2007 -おっと、ptr_cache を取るのは早すぎたが... lqa は aligned address -しか扱わないので、汎用のshuffle byte code を使えない.... +cptr_cache ... lqa aligned address +宴с羆shuffle byte code 篏帥.... Tue Dec 25 22:22:11 JST 2007 -あぁ、Recursive Macro は、やっぱり扱ってないじゃないか〜 +Recursive Macro c宴宴c Mon Jan 21 11:46:52 JST 2008 -PS3 PPC が動かなくなっているんだよな。 +PS3 PPC c Wed Jun 11 17:49:30 JST 2008 -Recursive macro は、一旦、macro_epansion/getsymを出てしまうと、history -を使った recursive check にはひっかからない。 - -check_recursive にひっかかっても、もう一度、retry されてしまうので、 -意味がない。 - -chptr の切替えでmacro_history をclearすると、get_name_from_chhptr() -で clear されてしまうので、そのあと check_recurse しても無意味。 - -難しいな.... - -clear するタイミングを prev_macro_end でおくらせる。 - - +Recursive macro 筝macro_epansion/getsym冴障history +篏帥c recursive check 蚊c + +check_recursive 蚊cc筝綺retry 障с +潟 + +chptr 帥macro_history clearget_name_from_chhptr() + clear 障с check_recurse ≧潟 + +c.... + +clear 帥ゃ潟違 prev_macro_end с + +Sat Nov 8 15:06:22 JST 2008 + +違c
--- a/Idea Fri Nov 07 20:12:29 2008 +0000 +++ b/Idea Sat Nov 08 15:11:06 2008 +0900 @@ -1,88 +1,88 @@ Thu Nov 25 17:27:12 JST 1999 -subroutine call がない -局所変数もない -その代わり、大域変数を多用する -大域変数のスコープは局所的 -Fortran の用に局所変数は静的に取る -recursion する時には、自分で保存する -subroutine call時のレジスタのセーブも局所的に行う -それは、ちょっと変じゃない? -やっぱりデフォルトのフレームは持ち歩くか? - -recursive call とそうでないのを区別するか? - -fp は用意する方が良い - -関数定義と同時に、それ専用のfpの構造体を用意する - -C をcompileする時には、stackを持ち歩く +subroutine call +絮紊違 +篁c紊у紊違紊 +紊у紊違鴻潟若絮 +Fortran 絮紊違 +recursion т絖 +subroutine call吾鴻帥祉若絮茵 +<c紊? +c宴若≧? + +recursive call с阪ャ? + +fp 鴻 + +∽医臂絨fp罕篏 + +C compilestack≧ fp = (struct func_state *)stack -えっと、どこに代入するの? そういう問題もあるわけね。 -じゃあ、fpは特別? それは気に入らないな。static -なfpにすれば良いわけね。 +c篁eャ? 馹 +fp劫? 羂ャstatic +fp域 func(void *stack) { static struct func_state { static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -func_state をとってくる演算子があった方が良い? そうね。 +func_state c羲膊絖c鴻? func.state -ぐらい? - -fp->local1 みたいなことだけするなら、C と同じになる。 - -call する時のargument も、 - static な func_state に置く - stack 上の func_state に置く -という二通りの選択肢がある。Cと互換なら、当然、後者。 - -Recursive なら後者だが、この言語は状態遷移を記述するから、static -なものでも良いはず。 - -Internal function は? あってもいいんだけど... - -Recursive call する時には、 fp をsaveする必要があるね。 +? + +fp->local1 帥C + +call argument + static func_state 臀 + stack 筝 func_state 臀 +篋御≪C篋綵吟緇 + +Recursive 緇荐茯倶欠Щ荐菴違static +с + +Internal function ? c... + +Recursive call fp save綽荀 (--(struct func_state *)stack) = fp; call callee(&fp->arg,continuation,stack); -call しても、戻って来ないから... continuation は一般的にはcode -だから... それは Internal function にするか。 - -continuation に一般的にcompileする方法を考えないといけないか。 -self は必要なわけね? - -言語の名前も考えないといかんなぁ。 - -C からのコンパイラも書かないといけないのか... +call 祉cャ... continuation 筝code +... Internal function + +continuation 筝compile号 +self 綽荀? + +荐茯 + +C 潟潟ゃ吾... Mon Dec 13 18:53:04 JST 1999 -compiler based で、内部で partial evaluation できる? - -func をdatabaseとして扱えないなら、それはできない。 - -しかし、状態遷移としては取り扱える。 +compiler based с partial evaluation с? + +func database宴с + +倶欠Щ宴 func.state func.code -みたいな形にしてpartial evaluationすれば良い - -でも止まるのか? - -textual でない、中間的なコード表現があった方が良い? <-> interpreter? - -Prolog ではなんでいけないの? --> Unification が重いから +帥綵≪partial evaluation域 + +с罩≪障? + +textual с筝潟若茵憗c鴻? <-> interpreter? + +Prolog сс? --> Unification Sat Nov 27 13:50:41 JST 1999 -func.state とか作るのだったら、 +func.state 篏c struct { struct { int i; @@ -91,11 +91,11 @@ i = i+1; }; } name; -みたいな形で、それ自体を構造化すれば? で、代入すると部分評価される。 -代入も可能。なるほど。 +帥綵≪с篏罕? с篁eャ荅箴< +篁eャ純祉 *name.code; -値はあるわけ? 値は &state でしょうね。 -self があれば、 +ゃ? ゃ &state с +self 違 struct { struct { int i; @@ -104,39 +104,39 @@ self->i = self->i+1; }; } name; -かな。self = state だよね。 - -union の拡張もあわせて議論すると... - -Partial evaluator をセマンティクスや実行系にいれておくことは可能か? - -byte code とか仮想マシンだったら可能。そうでない場合は? - -いずれにせよ、構造体のタグのunique性を修正しないとだめだな。 - -ヘッダファイルはどうするの? +self = state + +union ≦宍茘域... + +Partial evaluator 祉潟c鴻絎茵膤祉純? + +byte code 篁潟激潟c純с翫? + +罕篏帥違uniqueс篆罩c + +<ゃ? Mon Dec 13 18:53:18 JST 1999 -library との整合性は? - -exec sequence では、 +library 翫с? + +exec sequence с (--(struct func_state *)stack) = fp; call callee(&fp->arg); -という形でpointerだけ渡すの? それは変だよね。 - -値渡しにするとすれば、複数の値を渡せたほうが良い。 +綵≪pointer羝<? 紊 + +ゆ検違茲違ゃ羝<祉 func(void *stack) { static struct func_state { static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -の引数自体が、構造体であるべき。 +綣域篏罕篏с鴻 func( struct void *stack @@ -145,11 +145,11 @@ static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -で、構造体に register storage を許す。 +с罕篏 register storage 荐宴 func( static struct argument { @@ -161,11 +161,11 @@ static struct func_state *fp; int local1; brahbrah... - } func_state; // ここまで hidden + } func_state; // 障 hidden func_state.fp = (stack -= sizeof(struct func_state)); } -すると、caller の方も、構造体を引数とするのが自然。 +caller 鴻罕篏綣違吟 call caller( static struct argument { @@ -174,23 +174,23 @@ } arg = {a,b}; ) -みたいな。もちろん、この構造体はインタフェースと呼ばれる。 - -argument は、callee にあった方が良いけど、caller 側にあっても -良い。register なんかは、そう。 +帥<罕篏ゃ潟帥с若鴻若違 + +argument callee c鴻caller 眼c +register caller(interface caller_arg = {a,b,c}) -みたいなsyntax かな。 +帥syntax caller->interface = {a,b,c}; *caller->code; -を、 + caller(a,b,c); -と称する。 - -function には、interface と code と state があることになる。 - -state にアクセスする時のlockは? protected state? synchronized state かな? -もちろん、sequential implementationでは、そんなものはいらない。 +腱違 + +function interface code state + +state ≪祉鴻lock? protected state? synchronized state ? +<sequential implementationс function { interface: @@ -203,72 +203,72 @@ b = a; } -int にvoid value を定義する。実装は重くなるけど... - -serialized の semantics は? - -もう少しmicro-Cに近く! - -carrying state と static state。 +int void value 絎臂絎茖... + +serialized semantics ? + +絨micro-C菴! + +carrying state static state Mon Dec 13 19:42:41 JST 1999 -interface に register keyword を使うのは、あまりに -実装よりすぎる。でも、でないと状態にできない? -そんなことはないか。やっぱりcaller側のstatic 領域に -直接書き込む? - -だとCより遅そう。でも、引数に40個とかかかれたら... +interface register keyword 篏帥障 +絎茖сс倶с? +c宴caller眼static +贋・吾莨若? + +Cс綣違40... Wed Dec 15 14:09:49 JST 1999 -C と互換にする? +C 篋? goto function(arguments); goto *continuation(arguments); -みたいな感じで。 - -stackの管理は? どうせ、library との互換はとらないと -いけないんだから... - -local 変数がある場合は stack を動かす。でも、戻す奴がいない。 -closure 化するか? - -return した時の挙動が複雑になる。大域returnするわけだら。 - -arguments をstatic 領域にかきこむ方式だと互換性がとれない。 -stack 上の frame pointer 上にないとダメだから。 - -両立させるのは無理か? つまり、これだと、呼び出された方の -frame semantics は、C と互換になる。だから、stackの直後に -frame pointer があると思っている (そうか? ) frame pointer -stack pointer に沿って移動した直後に、そこからのoffset -で引数を操作することになる。 - -つまり、それはだめだったことじゃない? つまり、goto だと、 -frame pointer は、stack の直後とは限らないから。前の -frame pointer 相対に引数にアクセスしてくれれば別だけどね。 - -stack に引数を積むのは容認して、goto の場合は、向こう側で -stack を畳むってのは? ということは、普通の関数と定義の -方法を変えるってことか。ま、悪くはないか。 - -すると、goto のsemantics は、C と互換になる。それを受ける -方が異なることをする。それは、なんかおかしいな。それに、 -それだと関数呼び出しが軽くならない... - -ということは、やはり、C のcall は、call function で -実現して、その他の呼び出しは、すべて、goto 扱いに -する方が正しいだろう。 - -問題は、この言語の関数をcallされた時だな。dual entry にして、 -call の時と、goto の時を区別するか。 +帥с + +stack膊∞? library 篋 +... + +local 紊違翫 stack с祉絅眼 +closure ? + +return 茲紊уreturn + +arguments static 劫篋с +stack 筝 frame pointer 筝< + +筝∞∞? ゃ障若喝冴鴻 +frame semantics C 篋stack翫 +frame pointer c (? ) frame pointer +stack pointer 羃帥c腱糸翫offset +у違篏 + +ゃ障c? ゃ障goto +frame pointer stack 翫 +frame pointer 後障綣違≪祉鴻医ャ + +stack 綣違腥絎壕goto 翫眼 +stack 潟c? ∽違絎臂 +号紊c障 + +goto semantics C 篋 +鴻違 +∽医若喝冴荵純... + +C call call function +絎憗篁若喝冴鴻goto 宴 +鴻罩c + +馹荐茯∽違calldual entry +call goto 阪ャ func: stack processing func_goto: normal processing ... -みたいな感じ。でも、return はないから... - -このあたりも自分で記述できる言語であるべきだよね。その通り。 -つまり、C とのstub も自分で記述すると言うことか。 +帥сreturn ... + +ц菴違с荐茯с鴻 +ゃ障C stub ц菴違荐 protocol function { interface c { @@ -288,120 +288,120 @@ }; } -みたいな感じでさ。さっすが、アセンブラ。いまいちreturnが汚いけど。 -まぁ、return はそのままreturnでもいいけどさ。 - -あ、これは良いかも知れない。code が複数かけるから。 - -state 以外は、consistent state であることを保証しない。ってのは? -local 変数は使っても良いけど、call/goto の前後で、値を保証しないか... - -うーん、だんだん炸裂してるなぁ。 - -だから、レジスタに対するマッピングの記述と、そうでない部分の -記述は分離するべきでしょうね。 - - -全部一辺に実装するわけにはいかないからぁ... +帥сc≪祉潟障return羆 +障return 障returnс + +ャcode 茲違 + +state 篁ュconsistent state с篆荐若c? +local 紊違篏帥ccall/goto 緇сゃ篆荐若... + +若梧 + +吾鴻帥絲障潟違荐菴違с +荐菴違≪鴻с + + +筝莨冴絎茖... Thu Dec 16 13:44:21 JST 1999 -lock は状態遷移レベルで実現するのだから、self などを -使ってlockする必要はないはず。 - -全体の直列化は、状態遷移レベルで、 +lock 倶欠Щу憗self +篏帥clock綽荀 + +篏翫倶欠Щс lock(storage) -> transition -みたいな形で記述すれば良い。この当たりを、どのように記述するかは -もう少し先送りしよう。 - - -引数はレジスタ渡しにしよう。長い引数は、呼び出し側の領域への -ポインタとする。実装を規定しても良い。そうすれば、varargs -みたいなものはなくなる。だいたい、なんで、そんなものがいるんだろう? -配列を渡せばいいじゃん。 - -なので、引数は一つ(or 二つ)に限るという方法もある。 - -とすると、やはり、前もって静的領域や動的領域を確保することは -できない。 - -この言語では動的領域は自分で確保するわけだから、その点は問題ない。 +帥綵≪ц菴違域綵荐菴違 +絨 + + +綣違吾鴻炊検激綣違若喝冴眼吾 +ゃ潟帥絎茖荀鎘違varargs +帥с? +羝<違 + +с綣違筝(or 篋)号 + +c腆坂 +с + +荐茯сх∈篆鴻馹 Thu Dec 16 20:24:55 JST 1999 -とすると関数呼び出しは、 +∽医若喝冴 # register save # set 1st argument in register %eax # set 2nd argument in register %ecx # set extra arguments in save area # set extra argument pointer in %edx jmp function -という形式になるわけね。second を処理するのはめんどくさいから一つ -にしよう。 - -えーと、frame pointer はないけど、コンパイルの手順からすると -あった方が良い。しかし、frame pointer そのものをstatic -にとるのはまずい。だから、frame pointer がfirst argument -ということにする方が正しい。とすると引数は、さらに、その -後と言うわけか。 +綵√second 筝 + + +若frame pointer 潟潟ゃ +c鴻frame pointer static +障frame pointer first argument +鴻罩c綣違 +緇荐 f(fp,argument) -fp を渡すのにさらにargument をレジスタで渡すのはおかしい。おかしいけど、 -ま、良いか。 - -return しないなら、return type の定義をとるのは変だな。 - -f(fp,arg1,arg2,arg3) とすると、それぞれが決まったレジスタに入って、 -多い分は配列にあると思われる。ふむふむ... +fp 羝<argument 吾鴻帥ф検 +障 + +return return type 絎臂紊 + +f(fp,arg1,arg2,arg3) 羆冴障c吾鴻帥ャc +紊泣泣... fp->xx -でアクセスすれば、そのまま局所変数になる。全部、配列で -送っても良い。 +с≪祉鴻違障上紊違 +c .set label,value -で as は値をセットするようですね。 - -関数コールの後は戻って来ないから後始末の心配はしなくてよい。 -frame pointer を使ったら自分で面倒を見ること。 - -だと + as ゃ祉с + +∽違潟若緇祉cャ緇紮綽 +frame pointer 篏帥cч√荀 + + a = atoi(s); -みたいなことはできない... - -普通のCの定義と交じると間違いやすい。 - -とすると、struct と同様に、 +帥с... + +C絎臂篋ゃ + +struct 罕 protocol code interface state -を用意するわけね。時間あるのかぁ? - -とりあえず、register 渡しのfunction 定義とgoto文を実装する。 +? + +register 羝<function 絎臂goto絎茖 code name(register "%ebp" void *arg) { goto name(arg); } -ぐらいかな? で、first argument が必ずregisterにのるようにしないと -いけない。register storage class を入れて、 +? сfirst argument 綽register +register storage class ャ register "%ebp" void *arg -とかするわけね。 - -ってことは、まず、レジスタを実装しないといけないわけね。 - -で、stack を使った演算は、一応、そのままにする? それでも動くはず。 -式の途中でgotoは使えないんだから、それでいいはず。 - -で、それから、これを拡張していく。 + + +c障吾鴻帥絎茖 + +сstack 篏帥c羲膊筝綽障障? с +綣筝goto篏帥с + +с≦宍 interface c { register "%ebp" void *arg; } code name(interface c) { - goto name(c.arg); // c. は省略可能 + goto name(c.arg); // c. ュ } -とかね。さらに、 + protocol name { interface c { @@ -415,28 +415,28 @@ } } -などとするわけか。なんと、これが C と共存するわけね。うーん。 + C 怨若 Fri Dec 31 11:44:03 JST 1999 -code でなくて、別な名前のほうが良くない? segment? action? - -レジスタ名が入るのは、やっぱりいや。optionalには許す。 - -interface は構造体のようなものだから... 構造体でいいんじゃない? -構造体の場合は... malloc する? う、うーん。malloc するとして、 -いつfree するの? - -再入するときには、壊れてていいんじゃない? multi-thread でなければね。 -multi thread では、状態は、レジスタ経由または、thread local に持つ -必要がある。static は、だから thread local に持たなくてはならない。 -大域変数に割り振っちゃだめ。でも、いまは、やめて - -interface は、とりあえず、二つまでの値渡しにしよう。 - self と arg -ですね。 - -もう少し拡張しやすいコンパイラがいいなぁ。 +code сャ祉? segment? action? + +吾鴻水ャc宴optional荐宴 + +interface 罕篏... 罕篏с? +罕篏翫... malloc ? 若malloc +free ? + +ャ紕? multi-thread с違 +multi thread с倶吾鴻睡宴障thread local +綽荀static thread local +紊у紊違蚊c<с障 + +interface 篋ゃ障сゆ検 + self arg +с + +絨≦宍潟潟ゃ code name (c,a) struct state *c; struct arg *a; @@ -444,62 +444,62 @@ goto name(arg); } -local 変数は? この互換性の問題かぁ。 - -KL/1 を意識して、interface は heap に置くことにしても良い。 -GC は言語に入れておくべきだが、interfaceは machine independent -であるべき。だとすれば use/forget みたいものはいるだろう。 -でも今のところは考える必要はない。 - -えーと、 +local 紊違? 篋с馹 + +KL/1 顑interface heap 臀 +GC 荐茯ャ鴻interface machine independent +с鴻 use/forget 帥 +с篁綽荀 + +若 code name (c,a) struct state *c; struct arg *a; { int i; goto name(arg); } -の時の一時変数iはどうするの? 基本的にはレジスタ割り当てだけど... -使用させない? んー、大胆な御意見。まぁ、やっぱりheapに割り当てちゃう -のが簡単か。でも、どうせ抜ける時にはいらなくなるわけだから... - -ほんらい、この変数は、次のcallでは必要無くなるのが普通。 - -とにかく、レジスタ変数は必要なんでしょう? - -だから、GC と合わせて言語を設計すべきだよね。API を規定して、 -異なるGCを選択できるようにする。 +筝紊i? 堺吾鴻水蚊綵... +篏睡? 若紊ц緇≧頳障c宴heap蚊綵< +膂≦с... + +祉紊違罨<callс綽荀< + +吾鴻水違綽荀с? + +GC 荐茯荐荐鴻API 荀鎘 +違GC御с Sat Jan 1 22:40:22 JST 2000 -とーにかく、 storage class register を実装しよう。 +若 storage class register 絎茖 stmode=REGISTER -で、local storage とおなじ扱いとする - static register? は、ない。 - -symbol table に storage class をたせば? dsp==EXTRN で判定しているから、 -local 変数が36以上あるとおかしくなるぞ? - -sc は GVAR/LVAR だけど、register は LVAR の特殊な奴だから、 -sc に入れるほうが正しいか... +сlocal storage 宴 + static register? + +symbol table storage class ? dsp==EXTRN уゅ +local 紊違36篁ヤ? + +sc GVAR/LVAR register LVAR 号絅眼 +sc ャ祉罩c... Sun Jan 2 01:47:17 JST 2000 -register 変数はできました。けど、register を二つ使うと、 -一杯になってしまうので、REGISTER6 でコンパイルしないと -結構ひどい。が、register 変数を%esi,%edi に割り当てれば -いいか。 +register 紊違с障register 篋や戎 +筝c障сREGISTER6 с潟潟ゃ +腟罕蚊register 紊違%esi,%edi 蚊綵 + Sun Jan 2 04:43:04 JST 2000 -で、 +с code name (c,a) struct state *c; struct arg *a; { goto name(c); } -の一時変数無しは実装できます。引数は二つまでね。 +筝紊亥<絎茖с障綣違篋ゃ障с .file "tmp.c" .version "01.01" @@ -520,27 +520,27 @@ .size code,_5-code .ident "Micro-C compiled" -う、すごい。 - -goto 文がめんどくさい。stack をたたんで、jmp すれば -よいだけだが.. + + +goto stack сjmp +.. Sun Jan 2 11:17:50 JST 2000 -普通のcallをcontinuation baseにすることができる? +callcontinuation baseс? Sun Jan 2 20:28:45 JST 2000 -goto 文だけど、やはり、一度、expr で生成してから、top level -で jump code を生成しよう。 +goto 筝綺expr хtop level + jump code Tue Jan 4 03:32:55 JST 2000 -code をtypeにしないと、 +code type code *p; -とか書けないね。 +吾 int *p(); -と同じだけどさ。 + main(ac,av) @@ -562,21 +562,21 @@ Tue Jan 4 04:56:56 JST 2000 -うーん、なんかレジスタにつむ順序が違う -これは、adecl がreverseにつむから。 - -code のreturn - -やはりcodeはtypeにしないとだめ。 +若吾鴻帥ゃ綺 +adecl reverseゃ + +code return + +codetype main() { goto code1(); } -とかだと、main に戻って来れない。もちろん、code1() 以降で、 -return するわけにはいかない。(main の disp をcode1 は知り得ない) -goto label をcode1の引数に送れば? +main 祉cャ<code1() 篁ラс +return (main disp code1 ャ緇) +goto label code1綣違? main() { @@ -584,20 +584,20 @@ ret: } -これだと、ret がforward labelかどうか分からないけど? - -code1 中で使う中間変数を stack 上にとるのは悪くない。しかし、それを -%ebp 経由でアクセスするということは、main の中間変数を壊すということ。 -それを防ぐには、main 中のgoto codeで、%ebp を修正してやれば良い。 -(今は戻って来ないので問題ない) - -code1 のgoto では、戻って来ないから、その必要はない。しかし、 -label をcode1 中で渡されると、ちょっと気まずい。 - -とすると、それは禁止して、main() 中でstackをたたんでからgotoするか? -そうすると、無限後退して、結局、帰れないことになる... うーん。 - -main() 中のlocal code を許せば、それは解決するが.. +ret forward label? + +code1 筝т戎筝紊違 stack 筝 +%ebp 腟宴с≪祉鴻main 筝紊違紕 +蚊main 筝goto codeс%ebp 篆罩c域 +(篁祉cャу馹) + +code1 goto с祉cャ綽荀 +label code1 筝ф検<c羂障 + +胼罩≪main() 筝stackсgoto? +♂緇腟絮絽違... 若 + +main() 筝local code 荐宴違茹f浦.. main() { @@ -607,10 +607,10 @@ } } -みたいな感じ。でも、そうするとscope rule を変える必要があるので厳しい。 -ま、悪くはないけどね。 - -continuation を明示する方法もある。 +帥сscope rule 紊綽荀уウ +障 + +continuation 腓冴号 main() { @@ -622,17 +622,17 @@ goto *ret; } -かな? call/cc ? - -label へのgotoを許すのもいいけど、 -でも、label を許すと、すごくspaghettiにならない? +? call/cc ? + +label 吾goto荐宴 +сlabel 荐宴spaghetti? Tue Jan 4 11:47:24 JST 2000 -continuation じゃなくて、return keyword を使おう。 -(実際、continuation と少し違うし) -type が少し変になるけど、まあ良い。 +continuation return keyword 篏帥 +(絎continuation 絨) +type 絨紊障 int main() @@ -645,33 +645,33 @@ goto *ret(3); } -だな。prototype も付けないといけないか。 +prototype 篁 Tue Jan 4 12:21:44 JST 2000 -これだとmethodがすべてstatic になってしまう。dynamic なmethod -呼び出しにするには? dispatcher を自分で作ることになる。かなり -めんどくさいが... +method鴻static c障dynamic method +若喝冴? dispatcher т +... code method(obj,arg) { } -か、あるいは、inline にするか... #define のかわりに inline ねぇ。 -これはあとで考えて良い。 +inline ... #define inline +ц Tue Jan 4 14:22:19 JST 2000 -main の変数を書き潰すのと、goto (*reg)(123) での値は、 -register 渡しで、current register にのらないので、 -結局、return label は専用に作る必要がある。 +main 紊違吾羹違goto (*reg)(123) сゃ +register 羝<сcurrent register с +腟絮return label 絨篏綽荀 Tue Jan 4 18:14:07 JST 2000 -stack を継ぎ足して、呼び出す方式を取れば、call by value -のregister 渡しを制限する必要は無くなる。 - -複数の値を返すことも容易だ。 +stack 膓莇潟若喝冴劫違call by value +register 羝<狗綽荀< + +茲違ゃ菴絎号 .file "tmp.c" .version "01.01" @@ -692,7 +692,7 @@ .size code,_5-code .ident "Micro-C compiled" -おお?! +?! %esp new %esp = old %esp - 12 -4 %ebp-4 = g %esi = a @@ -703,16 +703,16 @@ %ebp+12 = e %ebp+16 = f -interface は付けよう! というか、 +interface 篁! goto name(struct {xxxx}) -みたいな感じで良いわけね。どれをregisterにいれるかと言う問題はあるが。 - -で、どうやってcallすればいいわけ? emit_pushするかわりにpush -する? - -うう、これでは、だめか。code argument の数が変わると、 -ebp をいちいち動かすことになる。そこにはold sp があるから -そいつもコピーする必要がある。 +帥цregister荐馹 + +сccall違? emit_pushpush +? + +сcode argument 違紊 +ebp <≦old sp +ゃ潟若綽荀 %esp new %esp = old %esp - 20 %ebp-20 = g @@ -724,7 +724,7 @@ %ebp-4 = f %ebp = old %esp 0 -そうか、function からcallする時には、local 変数を書き潰して良い。 +function calllocal 紊違吾羹違 # goto name(a,b,d,e,f); @@ -744,135 +744,135 @@ %ebp = %esp 0 %eip 4 <- arg_offset -となる。ということは、pushl %ebp は、間違い。 - -だけど、%ebp をそのまま使うのは良くない。disp_offset がかかっているから。 -だから、もう一度 pushl %ebp したほうがよい。しかし、push する先は、 -上の、(*)。 +pushl %ebp + +%ebp 障鞘戎disp_offset c +筝綺 pushl %ebp 祉push +筝(*) leave movl %ebp,%esp popl %ebp -じゃなかったか? +c? Thu Jan 6 13:00:33 JST 2000 -できたね。これでとりあえず動くはず。速度は問題だが... -あとは、 +сс綺馹... + ANSI-C prototype ANSI-C prototype check Interface Definietion GC support Direct handling of Frame -だね。簡単に出来そう? たぶん... +膂≦堺ャ? 吟... Fri Jan 7 09:42:53 JST 2000 -goto 文が動いてなかった。あと peep hole optimization version も -作るか? - -continuation として label を送れるようにするべきか? -そうすると便利なんだけど、ちょっと、汚いプログラムが -出来るようになる。あと、送り側の環境(frame)を維持する -必要がある。ま、できなくはないか... - -そうすると、label が値を持つようになる。 +goto c peep hole optimization version +篏? + +continuation label 鴻? +箴水<c羆違 +堺ャ眼医(frame)膓 +綽荀障с... + +label ゃゃ a = label:; -とか。うーん。label:(a,b,c) {}; みたいな形で、parallel 代入を許すと言う -手もあるね。 - -こちらの方がCとの相性は良いが... main() { label:(){ ... } } -みたいなnestを許すかどうかと言う問題がある。 -変数の参照を許さなければ、特に問題はない。 - -a = label: は、二重の意味があるなぁ。 - -言語の名前。DinnerBell II とか? join も入れる? +若label:(a,b,c) {}; 帥綵≪сparallel 篁eャ荐宴荐 + + +<鴻C御с... main() { label:(){ ... } } +帥nest荐宴荐馹 +紊違с荐宴違鴻馹 + +a = label: 篋潟 + +荐茯DinnerBell II ? join ャ? code entry_a().entry_b() {} -ですか? parallel call も? +с? parallel call ? Fri Jan 7 19:53:53 JST 2000 -いまのままだと return が環境を持ってないから、大域脱出できない。 -まぁ、環境を入れてもいいんだけど、どこに置くかと言う問題が -あるね。 - -そうじゃなくて、return 側で判断するか? +障障障 return 医c紊у怨冴с +障医ャ臀荐馹 + + +return 眼уゆ? return(ID) -みたいな形でIDで判断する。そうすれば、return 側でID -を見て判断できる。けど... - -まぁ、はやり、環境を持って歩く方がいいかなぁ。でも、 -引き渡しているから、二つ引き渡して、片方を使われたときに、 -反対側が消えてしまうのはいたいよね。今のままならば、 -そういうことは起こらない。 - -continuation 特有の問題を避けるなら、このままでもいいんだが... -continuation や環境は、このシステムでは自分で作ることが -できるからね。 - -そうなんだけど.... retlabel や retcont は実はオブジェクト -全体に一つあれば良い。 - -引数を渡すときに、そこに環境へのポインタをいれてやれば良いので、 -解決は割と簡単だが、そうすると、例の構造体を引数で渡すと言う -問題を解決する必要がある。 - -でも、今の実装ならば、まったく同じ変数の構成ならばコピーは -実際には起こらないわけだから問題ないはず。特に、それを保証するために、 -interface を実装する必要がある。 +帥綵≪IDуゆ違return 眼ID +荀ゆс... + +障医c罩鴻с +綣羝<篋ゅ羝<鴻篏帥 +絲上眼羔障篁障障違 +莎激 + +continuation 号馹帥障障с... +continuation 医激鴻ст +с + +.... retlabel retcont 絎吾с +篏筝ゃ域 + +綣違羝<医吾ゃ潟帥域с +茹f浦蚊膂≦箴罕篏綣違ф検荐 +馹茹f浦綽荀 + +с篁絎茖違障c紊違罕違潟若 +絎莎激馹鴻篆荐若 +interface 絎茖綽荀 return -> (void *)old bp return address -bp を直接操作できるようにするといいんだけど.... +bp 贋・篏с.... Sat Jan 8 08:49:59 JST 2000 -今は、code 内ではreturnできないわけだけど。実は、return って、 +篁code сreturnс絎return c code return0(i) int i; { return(i); } -か? 今は禁止してないから書けちゃうよね。どういうcodeが出るんだろう? - -doreturn() では retpending をセットしているだけだから、control=1 -のまま。で、code の終りにくるのでエラーになる。checkret は、 -statement の引数で判断するようにしたほうが合理的だろう。 - -大域脱出は結構根が深いよね。途中をスキップされてうれしいか? -destructor と同じで、途中のcodeは全部呼びたいのが普通だろう。 - -bp が同じになるまで return すれば良いわけだよね。 -return と同じで、明示的に環境を引き渡すようにするか。 -type は void * で良い? - -return する時にstackの上限を越えているかどうかを自分でチェックする -必要があるね。誰にreturnするかをcodeで明示すれば良いわけだけど。 +? 篁胼罩≪吾<code冴? + +doreturn() с retpending 祉control=1 +障障сcode 腟с若checkret +statement 綣違уゆ祉 + +紊у怨冴腟罕鴻羞宴筝鴻? +destructor с筝code若潟 + +bp 障 return 域 +return с腓榊医綣羝< +type void * ц? + +return stack筝莇сс +綽荀茯違returncodeф腓冴域 code return0(i) int i; { return(i); } -を許して、そこで、frame pointer を大域あるいは渡した引数と -比較して処理する? +荐宴сframe pointer 紊у羝<綣違 +罸莠? code return0(i,env) int i; env *env; { if (env==self) return(i); } -あれ? これはおかしいよね。 +? code return0(i,env) int i; env *env; { if (env!=self) { env->return(); return(i); } } -も、なんか変だよなぁ。呼び出しと逆順に帰りたいわけだが... -実際、逆順には帰っているわけだよね。 - -return の中でこそこそ比較するという技もあるけど。 - -問題は、destructor に渡す情報だよね。もちろん、self で良いわけだが、 -このあたりは、言語外の問題で、それを明示的にしたいから、この言語を -作っているわけなのだから、これを内部で処理するのはおかしい。 +紊若喝冴絽違... +絎絽違c + +return 筝с罸莠 + +馹destructor 羝<宴<self ц +荐茯紊馹с腓榊荐茯 +篏cу code return0(i) int i; { return(i); } -これだと、return の型が合わないと言う問題が生じるな。簡単には -チェックできない。 +return 荐馹膂≦ +сс int main() { code a() { @@ -881,7 +881,7 @@ return(i); } } -にすれば、check はできるようになる。でも、これだと、 +違check сс int main() { a: { @@ -890,149 +890,149 @@ return(i); } } -と差がない。module 化を言語外でやるというのが主旨なのだから、これでは -まずい。これは高級アセンブラなのだから。 - -あそうか、return と、大域脱出時のabortとは、状況が違う。だから、 -別なcode を呼び出さないとだめ。あるいは、値で区別するか。これは、 -logic programming のfail/success と似ている。 +綏module 荐茯紊с筝紙с +障蕭膣≪祉潟 + +return 紊у怨堺abort倶 +ャcode 若喝冴ゃу阪ャ +logic programming fail/success 篌若 main() { } abort { ... } -でもいいけど? +с? main() { code abort { ... }; code return { ... }} -かな? - -本来、subroutine call自体が、かなりの省略形なわけだから、これは -仕方がない。今のままで通常のsubroutine callをシミュレートできるのか? +? + +ャsubroutine call篏ュ就 +篁鴻篁障障ч絽吾subroutine call激ャ若с? code (struct arg {...},void *sp) { struct env; push(sp,arg); push(env,arg); } -できるけど、ちょっと重い。やはり、frame pointer を直接操作しないと -だめ。 - -goto 文のほうに、env を一緒に送るものを作ったほうがいいのかも。 +с<cframe pointer 贋・篏 + + +goto 祉env 筝膩篏c祉 goto (*ret)(),environment; -かな。type は? (void *)? +type ? (void *)? goto ret(),environment; -にはならないの? そうすれば、自分でthreadを制御できる。environment -の正当性を評価しなくて良いの? まぁ、ねぇ。 - -これは実装は容易だが... goto といちいち書くのが本当にいいのか? -env に対するoperationがあった方がいいなぁ。push とか? +? 違thread九勝сenvironment +罩eс荅箴<? 障 + +絎茖絎号... goto <≧吾綵? +env 絲障operationc鴻push ? code return0(i) int i; { return(i); } -を認めれば、return 擬変数はいらなくなる。 - -でも、実は、return は、caller の引数の数と一致してないといけない -わけだから、 code return0(i) int i; { return(i); } はだめ。env -と一致してないといけない。ということは分離するとまずいんじゃない? -あれ? そんなはずないな。 +茯違return 紊違 + +с絎return caller 綣違違筝眼 + code return0(i) int i; { return(i); } env +筝眼≪障? +? Sun Jan 9 01:15:56 JST 2000 -やはり、分離してはまずい。もともと、 +≪障 goto func(arg); -自体が、 +篏 goto func(arg) with current.env -みたいなものだ。つまり、これは、DinnerBell の、 +帥ゃ障DinnerBell self message: arg -と同じ。self->func(arg); でも良い。が、function callと区別が付かないのは -良くない。 - -そうすると、type code はsize int でなくなる。 +self->func(arg); сfunction call阪ャ篁 + + +type code size int с code *p = func; -ではいけなくて、 +с code p = {func,env}; -でないといけない。実際、 +с絎 goto func(arg) -では、current environment を pushl %ebp でstack = current env -に積んでいるわけだから。 - -いずれにせよ、 +сcurrent environment pushl %ebp stack = current env +腥с + + struct p = q; -は実装する必要がある。localな、 +絎茖綽荀local code p = {func,env}; -も動くはずだが... +... code (*p)(); goto (*p)(arg); -はだから少しおかしい。これは、goto がenv を補っていると考えるべき。 - -このようにすると、常に、 +絨goto env 茖c鴻 + +絽吾 func,env -の組をcodeとみなすことになる。これは、object と呼ぶべきだ。 -ただ、既存のobjectとは別だよな。actor の方が良い? - -うーん、これでjoinを入れれば、完璧なDinnerBellだな。並列送信はないけど。 +腟code帥object 若吟鴻 +√objectャactor 鴻? + +若joinャ違絎сDinnerBell筝篆< Sun Jan 9 01:40:05 JST 2000 -local 変数の初期化はallocation の後に遅らせる必要がある。 -nptr に入れられるはずだよね? nptr に初期化フラグを足すか? - -文途中で出現するlocal変数の初期化。ちゃんと動いているの? - -構造体のcopyは、lcheck を修正すべきでない。 +local 紊違allocation 緇綽荀 +nptr ャ? nptr 違莇潟? + +筝у榊憗local紊違<? + +罕篏copylcheck 篆罩c鴻с Sun Jan 9 08:49:43 JST 2000 -うーん、なんか修正が多いなぁ。あと、関数呼び出し、goto 文の -構造体への対応か。 +若篆罩c紊∽医若喝冴goto +罕篏吾絲上 goto (*code)(); -が、self env を使うのか、code の先の値を使うのかを区別する -必要がある。もし*を使わないとするとlabel(FNAME)との区別が -つかないぞ。あ、でも、環境を持ち歩くことにしたから、label -へもjumpしようと思えばできるね。 - -並列送信はなくても、この構成ならばstatement単位の並列性を検出するのは -容易だろう。 - -やればできるけど、この修正の量だと1日じゃ終らないかなぁ。 -不動小数点も入れるのでしょう? +self env 篏帥code ゃ篏帥阪ャ +綽荀*篏帥label(FNAME)阪ャ +ゃс医≧label +吾jump違с + +筝篆<罕statement篏筝с罎冴 +絎号 + +違с篆罩c1ャ腟 +筝絨亥鴻ャс? Mon Jan 10 09:00:12 JST 2000 -引数に構造体を許すには、必ずANSI-Cにする必要がある。難しくは -ないが... - -goto 文には label, code, continuation の3つが来る。 +綣違罕篏荐宴綽ANSI-C綽荀c +... + +goto label, code, continuation 3ゃャ continuation = code + env | label +env -なのだが、code/label では、env の内容が異なる。できれば面白いが、 -その価値はあるのか? - -しかし、code , env を分離するとあまりに危険すぎる。どうせgoto -が危険なんだからいいか? その方が簡単。簡単なら、そっちの方法を -とるべきじゃない? うーん。 - -return の関数依存性はなくした方が良い。 -一つにするのは、pop の問題があるので良くないが... - -そうか、ret をenvを指定して戻るようにしたから、leave する必要は -なくなった。そして、push %ebp に相当する部分は、lea -disp(%ebp),%sp -で消去されている。ということは、jump のfunction依存部分はいらない -ということだね。 - -でも、汚いなぁ。read only属性をhardware supportできればなあ。 - -sched_yeilds() 相当を書けるかな? lock は? - -一応、できたけど、やっぱり汚い。 +code/label сenv 絎鴻違с育∝純 +箴≦ゃ? + +code , env ≪障演冴goto +演冴? 鴻膂≦膂≦c<号 +鴻? 若 + +return ∽遺絖с鴻 +筝ゃpop 馹ц... + +ret env絎祉leave 綽荀 +cpush %ebp 後lea -disp(%ebp),%sp +фサjump function箴絖 + + +с羆read only絮сhardware supportс違 + +sched_yeilds() 後吾? lock ? + +筝綽сc宴羆 Wed Jan 12 16:12:27 JST 2000 -あは。ANSI prototype はめんどい。 +ANSI prototype bexpr() -で、関数での引数の順序と、そのあとの宣言の順序が変わることがある。 -そうすると、うしろの方が優先されてしまう。これは、こまる。 - -そうか、code_arg_offset のような方法だと、ANSI style では、 -困ってしまう。 +с∽違с綣違綺絎h綺紊 +鴻障障 + +code_arg_offset 号ANSI style с +違c障 Thu Jan 13 04:46:12 JST 2000 @@ -1058,34 +1058,34 @@ Thu Jan 13 13:38:24 JST 2000 -だいたいできたけど、test/tmp7.c のprintf のtype mismatch は -なんなんだろう? ASNI の副作用だろうなぁ。 - -これだと、プロセスの切替えのときには、結構な量のデータを -コピーすることになる。それでもいいんだけど... - -それごと、どっかにとって置く。continuationへの参照みたいなもの -ができないかな。 - -コピーができれば、environment/return の組は動くわけだから、 -それへの参照と切替えがあっても良いよね。 +сtest/tmp7.c printf type mismatch +? ASNI 篏 + +祉鴻帥腟罕若帥 +潟若с... + +cc臀continuation吾с帥 +с + +潟若с違environment/return 腟 +吾с帥c Fri Jan 14 12:03:35 JST 2000 -Libretto のkeyboardが壊れた... control key が効かない... - -printf の参照の問題は解決しました。list2 がlocalなheap -に割り当てているのがいけなかったね。 - -return の処理は、goto 文で処理するより、environment に -returnto する方が良くはないか? - -environment は実は送り先でそれなりの準備が必要。 -new-environment() みたいなlibrary があれば、thread にできる。 - -join は? - -funcall を用意すると良いね。 +Libretto keyboard紕... control key 鴻... + +printf с馹茹f浦障list2 localheap +蚊綵c + +return goto уenvironment +returnto 鴻? + +environment 絎с羣綽荀 +new-environment() 帥library 違thread с + +join ? + +funcall Mon Jan 17 15:23:34 JST 2000 @@ -1093,8 +1093,8 @@ return bb; } -みたいなのは? 関数の型か代入の型を見て、crn にpointerを渡して、 -あとでcopyしてから stack を畳む。 +帥? ∽違篁eャ荀crn pointer羝< +copy stack 潟 # bb=f1(aaa); movl $bb,%eax @@ -1107,21 +1107,21 @@ addl $400,%esp # return a1; -あ、でも、それだと、local変数を返したときに困るね。leave; ret; -してはいけなくて... - -あ、やっぱり、こういう場合はコピー先をmain2に引き渡しているみたいね。 +сlocal紊違菴違leave; ret; +... + +c宴翫潟弱main2綣羝<帥 void f1(struct aa *ret) { *ret = bb ; return; } -と同じか。これは簡単。 +膂≦ f1().a[55] -みたいな場合は、局所変数に強制的に取ってしまうみたいね。それはそうだ... -が、うちの実装だとちょっと厳しいか。 +帥翫絮紊違綣桁句c障帥... +<絎茖<cウ leal $-sizeof(struct),%esp pushl %esp -なんだけど、関数呼び出しの途中ではできないから.... +∽医若喝冴筝сс.... # main(ac,av) # int ac; @@ -1144,28 +1144,28 @@ # j = 3; subl $20,%esp -このsublを後から指定してやればOk。 - -でも、それだと jump の時にずれない? ずれるか? ずれるね。うーん。 -実行時にチェックしてやるのも変だし。 - -まぁ、それほど必要な機能ではないんだけど。 - -これもcontinuationを渡してやると言う手法が使えないことはないんだが... - -関数呼び出しの最初にやってやればいいか。それでできるかな? +subl緇絎Ok + +с jump ? ? 若 +絎茵с紊 + +障祉綽荀罘純с + +continuation羝<荐羈篏帥... + +∽医若喝冴c違сс? Sun Feb 20 23:59:16 JST 2000 -MIPS のcall frame +MIPS call frame $sp = $fp local variables saved register (including $31 = return address) -mask は使用したレジスタのbit pattern - -4 は何? +mask 篏睡吾鴻帥bit pattern + -4 篏? 18 .mask 0xc0000000,-4 19 .fmask 0x00000000,0 @@ -1191,88 +1191,88 @@ 38 0044 3000BD27 j $31 39 .end main -これと同じようにするならば、regiterの使用数を最初に調べる必要が -あるのだけど、one path compiler である micro-C では、それは -できない。したがって、enter は後ろでする方が良い。 +違regiter篏睡違茯帥鴻綽荀 +one path compiler с micro-C с +сcenter 緇с鴻 Mon Jan 20 18:25:27 JST 2003 -3年間さわってないのかよ。何やってんだ? - -goto 文のバグをとらないといけない。 - -まず、関数引数の構造体の展開。これは、どうってことないはず。 +3綛顔c篏c? + +goto 違 + +障∽医違罕篏絮c goto (*code)(i+1,j,...) -まず、いじらなくてすむ変数を摘出する。 +障紊違冴 foreach arg compare -単純演算 ( op+const , pointer , const assign ) などは、ここで検出する。 -大半は、そのようになるはず。 -レジスタに乗せる分があるから... それには触らないとして... - -複雑なものは、前もって計算しておく。(get_register する) -スタック上かレジスタ上に作る。 - -残りは並列代入となる。再帰的に計算する。 - -えーと、大きな順にやるんだっけ? 小さな順にやるんだっけ? +膣羲膊 ( op+const , pointer , const assign ) ф冴 +紊у +吾鴻帥箙... 茹... + +茲c荐膊(get_register ) +鴻帥筝吾鴻推篏 + +罧筝篁eャ絽亥荐膊 + +若紊сc? 絨c? code f( int a, int b, int c ) { goto g(b,c,a); } -みたいなやつだよね。 - - 移動するものを一つ検出する。 - そのために移動が必要なものを移動しておく(再帰) - 代入する - -こんなんでいいのか? ループしない? するよね。ループしたら -get_register する。 - -前の例だと、 - - g(b,c,a) のbに着目する。 - bに代入するコードを出すと、a が壊れる。 - a が必要かどうかを調べる。それは、引数のリストを見ればわかる。 - その前に、a を移動する。a の移動先を見て、 - 空いていれば、移動してOk。しかし、c - なので、 c を見る。と b になるので、ループするのがわかるので、 - b を get_register する。 - で、c が移動できる。で、aを移動して、とっておいたbを代入。 +帥ゃ + + 腱糸筝ゆ冴 + 腱糸綽荀腱糸(絽) + 篁eャ + +с? 若? 若 +get_register + +箴 + + g(b,c,a) b + b篁eャ潟若冴a 紕 + a 綽荀茯帥鴻綣違鴻荀違 + a 腱糸a 腱糸荀 + 腥冴違腱糸Okc + с c 荀 b с若с + b get_register + сc 腱糸ссa腱糸cb篁eャ Tue Jan 21 22:45:09 JST 2003 -とりあえず、jump は複雑すぎる。もっと簡単にすることを考える。 -parser 側である程度処理できない? +jump 茲c膂≦ +parser 眼с腮綺с? goto f(a+3,b(),c); -などを、 + a = a+3; b = b(); goto f(a,b,c); -程度に簡略化する。この時、f(a,b,c) は(できるだけ)、元の -関数の引数リストに近付ける。のは無理なので、単純変数 -まで落す。 - -あまり関係ないか。一時変数はどうせいるわけだし。ってこと -みたいね。 - -だとすると、元のコードと、そう変わらんね。前のも、そんなに -悪くないってことか。 +腮綺膂∞ュf(a,b,c) (с) +∽違綣違鴻菴篁∞с膣紊 +障ц純 + +障≫筝紊違c +帥 + +潟若紊 +c Wed Jan 22 14:33:12 JST 2003 -やっぱり、途中で局所変数を増やしたいよね。 +c宴筝у紊違紜 Fri Jan 31 20:30:36 JST 2003 -なんか #ifdef / #if がないとだめだな。実装する? -しました。 + #ifdef / #if 絎茖? +障 Tue Feb 4 01:04:12 JST 2003 @@ -1284,89 +1284,89 @@ addl %ecx,%edx movl (%edx),%edx pushl %edx - xchg %edx,%eax .... edx に$10が入る (なんでxchg?) + xchg %edx,%eax .... edx $10ャ (xchg?) call getc addl $4,%esp - movl %eax,-20(%ebp) c に代入 + movl %eax,-20(%ebp) c 篁e movl $chptr,%ecx pushl %ecx popl %ebx - movl (%ebx),%ecx ecx にchptrの中身 + movl (%ebx),%ecx ecx chptr筝荳 addl $1,(%ebx) movb %al,(%ecx) subl %edx,%eax eax-edx ($10) je _1119 -が壊れる理由なんだけど... - -edx,ecx が破壊されちゃうみたいね。 +紕宴... + +edx,ecx 翫<帥 Tue Feb 4 12:17:07 JST 2003 -ようやっと直したよ... - -use_pointer って、なにもしなくていいんだよね? eax,ebx を避ける -ってことらしいけど。 - -inline/引数付き #define 欲しくない? 置き換えは、local name stack に積んじゃう。 -展開は function で行う。 - -getch を工夫する必要はあるが。置き換えスタックが必要。 +c眼... + +use_pointer c? eax,ebx 帥 +c + +inline/綣遺 #define 罨蚊? 臀local name stack 腥 +絮 function ц + +getch 綏ュか綽荀臀鴻帥綽荀 Wed Feb 5 01:16:00 JST 2003 -大域で定義された struct field が大域変数と重なっていると落ちる。 -そりゃそうだけど。どうするの? (直した記憶があるんだけどなぁ...) -struct 毎に field 名とoffset/type の組を持てばい良いんだよね。 - -なんだけど、タグ無しの構造体もあるから、型名の方に付ける必要 -もある。というのは、型名のない構造体もあるから。タグ名には、 -一応、リストがついている。なんかに使う必要があったんでしょう -ね。あ、めんどう。無条件にやっても大域変数名を汚すのを直すの -が難しい。 - -ちょっと、あれだけど、「型名.フィールド名」で登録してしまうのはどう? -型名が後で出て来るところが気まずいが... - -def で登録するときに、nptrにdispを代入せずに、struct field list -(大域変数) に入れて、type の方に、field list (list3(nptr,offset, -type)) を入れれば良い。 - -あとは、strop の方でtypeのlistを見るようにすれば良いわけだ。 - -これなら、簡単に直せるはず。LUSTR/GUSTRなどの区別もなくなるし。 +紊уу臂 struct field 紊у紊違c純< +? (眼荐吟...) +struct 罸 field offset/type 腟違 + +帥亥<罕篏鴻篁綽荀 +罕篏帥医 +筝綽鴻ゃ篏帥綽荀cс +≧>散c紊у紊医羆眼 +c + +<c.c若х脂蚊障? +緇у冴ャ羂障... + +def х脂蚊nptrdisp篁eャstruct field list +(紊у紊) ャtype 鴻field list (list3(nptr,offset, +type)) ャ域 + +strop 鴻typelist荀域 + +膂≦眼LUSTR/GUSTR阪ャ Wed Feb 5 02:10:14 JST 2003 -浮動小数点ねぇ。完全なANSI Cにするのは大変。でも、 -浮動小数点ぐらいないと。 - -code generation part を、さらに分割して、 -複数のコード対応にしやすいようにする。 -おそらく、それほど共有する部分はないけどね。 - -Sample C code をコンパイルして、その結果から(半分手動で) -Micro CbC code generation part を生成する方法を用意する。 +羌絨亥鴻絎ANSI C紊ус +羌絨亥鴻 + +code generation part 蚊 +茲違潟若絲上 +祉掩 + +Sample C code 潟潟ゃ腟() +Micro CbC code generation part 号 Thu Feb 6 11:47:03 JST 2003 -Code Segment を単位として使うときに、大域変数はどういう -ように分けるの? static なんかは意味ないよね。 - -もちろん、自然にグループ分けされるわけだけど。 - -あとデータフローだよね。データフローに関しては、 -あんまりやってないなぁ +Code Segment 篏篏帥紊у紊違 +? static 潟 + +<吟違若 + +若帥若若帥若≪ +障c Fri Feb 7 14:36:15 JST 2003 -inline では、必らず、局所変数の増加がある。また、inline -は普通の関数として展開しておく必要もあるらしい。(何故?) - -#define ねぇ。 +inline с綽絮紊違紜障inline +∽違絮鏆荀(篏?) + +#define #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+1,b+1); @@ -1377,41 +1377,41 @@ c(a,b); } -local #define がいるんだよね。g の中で a が出て来た時には、 -c のa の置き換えは起こってはいけない。ということは、c -の置き換えはg が始まる前に終っている必要がある。dynamic -scope なんだから、assoc の上乗せで良いはず。 -macro のlevelを定義して、あるレベルでは、それ以前の展開 -を行わないという手法が良いかな。 +local #define g 筝 a 冴ャ +c a 臀莎激cc +臀g 紮障腟c綽荀dynamic +scope assoc 筝箙ц +macro level絎臂с篁ュ絮 +茵羈 c(a,b) => a=>"a+1", b=>"b+1" g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") -みたいな感じ? - -やっぱり関数解析でマクロ処理をやらせるのは無理かな? 先読みされちゃうし。 +帥? + +c宴∽域Вс∞? 茯帥< Sat Feb 8 00:53:52 JST 2003 -macro は途中まで書きました。置き換えをマクロが呼び出された -時点で cheap に置くと、それを解消するタイミングがない。 -ここだけmallocしても良いが.. - -chptrsave はlistにする必要がある。list で良い。 - -やっぱりmacro levelを見て、自分と一致したassoc valueまで -手繰って置換するんでしょう。そうすれば、置き換える必要は無い。 -ということは、local_define にmflagsを格納する必要がある。 +macro 筝障ф吾障臀若喝冴 +鴻 cheap 臀茹f帥ゃ潟違 +malloc.. + +chptrsave list綽荀list ц + +c宴macro level荀筝眼assoc value障 +膵違c臀с違臀綽荀< +local_define mflags主綽荀 c(a,b) => a=>"a", b=>"b" a=>"a" .. mflag == 1 g(a,b) => (a=>"a+1+1",a=>"a+1"), (b=>"b+1+1",a=>"a+1") a=>"a+1" .. mflag == 2 -macro のもとのnptr が残ってないと、オリジナルを返せない。オ -リジナルは、sc などが破壊されてしまう。ってことは、local macro -は、local table を汚してはいけないってことだよね。ってことは、 -macro table は、もとのとは別に用意する必要がある。 +macro nptr 罧c吾菴 +吾sc 翫障clocal macro +local table 羆cc +macro table ャ綽荀 #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+2,b+2); @@ -1431,7 +1431,7 @@ #endif } -うーむ。ややこしい。 +若 main() c(a,b) mflag++ @@ -1439,11 +1439,11 @@ g(a,b) mflag++; a=>"a+1" mflag ==2 ^ is replaced by c's "a" not g's a; -いったん mflag level n で展開したら、それは mflag level n-1 となる。 +c mflag level n у mflag level n-1 Sat Feb 8 18:13:43 JST 2003 -いちおう、mflag まではデバッグしたが.... mflag を戻してないんじゃないの? +<mflag 障с違.... mflag 祉? ---c(a,b)----------------------- mflag ==1 a=>hoge, b=>hoga (mflag==1) @@ -1452,22 +1452,22 @@ ----printf(a,b)---------- mflag ==3 a=>poge, b=>poga(mflag==3) -g が呼び出されると、ac,bc は mflag==1 でのみ置換される。 - -あるテキストを置き換えると、それは置き換えたマクロのmflag level -(つまり一つ少ないレベル)になる。 -置き換え終ったら、元のlevelに戻す。 - -mflag==2のlevel では、mflag==2のlocal macroの展開しかしない。 - -置き換えると、mflag level 1 になるので、そこで mflag==1 のlocal -macro を展開する。mflag==0 は常に展開を行う。 +g 若喝冴ac,bc mflag==1 с睡舟 + +鴻臀臀mflag level +(ゃ障筝ゅ) +臀腟clevel祉 + +mflag==2level сmflag==2local macro絮 + +臀mflag level 1 с mflag==1 local +macro 絮mflag==0 絽吾絮茵 Sun Feb 9 11:35:23 JST 2003 -うーん、なんかtypeが、list とCHARなどと入混じっているじゃん。 +若typelist CHARユ祁c int save = chptrsave; -で、chptrsave が、$chptrsave になってしまう。 +сchptrsave $chptrsave c障 Sun Feb 9 22:33:36 JST 2003 @@ -1476,64 +1476,64 @@ #define cadr(e) (heap[((int)(e))+1]) car(cadr(e)) -だろ。 + car -> #define e cadr(e) (mleve=1) cadr -> #define e e (mleve=2) -むぅ。これ、うまくいかないんじゃん。こまったなぁ。 +障障c #define c(a,b) g(a+1,b+1) #define g(a,b) printf("%d %d\n",a+1,b+1); c(a, b); -こっちもだめじゃん。ふーむ。lisp interpreter のように -作ればいいはずなんだけど。 +c<泣若lisp interpreter +篏違 Mon Feb 10 08:10:25 JST 2003 -結局、list base のinterpreter を実装しました。きちゃないが。 -前の方法でも、頑張ればできるんでしょうけどね。 +腟絮list base interpreter 絎茖障< +号с綣泣違сс Tue Feb 11 13:50:03 JST 2003 -struct copy だけど... 関数がstructを返すときに、引数に前もって -積んでおくのでは、そこに値がコピーされてしまうし、あとで、 -スタックをたたんで置くときにきまずい。 - -function call の時に、引数の型のチェックをしてない - -type に -1 とheapの引数が混在しているやつだけど.. -やっぱまずいんじゃないか? - -temporal struct は再利用できるんだけど、dispの変更ができないので -新しく作るしかない。大きいときだけ新しく作るなんていうセコイ -技はあるけど。(そうすると、帰って来た値へのポインタを使えなく -なるが.... 別にいいよね。戻り値それ自身を直接 return する -時もだいじょうぶなはず) - -結局、呼出側で、領域を確保して引き渡すことにしました。この方法だと、 -代入のときに二度コピーする必要もない。 - -register を使用しているかだけじゃなくて、実際にcreg/dregに -値があるかどうかを記憶する必要がある。 +struct copy ... ∽違struct菴綣違c +腥ссゃ潟若障с +鴻帥х舟障 + +function call 綣違с + +type -1 heap綣違羞桁ゃ.. +c宴障? + +temporal struct сdisp紊眼с +違鋎紊с違鋎祉潟 +(絽違cャゃ吾ゃ潟帥篏帥 +.... ャ祉ゃ荳贋・ return +吟) + +腟絮弱阪眼с腆坂綣羝<障号 +篁eャ篋綺潟若綽荀 + +register 篏睡絎creg/dreg +ゃ荐吟綽荀 Wed Feb 12 11:09:22 JST 2003 -それだけどさ... やっぱりアドホックに実現するのは難しいんじゃないの? - -まぁねぇ。register の場所の確保と、寿命は別だから、それで -いいんだけど、regs flag だけでなんとかならないのかな。 -こういう変更ははまるが虚しい。 +... c宴≪絎憗c? + +障register 贋腆坂絲水純ャ +regs flag с +紊眼障 Thu Feb 13 18:37:36 JST 2003 -さて、そろそろ jump にとりかかりますか。 - -構造体の引き渡しのシークエンスに使う局所変数の位置がgccと違う... - -そろそろ register は構造体にすべきだね。 + jump 障 + +罕篏綣羝<激若潟鴻篏帥絮紊違篏臀gcc... + + register 罕篏鴻 struct register { int used; int valued; @@ -1543,61 +1543,61 @@ int type; /* register variable or not */ int number; } -virtual/real は、どうする。 +virtual/real Sat Feb 15 14:00:03 JST 2003 -fdecl_struct を構文的に引数が出現するときに行うと、int *f(int -a) などで、* の評価が終る前に、int aが評価されしまう。*obj -のobj を評価し終らないとfのタイプが確定しない。int*f()[] み -たいな場合があるから。(?) なので、gcc と、そろえるためには、 -arg の先頭で fdecl_struct を行う方法ではだめで、fdecl 中であ -とから修正する方が良い。 - -fix しようにも引数リストなんて、存在しないじゃん! - -varargs を実装するのはめんどくさかろう... - -rvalue(expr(),type) では、expr() のtypeをrvalueに引き渡せな -い。でも、type を大域変数にすると、rvalueを異なるタイプで呼 -び出すときにtypeを変更する必要がある。このrvalueのtype の扱 -いは、かなりはまったことがあるので、rvalue(int e,int type)の -方が良いことは確かなんだが... - -struct_push のregisterの扱いが複雑すぎ。なんか、もっと -簡単にならないの? +fdecl_struct 罕綣違榊憗茵int *f(int +a) с* 荅箴<腟int a荅箴<障*obj +obj 荅箴<腟f帥ゃ腆阪int*f()[] +翫(?) сgcc +arg fdecl_struct 茵号ссfdecl 筝с +篆罩c鴻 + +fix 綣違鴻絖! + +varargs 絎茖... + +rvalue(expr(),type) сexpr() typervalue綣羝< +сtype 紊у紊違rvalue違帥ゃу +喝冴type紊眼綽荀rvaluetype +障cсrvalue(int e,int type) +鴻腆冴... + +struct_push register宴茲c +膂≦? Sun Feb 16 07:58:23 JST 2003 -代入しなくて良いからと言って、ソース -のリストから除いては、上書きを防げない。 +篁eャ荐c純若 +鴻ゃ筝吾蚊 Sun Feb 16 22:55:58 JST 2003 -vdisp ってなんだったんだ? +vdisp cc? Mon Feb 17 12:35:39 JST 2003 -並列代入は出来たみたい。代入は小さいものを先にすべきなのか? -まぁ、できりゃいいんだけど、横に避けるものが大きいのはいや -だよね。 +筝篁eャ堺ャ帥篁eャ絨鴻? +障с罔帥紊с + Tue Feb 18 11:56:10 JST 2003 -overlapped 用の emit_copy +overlapped emit_copy float/double long long Tue Feb 18 19:34:31 JST 2003 -code argument の符号を反転させると、list2(LVAR,offset) -のoffsetがアドレスの方向と一致しているという前提が -崩れる。それで、構造体の格納順序がずれてしまう... - -ということは... def(n) でcodeの時はargumentは、局所変数と同じ -扱いでマイナス符号で処理した方が良い。 - -できたみたい。でもさ、 +code argument 膃垩荵≪list2(LVAR,offset) +offset≪鴻劫筝眼 +經с罕篏主綺障... + +... def(n) codeargument絮紊違 +宴сゃ合垩у鴻 + +с帥с int main( int ac, char *av[]) { @@ -1605,46 +1605,46 @@ goto arg1(0,1,2,3,4,return,environment); } -って、きっと return 文がないと、文句を -言われるよね。むむむ。 - -post processing する時にoverlapしてないという保証がない。 +cc return ャ +荐 + +post processing overlap篆荐若 Wed Feb 19 15:38:55 JST 2003 -自分自身とのoverlapを見てないので、 +荳overlap荀с struct a a,int i int i,struct a a -みたいな時に自分自身を壊してしまう。なので、emit_copy -が、ちゃんと方向を見て壊さないように処理する必要がある。 - -call bcopy でいいじゃん。まね。 +帥荳紕障сemit_copy +<劫荀紕綽荀 + +call bcopy с障 Wed Feb 19 20:42:07 JST 2003 -楊さんの C2CbC と CbC2C を、micro C に取り込む。各所に、 -conv->func(); を埋め込む。conv は、構造体。 +罐 C2CbC CbC2C micro C 莨若 +conv->func(); 莨若conv 罕篏 conv: original c2cbc cbc2c -とする。なるほど。 +祉 Thu May 6 08:32:05 JST 2004 -やっぱり library も自分で作らないとね。そうすれば、 -CbC only で作れるから。 - -conv は、あんまり良いアイデアではないみたい。取るか。。。 +c宴 library т違 +CbC only т + +conv 障≪ゃ≪с帥 Thu May 13 12:59:16 JST 2004 -byte code interpreter を CbC 自身で書いたら? - -それでもやっぱり動かないから、あんまり意味はないんだけど... - -C で書いてもいいか。 +byte code interpreter CbC 荳ф吾? + +сc宴障潟... + +C ф吾 Wed Dec 22 15:17:49 JST 2004 @@ -1652,28 +1652,28 @@ shift; } -ねぇ。 なんで、return 構文にしたのか。しかも別々にしたのか。 + сreturn 罕ャ goto ret(value),env; -まぁ、ねぇ。 +障 try { .... goto event .... } catch (event) { } -をいれてもいいんだけど。 - -うーむ、いまいちだな。 - -inline function のreturn,env を実装するっていう技もあるけど。 - -やっぱり。setjmp = return みたいにする? それはそれで、 -やさしいんだけど.... + + +若障< + +inline function return,env 絎茖c + +c宴setjmp = return 帥? с +.... Fri Jan 6 20:26:24 JST 2006 -environment = interface frame の切替えを用意しないとね。 +environment = interface frame 帥 Mon Jan 30 21:53:11 JST 2006 @@ -1719,20 +1719,20 @@ goto f(a,...); } -syntax が汚い... type の指定はなんとかしないとだめだね。 +syntax 羆... type 絎 ... int a, -ずれたときのコストがなぁ。良く見えないんだよね。 - -可能だとは思うんだけど。 +潟鴻頳 + +純 __meta goto { } -みたいな感じ? +帥? Sun Nov 26 21:14:57 JST 2006 @@ -1740,7 +1740,7 @@ v----> argument local <--|-----v caller_arg -ではなくて、 +с | previous $fp |<-intr_size---><--------r1_offset----------->| @@ -1748,16 +1748,16 @@ v<--- interface-+---- local ----->|<--------->v <0 >0 caller_arg -なら、いいんじゃない? caller_arg は sp 相対で積めば良い。 -local 変数は max_caller_arg が不定なので sp 相対では積めない。 - -これだと、frame pointer がgoto で可変になる。interface がarugment -扱いになるので、限りなくsubroutine call に近くなるけど。 -(まぁ、そうだよな、そういう狙いだし...) - -だったら、完全にfunction callに合わせることも可能なんじゃないか? -可変長引数の場合とまったく同じになる。gcc の(予定ししてる実装と同じ) -これだと、C-- の paraterized goto と、まったく同じになる。 +? caller_arg sp 後障х域 +local 紊違 max_caller_arg 筝絎 sp 後障с腥 + +frame pointer goto у紊interface arugment +宴сsubroutine call 菴 +(障...) + +c絎function call純? +紊桁違翫障cgcc (篋絎絎茖) +C-- paraterized goto 障c | previous $fp |<-intr_size---><-------------r1_offset------------>| @@ -1768,30 +1768,30 @@ v<--- interface----+-------|--- local ----->|<-------->v <0 >0 xxx caller_arg -caller_arg はsp上に積むと。そうすれば、alloca も問題ない。 - -これを採用しなかったのは、たぶん、fp を移動しなければならな -いのを嫌ったんだろうな。今は、parse tree 作ってから、code -生成も可能なので、そうしても良いんだが。 - -でも、めんどくさいよ。めんどくさい。めんどくさいです。 -でも、やるしかない。 - -これを、やれば、C からの変換もかなりやさしくなるかも知れない。 +caller_arg sp筝腥違alloca 馹 + +。c吟fp 腱糸違 +絆c篁parse tree 篏ccode +純с + +сс +с + +違C 紊ャ Sun Nov 26 19:41:38 JST 2006 -max interface みたいなのが必要で、そうすれば、local 変数との -相互作用は避けられる。逆に言えば、利用は出来ない。 - -でも、max_interface は1 path では決まらない。だから、long offset -の時は、ちょっとはまる。特にARMの場合。やっぱり、max_interface -は決め打ちがいいのかな? そうすると、function call から呼ぶ -ときにはまるが... - -offset を 0 側からにすれば、max_interface はfp設定時のみに -なるが、そうすると、interface を変更したときのcopyが発生しやすく -なる。いや、そんなことはないのかな? +max interface 帥綽荀с違local 紊違 +娯篏帥荐違堺ャ + +сmax_interface 1 path с羆冴障long offset +<c障鴻ARM翫c宴max_interface +羆冴<? function call 若 +障... + +offset 0 眼違max_interface fp荐絎帥 +interface 紊眼copy榊 +? __code f(int a,int b) { goto g(int c,int b,int a); @@ -1804,10 +1804,10 @@ v<--- interface-+-------|--- local ----->|<-------->v goto g a,b,c -みたいな感じですか? 後ろをそろえるわけね。その方が自然か。 - -これだと、やっぱり、max_interface が問題になる。やっぱり、それで、 -fp を下にしてあるんだろうな。 +帥с? 緇鴻吟 + +c宴max_interface 馹c宴с +fp 筝 __code f(int a,int b) { goto g(int c,__code *f,int a,int b); @@ -1831,10 +1831,10 @@ v<--- interface---------|--- local ----->|<-------->v goto n a,b -えーと、goto n(...); で、どうやってfp を元に戻すの? ... の位置で、 -前の fp を覚えておけば良い。(*) - -これだと、function call を、そのまま実現できそうだけど? みたいだね。 +若goto n(...); сcfp 祉? ... 篏臀с + fp 荀域(*) + +function call 障上憗с? 帥 __code f(int a,int b,...) { goto g(int c,f,int a,int b,...); @@ -1844,13 +1844,13 @@ goto n(int d,int e,int g,...); } -とかすると、無限にstackが延びる。ふーん。 +♂stack綮吟潟泣若 __code g(int c,__code *n(...),...) { goto n(int d,int e); } -は、どうする? fp は、そのままなんだろうね。 +? fp 障障 |<----------------------------r1_offset------------>| |frame pointer | stack pointer @@ -1866,8 +1866,8 @@ v<-interface-+----|-- local --->|<---------v g d,e -で、fp は上書きか。それは、良くない。なので、fp の分ずらす。 -というよりは、fp の次を指すようにするのが良いのか。 +сfp 筝吾сfp +fp 罨< __code f(int a,int b,...) { goto g(int c,__code *f,int a,int b,...); @@ -1892,63 +1892,63 @@ v---- interface-+----------|-- local --->|<---------v goto n a,b -というわけか。frame pointer のオプションがあった方が良いわけだね。 - -これだと、全体の変更も少なくて済みそうだ。(ほんとうか?) - -g の ... の位置を前もって知ることが必須。かなりコードが繁雑に -なるけど。 +frame pointer 激с潟c鴻 + +篏紊眼絨羝帥(祉?) + +g ... 篏臀cャ綽潟若膵 + __code g(int c,__code n,...) { -の方が良いが、それだと、型のチェックが出来ない。実際には、 -かなり繁雑な型を書く羽目になる。typedef すればいいんだけどね。 - -__code は暗黙のtypedef にする? - - -これを許すとmax_interfaceの制限は現実的ではない? でもないか... -そのcodeでアクセス限界だからね。だったら、max_interface を -作って、(1024程度?) いや、やっぱり fp は動かさないとだめ -なので、良くない。 - -fp を積む場合と、戻す場合との区別は? 結構微妙か。 - goto 側の定義 ...が先に(か同時に)来たら戻す - goto 側の定義 ...が実引数より後に来たら積む -で、いいわけね? - -ちょっと、Semantics が複雑になりすぎる。可能なんだけど。 -environment での goto でたまにリセットしないとおかしくなりそう。 -Stack 増えている場合は、Warning ぐらいだした方がいいかも。 -大域的に見ないとわからない。有限かどうかも。 - -全部、tail recursive call でやるのと、あまり変わらないかな。 -そうすると、c-- のparametarized goto と差がないかも。 - - -あ、そうか。 +鴻с堺ャ絎 +膵吾靸順typedef 違 + +__code 藥typedef ? + + +荐宴max_interface狗憜с? с... +codeс≪祉拷cmax_interface +篏c(1024腮綺?) c宴 fp +с + +fp 腥翫祉翫阪ャ? 腟罕緇絋 + goto 眼絎臂 ...()ャ祉 + goto 眼絎臂 ...絎綣違緇ャ腥 +с? + +<cSemantics 茲純 +environment с goto с障祉 +Stack 紜翫Warning 鴻 +紊у荀 + +tail recursive call с障紊 +c-- parametarized goto 綏 + + + __code g(int c,__code *n(int a,int b,...),...) { goto n(int d,int e,int g,...); } -の n は、自動的に定義された方が便利だろう。 + n 絎臂鴻箴水 __code g(int c,...) { goto __cotinuation(int d,int e,int g,...); } -みたいな感じ。 +帥 go g(int c,int b,...) to hoge(...); -ですか? それは、だめか... だめでもないんだけど、型の設定が -難しすぎる。 - -K&R style の宣言の方が綺麗なのか... +с? ... с荐絎 +c + +K&R style 絎h鴻膓咲... Sun Nov 26 21:53:05 JST 2006 -(*) interface の大きさの増減は、自分のinterface を見れば -わかるはずだよね? だから、fp のsaveは必要ないはずだが... +(*) interface 紊с紜羝interface 荀 +? fp save綽荀... __code f(int a,int b,...) { goto g(int c,__code *f,int a,int b,...); @@ -1958,89 +1958,89 @@ goto n(...); } -確かにわかるんだけど、宣言を間違えたときに、おじゃんになる。 -どうせ、だめではあるんだが。引数の型は一段階までしか、 -チェックしないので、だめだね。 - - -このあたり、理論的な問題があるみたいだな。 - - stack を含めた有限な型付け - と、その表現 - -って問題があるわけね? - -そうか、parallel assignment では、同じ部分を前もって探した -方が効率がよいわけか。(どうせ、やっていることだが) +腆冴絎h +с綣違筝罧級障с +сс + + +茫馹帥 + + stack 篁 + 茵 + +c馹? + +parallel assignment сc「 +鴻合(c) Sun Nov 26 23:22:12 JST 2006 -fp のsave は必要。何故かと言うと、 +fp save 綽荀篏荐 goto f(a,b,...) -で、後ろの部分がどれだけあるかは、間接的な引数での -宣言ではわからないから。 - -stack 上に全部 interface があるなら、良いが、 -部分は register に乗っている。 +с緇・綣違с +絎hс + +stack 筝 interface + register 箙c goto f(a,b,c,...) -としたときに、... の一部はregisterに乗っている。どれだけ -乗っているのかを知る必要があるが、それをfpから推察する -ことはできない。浮動小数点とかの異なる型が散在している -から。 - -... で引き渡す引数は、メモリに乗っている必要がある。 -型が明解なら、レジスタ上でもだいじょぶなはずだが。 - -明示的な引数に大域的には変換できるはずだけど、open -な環境では、それはできない。 - -だとすれば、 +... 筝register箙c +箙cャ綽荀fpィ絲 +с羌絨亥鴻違e + + +... у羝<綣違<≪箙c綽荀 +茹c吾鴻推с吟 + +腓榊綣違紊у紊сopen +医сс + +違 __code f(int a, int b : int h, ...) { ... goto g(a,b,c : d,e,f,...) } -みたいな形で、stack 上に乗せる引数を明示する必要がある。 - -これは、なんなの? - - : の前の引数は可変に出来ない - : の後までは可変に出来る - -っていうことか。 - -構造体は、メモリ上に取るとしても.. - -まぁ、... のところまでレジスタで、それ以降は、メモリでも -十分だけどね。いずれにせよ、複雑すぎることは確か。 +帥綵≪сstack 筝箙綣違腓冴綽荀 + +? + + : 綣違紊堺ャ + : 緇障с紊堺ャ + +c + +罕篏<≪筝.. + +障... 障с吾鴻帥с篁ラ<≪с +茲腆冴 __code g(int c,__code (*n)(int a,int b,int d,...),...) { goto n(int d,int e,int c,...); } -で、この... は、すべて、同じものに置き換わるはず。 ... が -入る場合もあるが。 - -受け側が +с... 鴻臀 ... +ャ翫 + +眼 __code c(int d,int e,int c,int k,int j) {} -で定義されているときに、k,j がレジスタに乗っているかも知れず、 -乗っていたらダメダメ。なので、可変になる部分を明示する必要がある。 +у臂k,j 吾鴻帥箙cャ +箙c<<с紊腓冴綽荀 Mon Nov 27 11:17:39 JST 2006 -結局、このn の定義と、実際のn の定義がずれることが問題なんだよね。 +腟絮n 絎臂絎n 絎臂馹 __code c(int d,int e,int c,...) {} -で、受けることもあれば、 +с違 __code c(int d,int e,int c,int k,int j) {} -で受けることもある。あるいは、 +у __code c(int d,int e,int c,int k,int j,...) {} -とかも。 - -implements というか、accetps というか、そんな形の別な -宣言がいいのかな。 + + +implements accetps 綵≪ャ +絎h __code f(int a, int b : int h, ...) { -でもいいんだが... +с... Mon Nov 27 11:34:33 JST 2006 @@ -2053,63 +2053,63 @@ } -g に入るときに、fp は、n の頭になければならない。これを -移動するのは、f の役割。出て行くときには、b の頭に -合わせる必要がある。これは、g の役割。g は、元の頭(fp) -を知らないから、これは取っておく必要がある。差では -判断できない。g 側で取っておくことは可能だが、その -時にも、f 側からずらす大きさを渡す必要がある。 - -明示しても良いんだけどね... +g ャfp n 違 +腱糸f 綵劫蚊冴茵b +綽荀g 綵劫蚊g (fp) +ャc鏆荀綏с +ゆсg 眼уc純 +f 眼紊с羝<綽荀 + +腓冴... goto g(int c,__code *f,__environment,interface &rest), __envronment+sizeof(interface); __code g(int c,__code (*n)(...),(void*)parent,...) { goto n(...),parent; } -みたいな形でさ... その方がいいのかな。繁雑だけど。: よりかまし? - -: を使う方法だと、: が fp みたいな感じになる。 - -難しいね。きれいなsyntaxにならない。 +帥綵≪с... 鴻膵: 障? + +: 篏帥号: fp 帥 + +csyntax Wed Jul 25 14:48:16 JST 2007 -inline code __goto みたいな形にすると、 +inline code __goto 帥綵≪ __goto hoge(); -goto を reflection 出来る。 - -meta な、interface はどうするの? - -デフォルトで、,.... が入っていると思う方が良い。 +goto reflection 堺ャ + +meta interface ? + +с,.... ャc鴻 goto hoge(hoge.... , __code (*cont)(i) : meta ...); goto cont(i); -> goto cont(i: meta...); -という感じか? これがないと、記述がかなり面倒。subroutine とは -違うの? - -env の切替えで明示出来ないの? 出来るけど、繁雑なのか。 - -gcc との相性が良くないのだが... - -__code の先行宣言つらすぎる。script で生成するか、compiler で -自動解決する方が良い。 - -tcc の方が goto f(); ではなくて、goto (*f)(); を -強制する。これは、けっこう、めんどくさい。 - - ... ってのは大域変数みたいなものだよね? ただ、stack scope がある。 -なので、sub routine と同じなのでは? - - - - - - - - - - +? 荐菴違√subroutine +? + +env 帥ф腓阪堺ャ? 堺ャ膵 + +gcc 御с... + +__code 茵絎hゃscript хcompiler +茹f浦鴻 + +tcc 鴻 goto f(); сgoto (*f)(); +綣桁吟c + + ... c紊у紊違帥? stack scope +сsub routine с? + + + + + + + + + +
--- a/README.jp Fri Nov 07 20:12:29 2008 +0000 +++ b/README.jp Sat Nov 08 15:11:06 2008 +0900 @@ -1,14 +1,14 @@ C with Continuation (CwC) and Continuation based C (CbC) - 河野 真治 - 琉球大学情報工学科 + 羃渇 羃 + 紊у怨轡絖腱 0. What is this. -これはC言語の拡張であり、下位言語でもあります。サブルーチン -の代わりに code segment というプログラミング単位を持つ言語 -です。code segment は、軽量継続(light weight continuation) -によって接続されます。C の機能をすべて含む時は、C with -Continuation と呼びます。 +C荐茯≦宍с筝篏荐茯с障泣若 +篁c code segment 違潟医篏よ茯 +сcode segment 荵初靛膓(light weight continuation) +c・膓障C 罘純鴻C with +Continuation 若潟障 #include <stdio.h> @@ -41,141 +41,141 @@ goto (*exit1)(0),exit1env; } -code segment だけを使い、手続き呼び出しをしないと、Cの下位言語 -となります。これを、Continuation based B (Cbc) と呼びます。 -実際、C をCbCにコンパイルすることが可能です。 +code segment 篏帥膓若喝冴C筝篏荐茯 +障Continuation based B (Cbc) 若潟障 +絎C CbC潟潟ゃ純с -CbC は、アーキテクチャに依存しないアセンブラ言語だと思えば良いでしょう。 +CbC ≪若c箴絖≪祉潟荐茯域с -1. 構文 +1. 罕 code code_segment_name(interfaces) { body; } -code は code segment を表す型です。code segment ではreturn -文を使用することはできません。 +code code segment 茵сcode segment сreturn +篏睡с障 -Interfaces は引数です。構造体も使うことができます。Interface -の一部はレジスタにマップされるので参照を取ることはできません。 -構造体は常に可能です。 +Interfaces 綣違с罕篏篏帥с障Interface +筝吾鴻帥усс障 +罕篏絽吾純с -code segment から移動するには goto 文を使います。 +code segment 腱糸 goto 篏帥障 goto segment_name(interfaces); -間接gotoも可能です。同じinterfaceを持つcode segment間では、 -効率の良い移動ができます。普通はjmp命令一つです。(stack -pointer の移動を含む場合もあるので、そうとは限らないんですが..) -異なるInterfaceの場合は、並列代入が起きます。 +・goto純сinterfacecode segmentс +合腱糸с障jmp巡擦筝ゃс(stack +pointer 腱糸翫сс..) +違Interface翫筝篁eャ莎激障 -2. C との関係。 +2. C ≫ -CwC からは自由にCの関数を呼び出すことができます。 +CwC 宴C∽違若喝冴с障 -C の関数からcode segment にgotoするのは自由ですが、 -戻る場合には、Cの関数の環境を明示する必要があります。 +C ∽違code segment goto宴с +祉翫C∽違医腓冴綽荀障 goto factorial(n,1,n,print,return,environment); -return と environment は特殊な変数で、それぞれ、呼び出した -関数の継続(呼び出した関数に戻ることはできません)と、 -その関数の環境(つまりスタック)です。setjump のjump_buf -に似てますが、allocate することはできません。 +return environment 号紊違с若喝冴 +∽違膓膓(若喝冴∽違祉с障) +∽違医(ゃ障鴻帥)сsetjump jump_buf +篌若障allocate с障 void *environment; -という型を持ちます。return 変数は、元の関数の継続、 -つまりreturn文そのものです。その型は元の関数に -依存します。 +<障return 紊違∽違膓膓 +ゃ障returnс∽違 +箴絖障 code (*return)(int return_value); -ここにgotoするには環境を明示したgotoを使います。 -普通にgotoしてはいけません。コンパイラはチェックしてません。 -ごめんなさい。多重にfunction-code-function-codeして、 -一番外のheavy continuationに抜けることはできます。 +goto医腓冴goto篏帥障 +goto障潟潟ゃс障 +紊function-code-function-code +筝紊heavy continuationс障 goto (*exit1)(0),exit1env; -thread として使うことは今のところはできません。 +thread 篏帥篁с障 -3. 使い方 +3. 篏帥 -mc-powerpc, mc-ia32 がコンパイラです。アセンブラソースを出力します。 -アセンブルとリンクにはgccを使って下さい。 +mc-powerpc, mc-ia32 潟潟ゃс≪祉潟純若鴻阪障 +≪祉潟潟gcc篏帥c筝 mc-powerpc source.c gcc source.s -a.out を生成。 +a.out mc-powerpc source.c gcc -c sources.s -.o を生成。 +.o -s comments in assembler source. -c check only. -oname output file names -Idir add library include directory -test の下にいくつか例題があります。 +test 筝ゃ箴蕁障 -3. 実装されてない部分 +3. 絎茖 -// Mips コンパイラはまだ動きません。 +// Mips 潟潟ゃ障障 -64 bit long long が動きます。 -// long long, long double は型として使うことはできますが、 -// 演算はできません。変数の定義もできないと思う。 -// Long long value (0LL) は使えますが、単なるlongを返します。 -// long は32bit. int もpointerも同じ。 +64 bit long long 障 +// long long, long double 篏帥с障 +// 羲膊с障紊違絎臂с +// Long long value (0LL) 篏帥障long菴障 +// long 32bit. int pointer -Mac OS X と Red hat Linux だけでテストしてあります。 -Intel Mac でも動作します。 +Mac OS X Red hat Linux с鴻障 +Intel Mac с篏障 -// Inline は無視され、普通のstatic関数にコンパイルされます。 +// Inline ∴static∽違潟潟ゃ障 -//浮動小数点レジスタへの代入計算はできません。 +//羌絨亥鴻吾鴻帥吾篁eヨ膊с障 // *=, /=, +=. -// built-in allocaはありません。 +// built-in alloca障 -// varargs もないです。 +// varargs с -// Switch 文は、分岐にコンパイルされます。テーブルは生成されません。 +// Switch 絏潟潟ゃ障若障 -// マクロの機能のうち連結とかは動きません。 +// 罘純♂g障 -マクロはコルーチンで、プリプロセッサではありません。振舞いがcppと -少し異なります。 +潟若潟с祉泣с障cpp +絨違障 -デバッグ用の -g はありません。 +亥 -g 障 -CbC のcode segment から実行を始めることはできません。 +CbC code segment 絎茵紮с障 -// #include は、呼び出したソースコードのカレントディレクトリをサーチしません。 - #include は、呼び出したソースコードのカレントディレクトリをサーチします。 +// #include 若喝冴純若鴻潟若潟c泣若障 + #include 若喝冴純若鴻潟若潟c泣若障 -bit-field (こんなの要らないけどさ...) サポートしてますが、 -大域変数への初期化は出来ません。 +bit-field (荀...) 泣若障 +紊у紊違吾堺ャ障 -asm は部分的にしか実装されてません。 +asm 絎茖障 -その他、たくさん。ANSI コンパチを目指しているわけではないので... +篁ANSI 潟潟с... /************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving,
--- a/mc-code-arm.c Fri Nov 07 20:12:29 2008 +0000 +++ b/mc-code-arm.c Sat Nov 08 15:11:06 2008 +0900 @@ -1,15 +1,15 @@ /* Micro-C Code Generation Part for Linux Zaurus and GameBoy Advance */ /* ************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving, @@ -132,15 +132,15 @@ int eval_order = NORMAL; static int reg_sp; /* REGister Stack-Pointer */ -static int reg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int reg_stack[MAX_MAX]; /* 絎吾鴻帥 */ /* floating point registers */ static int freg_sp; /* floating point REGister Stack-Pointer */ -static int freg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int freg_stack[MAX_MAX]; /* 絎吾鴻帥 */ static int lreg_sp; /* longlong REGister Stack-Pointer */ -static int lreg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int lreg_stack[MAX_MAX]; /* 絎吾鴻帥 */ #define REG_ip 13 #define REG_fp 14 @@ -158,10 +158,10 @@ #define MIN_TMP_FREG 0 #define MAX_TMP_FREG 3 -int MAX_REGISTER=17; /* ARMのレジスタを10個まで使う*/ +int MAX_REGISTER=17; /* ARM吾鴻帥10障т戎*/ int MAX_FREGISTER=8; -#define REAL_MAX_REGISTER 17 /* ARMのレジスタが32ということ*/ -#define REAL_MAX_FREGISTER 8 /* ARMのレジスタが32ということ*/ +#define REAL_MAX_REGISTER 17 /* ARM吾鴻帥32*/ +#define REAL_MAX_FREGISTER 8 /* ARM吾鴻帥32*/ #define REAL_MAX_LREGISTER 6 #define FREG_OFFSET REAL_MAX_REGISTER @@ -677,19 +677,19 @@ int get_register(void) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,j,reg; for(i=MAX_TMP_REG;i>=MIN_TMP_REG;i--) { - if (regs[i]) continue; /* 使われている */ - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (regs[i]) continue; /* 篏帥 */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } for(i=0;i<REG_VAR_MAX-REG_VAR_MIN;i++) { reg =REG_VAR_BASE+i; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i+1>max_reg_var) max_reg_var=i+1; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } /* search register stack */ @@ -713,25 +713,25 @@ } } #endif - /* PTR_CACHE をつぶす */ + /* PTR_CACHE ゃ吟 */ for(i=MAX_TMP_REG;i>=MIN_TMP_REG;i--) { if (regs[i]==PTRC_REG) { clear_ptr_cache_reg(i); } else continue; - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } for(i=0;i<REG_VAR_MAX-REG_VAR_MIN;i++) { reg =REG_VAR_BASE+i; - /* PTR_CACHE をつぶす */ + /* PTR_CACHE ゃ吟 */ if (regs[reg]==PTRC_REG) { clear_ptr_cache_reg(reg); regs[reg]=0; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(RGERR); return creg; } @@ -747,14 +747,14 @@ int pop_register(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return reg_stack[--reg_sp]; } #if FLOAT_CODE int get_dregister(int d) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,reg; if (!(arch_mode&UseFPP)) { i = get_lregister(); @@ -763,9 +763,9 @@ } for(i=0;i<MAX_TMP_FREG;i++) { reg = i+MIN_TMP_FREG+FREG_OFFSET; - if (regs[reg]) continue; /* 使われている */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ - return reg; /* その場所を表す番号を返す */ + if (regs[reg]) continue; /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ + return reg; /* 贋茵垩菴 */ } /* search register stack */ for(i=0;i<freg_sp;i++) { @@ -778,13 +778,13 @@ } for(i=0;i<FREG_VAR_MAX;i++) { reg =FREG_VAR_BASE+i+FREG_OFFSET; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i>max_freg_var) max_freg_var=i; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(RGERR); return freg; } @@ -800,7 +800,7 @@ int pop_fregister(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return freg_stack[--freg_sp]; } #endif @@ -844,24 +844,24 @@ if (ll==-1) return -1; if (regs[ll]==0) { for(i=0;i<REG_VAR_MAX-REG_VAR_MIN;i++) { - if (! regs[REG_VAR_BASE+i]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[REG_VAR_BASE+i]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE+i]=USING_REG; if (i+1>max_reg_var) max_reg_var=i+1; for(j=0;j<REG_VAR_MAX-REG_VAR_MIN;j++) { if (! regs[REG_VAR_BASE+j]) { - /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE+j]=USING_REG; if (j+1>max_reg_var) max_reg_var=j+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ regs[ll]=USING_REG; regv_l(ll) = REG_VAR_BASE+j; regv_h(ll) = REG_VAR_BASE+i; return list3n(LREGISTER,ll,n); } } - /* ひとつしかなかった */ + /* 蚊ゃc */ regs[REG_VAR_BASE+i]=0; max_reg_var=max_reg_var_save; goto not_found; @@ -881,7 +881,7 @@ void -free_register(int i) { /* いらなくなったレジスタを開放 */ +free_register(int i) { /* c吾鴻帥 */ // printf("## free_register %d\n",i); regs[i]=0; if (is_longlong_reg(i)) { @@ -1170,11 +1170,11 @@ int max = n?REG_VAR_USER_MAX-REG_VAR_BASE:REG_VAR_MAX-REG_VAR_BASE; for(i=0;i<max;i++) { j = reg_var_num(i); - if (! regs[j]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[j]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[j]=USING_REG; if (i+1>=max_reg_var) max_reg_var=i+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(REGISTER,j,n); } } @@ -1190,10 +1190,10 @@ if ((arch_mode&UseFPP)) { for(i=0;i<FREG_VAR_MAX-FREG_VAR_BASE;i++) { j = freg_var_num(i); - if (! regs[j]) { /* 使われていないなら */ - regs[j]=USING_REG; /*そのレジスタを使うことを宣言し*/ + if (! regs[j]) { /* 篏帥 */ + regs[j]=USING_REG; /*吾鴻帥篏帥絎h*/ if (i+1>max_freg_var) max_freg_var=i+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(FREGISTER,j,n); } } @@ -1207,9 +1207,9 @@ int new_reg,old=creg; if (!is_int_reg(creg)) error(-1); if (reg_sp>MAX_MAX) error(-1); - new_reg = get_register(); /* 絶対に取れる */ + new_reg = get_register(); /* 腟九障 */ if (new_reg==creg) error(-1); /* who freed creg? */ - reg_stack[reg_sp++] = creg; /* push するかわりにレジスタを使う */ + reg_stack[reg_sp++] = creg; /* push 吾鴻帥篏帥 */ ireg = creg = new_reg; if (!regs[creg]) regs[creg]=USING_REG; return old; @@ -1747,7 +1747,7 @@ drn = register_name(reg); } // ldrb r2, [ip, #-1]! @ zero_extendqisi2 -// これはoffsetだから、12bit! +// offset12bit! code_ld(cload(sz,sign),reg,0,xreg,cext_at(sz,sign)); code_add(reg,dir,reg); code_ldf(cstore(sz),drn,0,xreg,sz==SIZE_OF_SHORT?" @ movhi":""); @@ -4754,9 +4754,9 @@ if (car(e2)==FREGISTER) { xreg = cadr(e2); code_float_lib_c("__addsf3",xreg,RET_DREGISTER,dir); - // xreg は increment する - // USE_CREG だと increment する前の値を creg にセット - // reg が指定されていれば、それに前の値をセット + // xreg increment + // USE_CREG increment ゃ creg 祉 + // reg 絎違ゃ祉 if (reg==USE_CREG) { use_float(d,reg); if (reg==RET_FREGISTER) { @@ -4791,9 +4791,9 @@ if (car(e2)==DREGISTER) { xreg = cadr(e2); code_double_lib_c("__adddf3",xreg,RET_DREGISTER,dir); - // xreg は increment する - // USE_CREG だと increment する前の値を creg にセット - // reg が指定されていれば、それに前の値をセット + // xreg increment + // USE_CREG increment ゃ creg 祉 + // reg 絎違ゃ祉 if (reg==USE_CREG) { use_float(d,reg); if (reg==RET_DREGISTER) { @@ -5007,8 +5007,8 @@ } if (!is_float_reg(creg)) error(-1); if (freg_sp>MAX_MAX) error(-1); - new_reg = get_dregister(d); /* 絶対に取れる */ - freg_stack[freg_sp++] = freg; /* push するかわりにレジスタを使う */ + new_reg = get_dregister(d); /* 腟九障 */ + freg_stack[freg_sp++] = freg; /* push 吾鴻帥篏帥 */ creg = freg = new_reg; } @@ -5182,8 +5182,8 @@ int new_reg; if (!is_longlong_reg(creg)) error(-1); if (lreg_sp>MAX_MAX) error(-1); - new_reg = get_lregister(); /* 絶対に取れる(?) */ - lreg_stack[lreg_sp++] = creg; /* push するかわりにレジスタを使う */ + new_reg = get_lregister(); /* 腟九障(?) */ + lreg_stack[lreg_sp++] = creg; /* push 吾鴻帥篏帥 */ lreg = creg = new_reg; }
--- a/mc-code-ia32.c Fri Nov 07 20:12:29 2008 +0000 +++ b/mc-code-ia32.c Sat Nov 08 15:11:06 2008 +0900 @@ -2,15 +2,15 @@ /************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving, @@ -271,8 +271,8 @@ int code_lassop_p = 0; -#define MAX_REGISTER 6 /* intel386のレジスタを6つまで使う*/ -#define REAL_MAX_REGISTER 8 /* intel386のレジスタが8つということ*/ +#define MAX_REGISTER 6 /* intel386吾鴻帥6ゃ障т戎*/ +#define REAL_MAX_REGISTER 8 /* intel386吾鴻帥8ゃ*/ static int MAX_DATA_REG=4; static int MAX_POINTER=3; int MAX_REGISTER_VAR=2; @@ -287,13 +287,13 @@ // static int MAX_CODE_INPUT_DREGISTER_VAR = 0; static int reg_sp; /* REGister Stack-Pointer */ -static int reg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int reg_stack[MAX_MAX]; /* 絎吾鴻帥 */ static int stack_depth = 0; /* floating point registers */ static int freg_sp; /* floating point REGister Stack-Pointer */ -static int freg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int freg_stack[MAX_MAX]; /* 絎吾鴻帥 */ static int reg_var; @@ -441,7 +441,7 @@ code segment stack frame - * gotoを呼び出した関数のr1 ! r1(goto前のr1) + * goto若喝冴∽違r1 ! r1(gotor1) disp_offset # * ebp <---r1_offset---------> esp r+ +----------+--+----------+----------------+-----------+----------+----+ @@ -742,20 +742,20 @@ int get_register(void) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,reg,j; for(i=1;i<MAX_REGISTER+1;i++) { - if (! regs[i]) { /* 使われていないなら */ - regs[i]=1; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (! regs[i]) { /* 篏帥 */ + regs[i]=1; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } } #ifdef __APPLE__ - /* PTR_CACHE をつぶす */ + /* PTR_CACHE ゃ吟 */ if ((i=last_ptr_cache())) { clear_ptr_cache_reg(i); - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } #endif /* search register stack */ @@ -768,26 +768,26 @@ } } error(RGERR); - return -1; /* 空いている場所がないなら、それを表す -1 を返す */ + return -1; /* 腥冴贋茵 -1 菴 */ } static int get_data_register(void) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,reg,j; for(i=REG_EAX;i<=REG_EDX;i++) { - if (! regs[i]) { /* 使われていないなら */ - regs[i]=1; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (! regs[i]) { /* 篏帥 */ + regs[i]=1; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } } #ifdef __APPLE__ - /* PTR_CACHE をつぶす */ + /* PTR_CACHE ゃ吟 */ while ((i=last_ptr_cache())) { clear_ptr_cache_reg(i); if (is_data_reg(i)) { - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } } #endif @@ -801,11 +801,11 @@ } } error(-1); - return -1; /* 空いている場所がないなら、それを表す -1 を返す */ + return -1; /* 腥冴贋茵 -1 菴 */ } void -free_register(int i) { /* いらなくなったレジスタを開放 */ +free_register(int i) { /* c吾鴻帥 */ if (i==REG_L) { reg_var=0; regs[REG_ESI]=regs[REG_EDI]=0; @@ -1048,7 +1048,7 @@ int pop_register(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return reg_stack[--reg_sp]; } @@ -1066,9 +1066,9 @@ { int i; for(i=REG_ESI;i<REG_EBP;i++) { - if (! regs[i]) { /* 使われていないなら */ - regs[i]=REG_VAR; /* そのレジスタを使うことを宣言し */ - return list3n(REGISTER,i,nptr); /* その場所を表す番号を返す */ + if (! regs[i]) { /* 篏帥 */ + regs[i]=REG_VAR; /* 吾鴻帥篏帥絎h */ + return list3n(REGISTER,i,nptr); /* 贋茵垩菴 */ } } return list3n(LVAR,new_lvar(SIZE_OF_INT),0); @@ -1085,11 +1085,11 @@ emit_push() { int new_reg,old; - new_reg = get_register(); /* 絶対に取れる */ + new_reg = get_register(); /* 腟九障 */ // who free new_reg? if (new_reg==creg) error(-1); old = creg; - reg_stack[reg_sp++] = creg; /* push するかわりにレジスタを使う */ + reg_stack[reg_sp++] = creg; /* push 吾鴻帥篏帥 */ ireg = creg = new_reg; if (!regs[creg]) regs[creg]=USING_REG; return old;
--- a/mc-code-mips.c Fri Nov 07 20:12:29 2008 +0000 +++ b/mc-code-mips.c Sat Nov 08 15:11:06 2008 +0900 @@ -3,15 +3,15 @@ /* ************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving, @@ -119,15 +119,15 @@ #define ENDIAN_D 0 static int reg_sp; /* REGister Stack-Pointer */ -static int reg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int reg_stack[MAX_MAX]; /* 絎吾鴻帥 */ /* floating point registers */ static int freg_sp; /* floating point REGister Stack-Pointer */ -static int freg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int freg_stack[MAX_MAX]; /* 絎吾鴻帥 */ static int lreg_sp; /* longlong REGister Stack-Pointer */ -static int lreg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int lreg_stack[MAX_MAX]; /* 絎吾鴻帥 */ #define REG_fp 1 #define REG_sp 30 @@ -141,10 +141,10 @@ #define MIN_TMP_FREG 0 #define MAX_TMP_FREG 11 -int MAX_REGISTER=30; /* MIPSのレジスタを10個まで使う*/ +int MAX_REGISTER=30; /* MIPS吾鴻帥10障т戎*/ int MAX_FREGISTER=31; -#define REAL_MAX_REGISTER 32 /* MIPSのレジスタが32ということ*/ -#define REAL_MAX_FREGISTER 32 /* MIPSのレジスタが32ということ*/ +#define REAL_MAX_REGISTER 32 /* MIPS吾鴻帥32*/ +#define REAL_MAX_FREGISTER 32 /* MIPS吾鴻帥32*/ #define REAL_MAX_LREGISTER 16 #define FREG_OFFSET REAL_MAX_REGISTER @@ -370,7 +370,7 @@ code segment stack frame - * gotoを呼び出した関数のr1 ! r1(goto前のr1) + * goto若喝冴∽違r1 ! r1(gotor1) # * $fp <---r1_offset---------> $sp r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -628,21 +628,21 @@ int get_register(void) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,j,reg; for(i=MAX_TMP_REG;i>MIN_TMP_REG;i--) { - if (regs[i]) continue; /* 使われている */ - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (regs[i]) continue; /* 篏帥 */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } - /* PTR_CACHE をつぶす */ + /* PTR_CACHE ゃ吟 */ for(i=MAX_TMP_REG;i>MIN_TMP_REG;i--) { if (regs[i]==PTRC_REG) { clear_ptr_cache_reg(i); } else continue; - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } /* search register stack */ for(i=0;i<reg_sp;i++) { @@ -667,13 +667,13 @@ #endif for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { reg =REG_VAR_BASE-i; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i+1>max_reg_var) max_reg_var=i+1; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(RGERR); return creg; } @@ -689,14 +689,14 @@ int pop_register(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return reg_stack[--reg_sp]; } #if FLOAT_CODE int get_dregister(int d) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,reg; if (d) { i = get_lregister(); @@ -704,9 +704,9 @@ return i; } for(i=MAX_TMP_FREG+FREG_OFFSET;i>MIN_TMP_FREG+FREG_OFFSET;i--) { - if (regs[i]) continue; /* 使われている */ - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (regs[i]) continue; /* 篏帥 */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } /* search register stack */ for(i=0;i<freg_sp;i++) { @@ -719,13 +719,13 @@ } for(i=0;i<FREG_VAR_BASE-REG_VAR_MIN;i++) { reg =FREG_VAR_BASE-i+FREG_OFFSET; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i+1>max_freg_var) max_freg_var=i+1; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(REG_ERR); return freg; } @@ -741,7 +741,7 @@ int pop_fregister(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return freg_stack[--freg_sp]; } #endif @@ -784,24 +784,24 @@ if (ll==-1) return -1; if (regs[ll]==0) { for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { - if (! regs[REG_VAR_BASE-i]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[REG_VAR_BASE-i]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE-i]=USING_REG; if (i+1>max_reg_var) max_reg_var=i+1; for(j=0;j<REG_VAR_BASE-REG_VAR_MIN;j++) { if (! regs[REG_VAR_BASE-j]) { - /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE-j]=USING_REG; if (j+1>max_reg_var) max_reg_var=j+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ regs[ll]=USING_REG; regv_l(ll) = REG_VAR_BASE-j; regv_h(ll) = REG_VAR_BASE-i; return list3n(LREGISTER,ll,n); } } - /* ひとつしかなかった */ + /* 蚊ゃc */ regs[REG_VAR_BASE-i]=0; max_reg_var=max_reg_var_save; goto not_found; @@ -821,7 +821,7 @@ void -free_register(int i) { /* いらなくなったレジスタを開放 */ +free_register(int i) { /* c吾鴻帥 */ // printf("## free_register %d\n",i); regs[i]=0; if (is_longlong_reg(i)) { @@ -1132,11 +1132,11 @@ int i,j; for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { j = reg_var_num(i); - if (! regs[j]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[j]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[j]=USING_REG; if (i+1>=max_reg_var) max_reg_var=i+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(REGISTER,j,n); } } @@ -1160,10 +1160,10 @@ for(i=0;i<FREG_VAR_BASE-FREG_VAR_MIN;i++) { j = freg_var_num(i); - if (! regs[j]) { /* 使われていないなら */ - regs[j]=USING_REG; /*そのレジスタを使うことを宣言し*/ + if (! regs[j]) { /* 篏帥 */ + regs[j]=USING_REG; /*吾鴻帥篏帥絎h*/ if (i+1>max_freg_var) max_freg_var=i+1; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(FREGISTER,j,n); } } @@ -1176,9 +1176,9 @@ int new_reg,old=creg; if (!is_int_reg(creg)) error(-1); if (reg_sp>MAX_MAX) error(-1); - new_reg = get_register(); /* 絶対に取れる */ + new_reg = get_register(); /* 腟九障 */ if (creg==new_reg) error(-1); /* some one free creg */ - reg_stack[reg_sp++] = creg; /* push するかわりにレジスタを使う */ + reg_stack[reg_sp++] = creg; /* push 吾鴻帥篏帥 */ ireg = creg = new_reg; if (!regs[creg]) regs[creg]=USING_REG; return old; @@ -4236,9 +4236,9 @@ if (car(e2)==DREGISTER) { xreg = cadr(e2); code_double_lib_c("dpadd",xreg,RET_DREGISTER,dir); - // xreg は increment する - // USE_CREG だと increment する前の値を creg にセット - // reg が指定されていれば、それに前の値をセット + // xreg increment + // USE_CREG increment ゃ creg 祉 + // reg 絎違ゃ祉 if (reg==USE_CREG) { use_float(d,reg); if (reg==RET_DREGISTER) { @@ -4379,8 +4379,8 @@ } if (!is_float_reg(creg)) error(-1); if (freg_sp>MAX_MAX) error(-1); - new_reg = get_dregister(d); /* 絶対に取れる */ - freg_stack[freg_sp++] = freg; /* push するかわりにレジスタを使う */ + new_reg = get_dregister(d); /* 腟九障 */ + freg_stack[freg_sp++] = freg; /* push 吾鴻帥篏帥 */ creg = freg = new_reg; } @@ -5044,8 +5044,8 @@ int new_reg; if (!is_longlong_reg(creg)) error(-1); if (lreg_sp>MAX_MAX) error(-1); - new_reg = get_lregister(); /* 絶対に取れる(?) */ - lreg_stack[lreg_sp++] = creg; /* push するかわりにレジスタを使う */ + new_reg = get_lregister(); /* 腟九障(?) */ + lreg_stack[lreg_sp++] = creg; /* push 吾鴻帥篏帥 */ lreg = creg = new_reg; }
--- a/mc-code-powerpc.c Fri Nov 07 20:12:29 2008 +0000 +++ b/mc-code-powerpc.c Sat Nov 08 15:11:06 2008 +0900 @@ -3,15 +3,15 @@ /* ************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving, @@ -206,15 +206,15 @@ #define ENDIAN_D 1 static int reg_sp; /* REGister Stack-Pointer */ -static int reg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int reg_stack[MAX_MAX]; /* 絎吾鴻帥 */ /* floating point registers */ static int freg_sp; /* floating point REGister Stack-Pointer */ -static int freg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int freg_stack[MAX_MAX]; /* 絎吾鴻帥 */ static int lreg_sp; /* longlong REGister Stack-Pointer */ -static int lreg_stack[MAX_MAX]; /* 実際のレジスタの領域 */ +static int lreg_stack[MAX_MAX]; /* 絎吾鴻帥 */ #ifdef __APPLE__ #define REG_sp 1 @@ -242,10 +242,10 @@ #define MAX_TMP_FREG 9 #endif -int MAX_REGISTER=30; /* PowerPCのレジスタを10個まで使う*/ +int MAX_REGISTER=30; /* PowerPC吾鴻帥10障т戎*/ int MAX_FREGISTER=31; -#define REAL_MAX_REGISTER 32 /* PowerPCのレジスタが32ということ*/ -#define REAL_MAX_FREGISTER 32 /* PowerPCのレジスタが32ということ*/ +#define REAL_MAX_REGISTER 32 /* PowerPC吾鴻帥32*/ +#define REAL_MAX_FREGISTER 32 /* PowerPC吾鴻帥32*/ #define REAL_MAX_LREGISTER 16 #define FREG_OFFSET REAL_MAX_REGISTER @@ -467,7 +467,7 @@ code segment stack frame - * gotoを呼び出した関数のr1 ! r1(goto前のr1) + * goto若喝冴∽違r1 ! r1(gotor1) # * r30 <---r1_offset---------> r1 r+ +----------+--+----------+----------------+-----------+----------+----+ cousin arg xx reg save !callee arg !code local caller arg xx @@ -851,18 +851,18 @@ int get_register(void) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,j,reg; for(i=MAX_TMP_REG;i>MIN_TMP_REG;i--) { - if (regs[i]) continue; /* 使われている */ - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ - } - /* PTR_CACHE をつぶす */ + if (regs[i]) continue; /* 篏帥 */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ + } + /* PTR_CACHE ゃ吟 */ if ((i=last_ptr_cache())) { clear_ptr_cache_reg(i); - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } /* search register stack */ for(i=0;i<reg_sp;i++) { @@ -887,13 +887,13 @@ #endif for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { reg =REG_VAR_BASE-i; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i>max_reg_var) max_reg_var=i; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(RGERR); return creg; } @@ -909,19 +909,19 @@ int pop_register(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return reg_stack[--reg_sp]; } #if FLOAT_CODE int get_dregister(int d) -{ /* 使われていないレジスタを調べる */ +{ /* 篏帥吾鴻帥茯帥鴻 */ int i,reg; for(i=MAX_TMP_FREG+FREG_OFFSET;i>MIN_TMP_FREG+FREG_OFFSET;i--) { - if (regs[i]) continue; /* 使われている */ - regs[i]=USING_REG; /* そのレジスタを使うことを宣言し */ - return i; /* その場所を表す番号を返す */ + if (regs[i]) continue; /* 篏帥 */ + regs[i]=USING_REG; /* 吾鴻帥篏帥絎h */ + return i; /* 贋茵垩菴 */ } /* search register stack */ for(i=0;i<freg_sp;i++) { @@ -934,13 +934,13 @@ } for(i=0;i<FREG_VAR_BASE-REG_VAR_MIN;i++) { reg =FREG_VAR_BASE-i+FREG_OFFSET; - if (! regs[reg]) { /* 使われていないなら */ - regs[reg]=USING_REG; /* そのレジスタを使うことを宣言し */ + if (! regs[reg]) { /* 篏帥 */ + regs[reg]=USING_REG; /* 吾鴻帥篏帥絎h */ if (i>max_freg_var) max_freg_var=i; - return reg; /* その場所を表す番号を返す */ + return reg; /* 贋茵垩菴 */ } } - /* 空いている場所がないなら、エラー (いったい誰が使ってるの?) */ + /* 腥冴贋 (c茯違篏帥c?) */ error(REG_ERR); return freg; } @@ -956,7 +956,7 @@ int pop_fregister(void) -{ /* レジスタから値を取り出す */ +{ /* 吾鴻帥ゃ冴 */ return freg_stack[--freg_sp]; } #endif @@ -1040,24 +1040,24 @@ if (ll==-1) goto not_found; if (regs[ll]==0) { for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { - if (! regs[REG_VAR_BASE-i]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[REG_VAR_BASE-i]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE-i]=USING_REG; if (i>max_reg_var) max_reg_var=i; for(j=0;j<REG_VAR_BASE-REG_VAR_MIN;j++) { if (! regs[REG_VAR_BASE-j]) { - /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE-j]=REG_VAR; if (j>max_reg_var) max_reg_var=j; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ regs[ll]=REG_VAR; regv_l(ll) = REG_VAR_BASE-j; regv_h(ll) = REG_VAR_BASE-i; return list3n(LREGISTER,ll,n); } } - /* ひとつしかなかった */ + /* 蚊ゃc */ regs[REG_VAR_BASE-i]=0; max_reg_var=max_reg_var_save; goto not_found; @@ -1077,7 +1077,7 @@ void -free_register(int i) { /* いらなくなったレジスタを開放 */ +free_register(int i) { /* c吾鴻帥 */ // printf("## free_register %d\n",i); if (is_longlong_reg(i)) { regs[regv_l(i)]=0; @@ -1372,11 +1372,11 @@ { int i; for(i=0;i<REG_VAR_BASE-REG_VAR_MIN;i++) { - if (! regs[REG_VAR_BASE-i]) { /* 使われていないなら */ - /* そのレジスタを使うことを宣言し */ + if (! regs[REG_VAR_BASE-i]) { /* 篏帥 */ + /* 吾鴻帥篏帥絎h */ regs[REG_VAR_BASE-i]=REG_VAR; if (i>max_reg_var) max_reg_var=i; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(REGISTER,REG_VAR_BASE-i,n); } } @@ -1388,10 +1388,10 @@ { int i; for(i=0;i<FREG_VAR_BASE-FREG_VAR_MIN;i++) { - if (! regs[FREG_VAR_BASE-i+FREG_OFFSET]) { /* 使われていないなら */ - regs[FREG_VAR_BASE-i+FREG_OFFSET]=REG_VAR; /*そのレジスタを使うことを宣言し*/ + if (! regs[FREG_VAR_BASE-i+FREG_OFFSET]) { /* 篏帥 */ + regs[FREG_VAR_BASE-i+FREG_OFFSET]=REG_VAR; /*吾鴻帥篏帥絎h*/ if (i>max_freg_var) max_freg_var=i; - /* その場所を表す番号を返す */ + /* 贋茵垩菴 */ return list3n(DREGISTER, FREG_VAR_BASE-i+FREG_OFFSET,n); } @@ -1405,9 +1405,9 @@ int new_reg,old=creg; if (!is_int_reg(creg)) error(-1); if (reg_sp>MAX_MAX) error(-1); - new_reg = get_register(); /* 絶対に取れる */ + new_reg = get_register(); /* 腟九障 */ if (new_reg==creg) error(-1); // freed creg - reg_stack[reg_sp++] = creg; /* push するかわりにレジスタを使う */ + reg_stack[reg_sp++] = creg; /* push 吾鴻帥篏帥 */ ireg = creg = new_reg; if (!regs[creg]) regs[creg]=USING_REG; return old; @@ -2265,8 +2265,8 @@ /* use input register as current register - なんで、こんなに複雑なんだ? - むしろ、INPUT_REG みたいな mark をいれたら? + с茲? + INPUT_REG 帥 mark ? */ static void @@ -2278,7 +2278,7 @@ ireg = 0; } if (lreg) { - // free_regsiter(lreg) でいいんじゃないの? + // free_regsiter(lreg) с? if (regv_l(lreg)==reg) { regs[lreg]=0; if (regv_h(lreg)>reg&®s[regv_h(lreg)]==USING_REG) { @@ -4883,8 +4883,8 @@ int new_reg; if (!is_float_reg(creg)) error(-1); if (freg_sp>MAX_MAX) error(-1); - new_reg = get_dregister(1); /* 絶対に取れる */ - freg_stack[freg_sp++] = freg; /* push するかわりにレジスタを使う */ + new_reg = get_dregister(1); /* 腟九障 */ + freg_stack[freg_sp++] = freg; /* push 吾鴻帥篏帥 */ creg = freg = new_reg; } @@ -5804,8 +5804,8 @@ int new_reg; if (!is_longlong_reg(creg)) error(-1); if (lreg_sp>MAX_MAX) error(-1); - new_reg = get_lregister(); /* 絶対に取れる(?) */ - lreg_stack[lreg_sp++] = creg; /* push するかわりにレジスタを使う */ + new_reg = get_lregister(); /* 腟九障(?) */ + lreg_stack[lreg_sp++] = creg; /* push 吾鴻帥篏帥 */ lreg = creg = new_reg; }
--- a/mc-codegen.c Fri Nov 07 20:12:29 2008 +0000 +++ b/mc-codegen.c Sat Nov 08 15:11:06 2008 +0900 @@ -3,15 +3,15 @@ /* ************************************************************************ ** Copyright (C) 2006 Shinji Kono -** 連絡先: 琉球大学情報工学科 河野 真治 -** (E-Mail Address: kono@ie.u-ryukyu.ac.jp) +** g機鐚 紊у怨轡絖腱 羃渇 羃 +** 鐚E-Mail Address: kono@ie.u-ryukyu.ac.jp鐚 ** -** このソースのいかなる複写,改変,修正も許諾します。ただし、 -** その際には、誰が貢献したを示すこの部分を残すこと。 -** 再配布や雑誌の付録などの問い合わせも必要ありません。 -** 営利利用も上記に反しない範囲で許可します。 -** バイナリの配布の際にはversion messageを保存することを条件とします。 -** このプログラムについては特に何の保証もしない、悪しからず。 +** 純若鴻茲鐚劫鐚篆罩c荐沿障障 +** 茯違莢∝腓冴罧 +** 絽茯篁蚊綽荀障 +** 九筝荐膀蚊ц┗障 +** ゃ絽version message篆絖>散障 +** 違ゃ鴻篏篆荐若 ** ** Everyone is permitted to do anything on this program ** including copying, modifying, improving, @@ -258,7 +258,7 @@ if (car(e2)!=LVAR) error(-1); code_label_value(cadr(e2),USE_CREG); return ADDRESS; - case CONST: /* 代入する値が0でも特別な処理はしない */ + case CONST: /* 篁eャゃ0с劫ャ */ code_const(e2,USE_CREG); return INT; #if FLOAT_CODE @@ -352,7 +352,7 @@ return register_to_lvar(e2); /* too late? */ else return g_expr0(e2); - case MINUS: /* レジスタに対し、neglを実行すれば実現可能 */ + case MINUS: /* 吾鴻帥絲障negl絎茵医憜 */ g_expr0(e2); code_neg(USE_CREG); return INT; #if LONGLONG_CODE @@ -940,7 +940,7 @@ error(REG_ERR); return 0; #if 0 - 途中でレジスタからLVARに変更しても、間に合わない。 + 筝с吾鴻帥LVAR紊眼 NMTBL *n = (NMTBL*)caddr(e); int reg = cadr(e); @@ -973,8 +973,8 @@ // // target = list3(target_regnum,next,source_regnum); // -// register の大きさはsize_of_int とは限らない。むしろ、 -// get_register_var した方が安全... +// register 紊сsize_of_int +// get_register_var 鴻絎... extern void parallel_rassign(int assigns) @@ -1096,8 +1096,8 @@ save_target(int t,int s,int *target,int *use,int sz,int ty) { int e1 = 0; - // 使ったら free するべきだよね? code goto の時なら害はないか... - /*新しいレジスタ(or スタック)を取得する*/ + // 篏帥c free 鴻? code goto 絎潟... + /*違吾鴻(or 鴻帥)緇*/ if (scalar(ty) && sz==size_of_int && (e1=get_register_var(0))!=-1) { // e1=list3(REGISTER,e1,0); if (code_register_overlap(s,e1)) goto use_lvar; @@ -1187,7 +1187,7 @@ t=car(target0); s=cadddr(target0); sz=size(ty=caddr(target0)); if(car(t)==car(s) && cadr(t)==cadr(s)) { - /*書き込み先が自分自身*/ + /*吾莨若水荳*/ #if DEBUG_PARALLEL_ASSIGN if (lsrc) printf("## remove same %d ty %d+%d sz %d\n",car(t),ty,cadr(t),sz); #endif @@ -1195,7 +1195,7 @@ progress = 1; } else if (!(s1=overlap(t,sz,*target)) || (cadr(s1)==0 && car(car(s1))==t)) { - /* 重なってないので安心して書き込める */ + /* cу綽吾莨若 */ #if DEBUG_PARALLEL_ASSIGN if (s1 && cadr(s1)==0) { if (lsrc) printf("## singleton %d ty %d+%d sz %d\n",car(t),ty,cadr(t),sz); @@ -1472,7 +1472,7 @@ g_expr_u(assign_expr0(envreg,env,INT,INT)); } - /* まず、サイズを計算しながら、target を決まった形に落す。 */ + /* 障泣ゃ冴荐膊target 羆冴障c綵≪純 */ /* list5(target,next,ty,source,source_dependency) */ arg_size = 0; regs = 0; @@ -1516,22 +1516,22 @@ } - /* disp を飛び先似合わせて修正 */ + /* disp 蕋喝篌弱篆罩 */ if (is_code(fnptr)) { if (-arg_size<disp) disp = -arg_size; } else { if (disp_offset-arg_size<disp) disp = disp_offset-arg_size; } - /* 複雑な式を前もって計算しておく */ - /* 必要なら局所変数を用いる。 */ - /* 局所変数へのオフセットを覚えておく */ + /* 茲綣c荐膊 */ + /* 綽荀絮紊違 */ + /* 絮紊違吾祉荀 */ for (e2 = target; e2; e2 = cadr(e2)) { t0=car(e2); s0=cadddr(e2); sz=size(ty=caddr(e2)); if(car(t0)==LVAR) { - /* ここで、書込先アドレスを決める */ + /* с梧昭≪鴻羆冴 */ if (envreg) error(-1); cadr(t0)=-arg_size; // disp_offset?! } @@ -1613,7 +1613,7 @@ } if (chk) return; - /* 並列代入を実行 */ + /* 筝篁eャ絎茵 */ parallel_assign(&target,&processing,&use); while (use) { reg = car(caddr(use)); @@ -1814,8 +1814,8 @@ emit_push(); g_expr(e2); xreg = emit_pop(0); - /* 一般的にはコピーのオーバラップの状況は実行時にしかわからない */ - /* しかし、わかる場合もある */ + /* 筝潟若若倶絎茵 */ + /* 翫 */ if (is_same_type(e2,e4)) { if(cadr(e2)>cadr(e4)) { offset=sz; sz=-sz;} else offset=0; @@ -2572,9 +2572,9 @@ #if 0 /* new = &e2 */ /* *new = *new op e3 */ - // e2 が複雑な式でないと却ってだめなこともある - // register が取れれば常に有効か? - // たぶん、i386 の時には有効だったんだろうなぁ。 + // e2 茲綣с眼c + // register 医幻鴻? + // 吟i386 鴻c int n = list3n(LVAR,new_lvar(size_of_int),0); // get register var? g_expr_u(assign_expr0(n,list2(ADDRESS,e2),INT,INT)); g_expr0(assign_expr0(rvalue_t(n,INT), @@ -3370,10 +3370,10 @@ ndsp = fwdlabel(); else ndsp = --disp; - // inmode の時は pvartable のoffset を確保する。st_label で - // nptr が 0 ならば backdef、st_label よりも先に使われたら - // fwdlabel すれば良い。 - // scope は parse 時に解決される。 + // inmode pvartable offset 腆坂st_label + // nptr 0 backdefst_label 篏帥 + // fwdlabel 域 + // scope parse 茹f浦 break; case ADECL: // funcion arguments if(type0>0) { @@ -4230,7 +4230,7 @@ if(car(e)==INDIRECT) return cadr(e); return list2(ADDRESS,e); case STRUCT: case UNION: - // RINDIRECT がいいのかも + // RINDIRECT if(car(e)==RSTRUCT) return e; /* ??? */ return list3(RSTRUCT,e,cadr(type) /* size */); case FUNCTION: @@ -4945,9 +4945,9 @@ if (cadr(t)>0) { switch(car(cadr(t))) { case FUNCTION: - // type でチェックするべきだよね? 本来... + // type сс鴻? ... // compatible(cadr(t),cadr(type)); - // ではあかんの? + // с? if (car(e)==FNAME) { NMTBL *n = ncaddr(e); int targ0 = caddr(cadr(t));
--- a/tools/regs.pl Fri Nov 07 20:12:29 2008 +0000 +++ b/tools/regs.pl Sat Nov 08 15:11:06 2008 +0900 @@ -17,8 +17,8 @@ grep($fmask |= (1<<($_)),@fregs); grep($fcount += $_?1:0 ,@fregs); -# count のルールは良く分からないね。カウントじゃないみたいだな。 -# やっぱりregister saveのoffsetみたいだね (gcc によると) +# count 若潟帥 +# c宴register saveoffset帥 (gcc ) # printf(".mask\t%x,%d\n",$mask,-$count*4); @@ -26,6 +26,6 @@ # cprestore # input variable? -# call するサブルーチンの整数の引数の数か? +# call 泣若潟贋違綣違違?