Mercurial > hg > CbC > old > device
diff Idea @ 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 | f536897fa3cb |
| children |
line wrap: on
line diff
--- 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 +絮紊違 +篁ｃ紊у紊違紊 +紊у紊違鴻潟若絮 +Fortran 絮紊違 +recursion т絖 +subroutine call吾鴻帥祉若絮茵 +＜ｃ紊? +ｃ宴若≧? + +recursive call с阪ャ? + +fp 鴻 + +∽医臂絨fp罕篏 + +C compilestack≧ fp = (struct func_state *)stack -えっと、どこに代入するの? そういう問題もあるわけね。 -じゃあ、fpは特別? それは気に入らないな。static -なfpにすれば良いわけね。 +ｃ篁ｅャ? 馹 +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 ｃ羲膊絖ｃ鴻? 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 ? ｃ... + +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 祉ｃャ... 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 с筝潟若茵憗ｃ鴻? <-> interpreter? + +Prolog сс? --> Unification Sat Nov 27 13:50:41 JST 1999 -func.state とか作るのだったら、 +func.state 篏ｃ struct { struct { int i; @@ -91,11 +91,11 @@ i = i+1; }; } name; -みたいな形で、それ自体を構造化すれば? で、代入すると部分評価される。 -代入も可能。なるほど。 +帥綵≪с篏罕? с篁ｅャ荅箴＜ +篁ｅャ純祉 *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 祉潟ｃ鴻絎茵膤祉純? + +byte code 篁潟激潟ｃ純с翫? + +罕篏帥違uniqueс篆罩ｃ + +＜ゃ? 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 ｃ鴻caller 眼ｃ +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 篏帥障 +絎茖сс倶с? +ｃ宴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 ｃ (? ) frame pointer +stack pointer 羃帥ｃ腱糸翫offset +у違篏 + +ゃ障ｃ? ゃ障goto +frame pointer stack 翫 +frame pointer 後障綣違≪祉鴻医ャ + +stack 綣違腥絎壕goto 翫眼 +stack 潟ｃ? ∽違絎臂 +号紊ｃ障 + +goto semantics C 篋 +鴻違 +∽医若喝冴荵純... + +C call call function +絎憗篁若喝冴鴻goto 宴 +鴻罩ｃ + +馹荐茯∽違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 の前後で、値を保証しないか... - -うーん、だんだん炸裂してるなぁ。 - -だから、レジスタに対するマッピングの記述と、そうでない部分の -記述は分離するべきでしょうね。 - - -全部一辺に実装するわけにはいかないからぁ... +帥сｃ≪祉潟障return羆 +障return 障returnс + +ャcode 茲違 + +state 篁ュconsistent state с篆荐若ｃ? +local 紊違篏帥ｃcall/goto 緇сゃ篆荐若... + +若梧 + +吾鴻帥絲障潟違荐菴違с +荐菴違≪鴻с + + +筝莨冴絎茖... Thu Dec 16 13:44:21 JST 1999 -lock は状態遷移レベルで実現するのだから、self などを -使ってlockする必要はないはず。 - -全体の直列化は、状態遷移レベルで、 +lock 倶欠Щу憗self +篏帥ｃlock綽荀 + +篏翫倶欠Щс lock(storage) -> transition -みたいな形で記述すれば良い。この当たりを、どのように記述するかは -もう少し先送りしよう。 - - -引数はレジスタ渡しにしよう。長い引数は、呼び出し側の領域への -ポインタとする。実装を規定しても良い。そうすれば、varargs -みたいなものはなくなる。だいたい、なんで、そんなものがいるんだろう? -配列を渡せばいいじゃん。 - -なので、引数は一つ(or 二つ)に限るという方法もある。 - -とすると、やはり、前もって静的領域や動的領域を確保することは -できない。 - -この言語では動的領域は自分で確保するわけだから、その点は問題ない。 +帥綵≪ц菴違域綵荐菴違 +絨 + + +綣違吾鴻炊検激綣違若喝冴眼吾 +ゃ潟帥絎茖荀鎘違varargs +帥с? +羝＜違 + +с綣違筝(or 篋)号 + +ｃ腆坂 +с + +荐茯сх∈篆鴻馹 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 潟潟ゃ +ｃ鴻frame pointer static +障frame pointer first argument +鴻罩ｃ綣違 +緇荐 f(fp,argument) -fp を渡すのにさらにargument をレジスタで渡すのはおかしい。おかしいけど、 -ま、良いか。 - -return しないなら、return type の定義をとるのは変だな。 - -f(fp,arg1,arg2,arg3) とすると、それぞれが決まったレジスタに入って、 -多い分は配列にあると思われる。ふむふむ... +fp 羝＜argument 吾鴻帥ф検 +障 + +return return type 絎臂紊 + +f(fp,arg1,arg2,arg3) 羆冴障ｃ吾鴻帥ャｃ +紊泣泣... fp->xx -でアクセスすれば、そのまま局所変数になる。全部、配列で -送っても良い。 +с≪祉鴻違障上紊違 +ｃ .set label,value -で as は値をセットするようですね。 - -関数コールの後は戻って来ないから後始末の心配はしなくてよい。 -frame pointer を使ったら自分で面倒を見ること。 - -だと + as ゃ祉с + +∽違潟若緇祉ｃャ緇紮綽 +frame pointer 篏帥ｃч√荀 + + 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は使えないんだから、それでいいはず。 - -で、それから、これを拡張していく。 + + +ｃ障吾鴻帥絎茖 + +сstack 篏帥ｃ羲膊筝綽障障? с +綣筝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? + +吾鴻水ャｃ宴optional荐宴 + +interface 罕篏... 罕篏с? +罕篏翫... malloc ? 若malloc +free ? + +ャ紕? multi-thread с違 +multi thread с倶吾鴻睡宴障thread local +綽荀static thread local +紊у紊違蚊ｃ＜с障 + +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? 堺吾鴻水蚊綵... +篏睡? 若紊ц緇≧頳障ｃ宴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 ャ祉罩ｃ... Sun Jan 2 01:47:17 JST 2000 -register 変数はできました。けど、register を二つ使うと、 -一杯になってしまうので、REGISTER6 でコンパイルしないと -結構ひどい。が、register 変数を%esi,%edi に割り当てれば -いいか。 +register 紊違с障register 篋や戎 +筝ｃ障с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 祉ｃャ＜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 篆罩ｃ域 +(篁祉ｃャу馹) + +code1 goto с祉ｃャ綽荀 +label code1 筝ф検＜ｃ羂障 + +胼罩≪main() 筝stackсgoto? +♂緇腟絮絽違... 若 + +main() 筝local code 荐宴違茹ｆ浦.. 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 ｃ障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荐馹 + +сｃcall違? 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 ｃ +筝綺 pushl %ebp 祉push +筝(*) leave movl %ebp,%esp popl %ebp -じゃなかったか? +ｃ? 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 ｃ peep hole optimization version +篏? + +continuation label 鴻? +箴水＜ｃ羆違 +堺ャ眼医(frame)膓 +綽荀障с... + +label ゃゃ a = label:; -とか。うーん。label:(a,b,c) {}; みたいな形で、parallel 代入を許すと言う -手もあるね。 - -こちらの方がCとの相性は良いが... main() { label:(){ ... } } -みたいなnestを許すかどうかと言う問題がある。 -変数の参照を許さなければ、特に問題はない。 - -a = label: は、二重の意味があるなぁ。 - -言語の名前。DinnerBell II とか? join も入れる? +若label:(a,b,c) {}; 帥綵≪сparallel 篁ｅャ荐宴荐 + + +＜鴻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 医ｃ紊у怨冴с +障医ャ臀荐馹 + + +return 眼уゆ? return(ID) -みたいな形でIDで判断する。そうすれば、return 側でID -を見て判断できる。けど... - -まぁ、はやり、環境を持って歩く方がいいかなぁ。でも、 -引き渡しているから、二つ引き渡して、片方を使われたときに、 -反対側が消えてしまうのはいたいよね。今のままならば、 -そういうことは起こらない。 - -continuation 特有の問題を避けるなら、このままでもいいんだが... -continuation や環境は、このシステムでは自分で作ることが -できるからね。 - -そうなんだけど.... retlabel や retcont は実はオブジェクト -全体に一つあれば良い。 - -引数を渡すときに、そこに環境へのポインタをいれてやれば良いので、 -解決は割と簡単だが、そうすると、例の構造体を引数で渡すと言う -問題を解決する必要がある。 - -でも、今の実装ならば、まったく同じ変数の構成ならばコピーは -実際には起こらないわけだから問題ないはず。特に、それを保証するために、 -interface を実装する必要がある。 +帥綵≪IDуゆ違return 眼ID +荀ゆс... + +障医ｃ罩鴻с +綣羝＜篋ゅ羝＜鴻篏帥 +絲上眼羔障篁障障違 +莎激 + +continuation 号馹帥障障с... +continuation 医激鴻ст +с + +.... retlabel retcont 絎吾с +篏筝ゃ域 + +綣違羝＜医吾ゃ潟帥域с +茹ｆ浦蚊膂≦箴罕篏綣違ф検荐 +馹茹ｆ浦綽荀 + +с篁絎茖違障ｃ紊違罕違潟若 +絎莎激馹鴻篆荐若 +interface 絎茖綽荀 return -> (void *)old bp return address -bp を直接操作できるようにするといいんだけど.... +bp 贋･篏с.... Sat Jan 8 08:49:59 JST 2000 -今は、code 内ではreturnできないわけだけど。実は、return って、 +篁code сreturnс絎return ｃ 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 で良いわけだが、 -このあたりは、言語外の問題で、それを明示的にしたいから、この言語を -作っているわけなのだから、これを内部で処理するのはおかしい。 +紊若喝冴絽違... +絎絽違ｃ + +return 筝с罸莠 + +馹destructor 羝＜宴＜self ц +荐茯紊馹с腓榊荐茯 +篏ｃу 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 を一緒に送るものを作ったほうがいいのかも。 +с＜ｃframe pointer 贋･篏 + + +goto 祉env 筝膩篏ｃ祉 goto (*ret)(),environment; -かな。type は? (void *)? +type ? (void *)? goto ret(),environment; -にはならないの? そうすれば、自分でthreadを制御できる。environment -の正当性を評価しなくて良いの? まぁ、ねぇ。 - -これは実装は容易だが... goto といちいち書くのが本当にいいのか? -env に対するoperationがあった方がいいなぁ。push とか? +? 違thread九勝сenvironment +罩ｅс荅箴＜? 障 + +絎茖絎号... goto ＜≧吾綵? +env 絲障operationｃ鴻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 茖ｃ鴻 + +絽吾 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 篆罩ｃ鴻с Sun Jan 9 08:49:43 JST 2000 -うーん、なんか修正が多いなぁ。あと、関数呼び出し、goto 文の -構造体への対応か。 +若篆罩ｃ紊∽医若喝冴goto +罕篏吾絲上 goto (*code)(); -が、self env を使うのか、code の先の値を使うのかを区別する -必要がある。もし*を使わないとするとlabel(FNAME)との区別が -つかないぞ。あ、でも、環境を持ち歩くことにしたから、label -へもjumpしようと思えばできるね。 - -並列送信はなくても、この構成ならばstatement単位の並列性を検出するのは -容易だろう。 - -やればできるけど、この修正の量だと1日じゃ終らないかなぁ。 -不動小数点も入れるのでしょう? +self env 篏帥code ゃ篏帥阪ャ +綽荀*篏帥label(FNAME)阪ャ +ゃс医≧label +吾jump違с + +筝篆＜罕statement篏筝с罎冴 +絎号 + +違с篆罩ｃ1ャ腟 +筝絨亥鴻ャс? Mon Jan 10 09:00:12 JST 2000 -引数に構造体を許すには、必ずANSI-Cにする必要がある。難しくは -ないが... - -goto 文には label, code, continuation の3つが来る。 +綣違罕篏荐宴綽ANSI-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 +演冴? 鴻膂≦膂≦ｃ＜号 +鴻? 若 + +return ∽遺絖с鴻 +筝ゃpop 馹ц... + +ret env絎祉leave 綽荀 +ｃpush %ebp 後lea -disp(%ebp),%sp +фｻjump function箴絖 + + +с羆read only絮сhardware supportс違 + +sched_yeilds() 後吾? lock ? + +筝綽сｃ宴羆 Wed Jan 12 16:12:27 JST 2000 -あは。ANSI prototype はめんどい。 +ANSI prototype bexpr() -で、関数での引数の順序と、そのあとの宣言の順序が変わることがある。 -そうすると、うしろの方が優先されてしまう。これは、こまる。 - -そうか、code_arg_offset のような方法だと、ANSI style では、 -困ってしまう。 +с∽違с綣違綺絎ｈ綺紊 +鴻障障 + +code_arg_offset 号ANSI style с +違ｃ障 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 篏 + +祉鴻帥腟罕若帥 +潟若с... + +ｃｃ臀continuation吾с帥 +с + +潟若с違environment/return 腟 +吾с帥ｃ 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 с馹茹ｆ浦障list2 localheap +蚊綵ｃ + +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 を畳む。 +帥? ∽違篁ｅャ荀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; +... + +ｃ宴翫潟弱main2綣羝＜帥 void f1(struct aa *ret) { *ret = bb ; return; } -と同じか。これは簡単。 +膂≦ f1().a[55] -みたいな場合は、局所変数に強制的に取ってしまうみたいね。それはそうだ... -が、うちの実装だとちょっと厳しいか。 +帥翫絮紊違綣桁句ｃ障帥... +＜絎茖＜ｃｳ 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羝＜荐羈篏帥... + +∽医若喝冴ｃ違сс? 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 с +сｃenter 緇с鴻 Mon Jan 20 18:25:27 JST 2003 -3年間さわってないのかよ。何やってんだ? - -goto 文のバグをとらないといけない。 - -まず、関数引数の構造体の展開。これは、どうってことないはず。 +3綛顔ｃ篏ｃ? + +goto 違 + +障∽医違罕篏絮ｃ goto (*code)(i+1,j,...) -まず、いじらなくてすむ変数を摘出する。 +障紊違冴 foreach arg compare -単純演算 ( op+const , pointer , const assign ) などは、ここで検出する。 -大半は、そのようになるはず。 -レジスタに乗せる分があるから... それには触らないとして... - -複雑なものは、前もって計算しておく。(get_register する) -スタック上かレジスタ上に作る。 - -残りは並列代入となる。再帰的に計算する。 - -えーと、大きな順にやるんだっけ? 小さな順にやるんだっけ? +膣羲膊 ( op+const , pointer , const assign ) ф冴 +紊у +吾鴻帥箙... 茹... + +茲ｃ荐膊(get_register ) +鴻帥筝吾鴻推篏 + +罧筝篁ｅャ絽亥荐膊 + +若紊сｃ? 絨ｃ? 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を代入。 +帥ゃ + + 腱糸筝ゆ冴 + 腱糸綽荀腱糸(絽) + 篁ｅャ + +с? 若? 若 +get_register + +箴 + + g(b,c,a) b + b篁ｅャ潟若冴a 紕 + a 綽荀茯帥鴻綣違鴻荀違 + a 腱糸a 腱糸荀 + 腥冴違腱糸Okc + с c 荀 b с若с + b get_register + сc 腱糸ссa腱糸ｃb篁ｅャ Tue Jan 21 22:45:09 JST 2003 -とりあえず、jump は複雑すぎる。もっと簡単にすることを考える。 -parser 側である程度処理できない? +jump 茲ｃ膂≦ +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) (с) +∽違綣違鴻菴篁∞с膣紊 +障ц純 + +障≫筝紊違ｃ +帥 + +潟若紊 +ｃ Wed Jan 22 14:33:12 JST 2003 -やっぱり、途中で局所変数を増やしたいよね。 +ｃ宴筝у紊違紜 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 篁ｅ 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 を工夫する必要はあるが。置き換えスタックが必要。 +ｃ眼... + +use_pointer ｃ? eax,ebx 帥 +ｃ + +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 紊у紊違ｃ純＜ +? (眼荐吟...) +struct 罸 field offset/type 腟違 + +帥亥＜罕篏鴻篁綽荀 +罕篏帥医 +筝綽鴻ゃ篏帥綽荀ｃс +≧＞散ｃ紊у紊医羆眼 +ｃ + +＜ｃ.ｃ若х脂蚊障? +緇у冴ャ羂障... + +def х脂蚊nptrdisp篁ｅャ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 潟 + +＜吟違若 + +若帥若若帥若≪ +障ｃ 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 臀莎激ｃc +臀g 紮障腟ｃ綽荀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") -みたいな感じ? - -やっぱり関数解析でマクロ処理をやらせるのは無理かな? 先読みされちゃうし。 +帥? + +ｃ宴∽域Вс∞? 茯帥＜ Sat Feb 8 00:53:52 JST 2003 -macro は途中まで書きました。置き換えをマクロが呼び出された -時点で cheap に置くと、それを解消するタイミングがない。 -ここだけmallocしても良いが.. - -chptrsave はlistにする必要がある。list で良い。 - -やっぱりmacro levelを見て、自分と一致したassoc valueまで -手繰って置換するんでしょう。そうすれば、置き換える必要は無い。 -ということは、local_define にmflagsを格納する必要がある。 +macro 筝障ф吾障臀若喝冴 +鴻 cheap 臀茹ｆ帥ゃ潟違 +malloc.. + +chptrsave list綽荀list ц + +ｃ宴macro level荀筝眼assoc value障 +膵違ｃ臀с違臀綽荀＜ +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 罧ｃ吾菴 +吾sc 翫障ｃlocal macro +local table 羆ｃｃ +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 となる。 +ｃ 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 +(ゃ障筝ゅ) +臀腟ｃlevel祉 + +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ユ祁ｃ int save = chptrsave; -で、chptrsave が、$chptrsave になってしまう。 +сchptrsave $chptrsave ｃ障 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) -むぅ。これ、うまくいかないんじゃん。こまったなぁ。 +障障ｃ #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 のように -作ればいいはずなんだけど。 +ｃ＜泣若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菴綣違ｃ +腥ссゃ潟若障с +鴻帥х舟障 + +function call 綣違с + +type -1 heap綣違羞桁ゃ.. +ｃ宴障? + +temporal struct сdisp紊眼с +違鋎紊с違鋎祉潟 +(絽違ｃャゃ吾ゃ潟帥篏帥 +.... ャ祉ゃ荳贋･ return +吟) + +腟絮弱阪眼с腆坂綣羝＜障号 +篁ｅャ篋綺潟若綽荀 + +register 篏睡絎creg/dreg +ゃ荐吟綽荀 Wed Feb 12 11:09:22 JST 2003 -それだけどさ... やっぱりアドホックに実現するのは難しいんじゃないの? - -まぁねぇ。register の場所の確保と、寿命は別だから、それで -いいんだけど、regs flag だけでなんとかならないのかな。 -こういう変更ははまるが虚しい。 +... ｃ宴≪絎憗ｃ? + +障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 筝с +篆罩ｃ鴻 + +fix 綣違鴻絖! + +varargs 絎茖... + +rvalue(expr(),type) сexpr() typervalue綣羝＜ +сtype 紊у紊違rvalue違帥ゃу +喝冴type紊眼綽荀rvaluetype +障ｃсrvalue(int e,int type) +鴻腆冴... + +struct_push register宴茲ｃ +膂≦? Sun Feb 16 07:58:23 JST 2003 -代入しなくて良いからと言って、ソース -のリストから除いては、上書きを防げない。 +篁ｅャ荐ｃ純若 +鴻ゃ筝吾蚊 Sun Feb 16 22:55:58 JST 2003 -vdisp ってなんだったんだ? +vdisp ｃｃ? Mon Feb 17 12:35:39 JST 2003 -並列代入は出来たみたい。代入は小さいものを先にすべきなのか? -まぁ、できりゃいいんだけど、横に避けるものが大きいのはいや -だよね。 +筝篁ｅャ堺ャ帥篁ｅャ絨鴻? +障с罔帥紊с + 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してないという保証がない。 +ｃｃ 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 は、あんまり良いアイデアではないみたい。取るか。。。 +ｃ宴 library т違 +CbC only т + +conv 障≪ゃ≪с帥 Thu May 13 12:59:16 JST 2004 -byte code interpreter を CbC 自身で書いたら? - -それでもやっぱり動かないから、あんまり意味はないんだけど... - -C で書いてもいいか。 +byte code interpreter CbC 荳ф吾? + +сｃ宴障潟... + +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 絎茖ｃ + +ｃ宴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 菴 +(障...) + +ｃ絎function call純? +紊桁違翫障ｃgcc (篋絎絎茖) +C-- paraterized goto 障ｃ | 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 馹 + +｡ｃ吟fp 腱糸違 +絆ｃ篁parse tree 篏ｃcode +純с + +сс +с + +違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 +＜ｃ障鴻ARM翫ｃ宴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 を下にしてあるんだろうな。 +帥с? 緇鴻吟 + +ｃ宴max_interface 馹ｃ宴с +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(...); сｃfp 祉? ... 篏臀с + 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 激с潟ｃ鴻 + +篏紊眼絨羝帥(祉?) + +g ... 篏臀ｃャ綽潟若膵 + __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с≪祉拷ｃmax_interface +篏ｃ(1024腮綺?) ｃ宴 fp +с + +fp 腥翫祉翫阪ャ? 腟罕緇絋 + goto 眼絎臂 ...()ャ祉 + goto 眼絎臂 ...絎綣違緇ャ腥 +с? + +＜ｃSemantics 茲純 +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 の宣言の方が綺麗なのか... +с? ... с荐絎 +ｃ + +K&R style 絎ｈ鴻膓咲... 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 では、同じ部分を前もって探した -方が効率がよいわけか。(どうせ、やっていることだが) +腆冴絎ｈ +с綣違筝罧級障с +сс + + +茫馹帥 + + stack 篁 + 茵 + +ｃ馹? + +parallel assignment сｃ｢ +鴻合(ｃ) Sun Nov 26 23:22:12 JST 2006 -fp のsave は必要。何故かと言うと、 +fp save 綽荀篏荐 goto f(a,b,...) -で、後ろの部分がどれだけあるかは、間接的な引数での -宣言ではわからないから。 - -stack 上に全部 interface があるなら、良いが、 -部分は register に乗っている。 +с緇･綣違с +絎ｈс + +stack 筝 interface + register 箙ｃ goto f(a,b,c,...) -としたときに、... の一部はregisterに乗っている。どれだけ -乗っているのかを知る必要があるが、それをfpから推察する -ことはできない。浮動小数点とかの異なる型が散在している -から。 - -... で引き渡す引数は、メモリに乗っている必要がある。 -型が明解なら、レジスタ上でもだいじょぶなはずだが。 - -明示的な引数に大域的には変換できるはずだけど、open -な環境では、それはできない。 - -だとすれば、 +... 筝register箙ｃ +箙ｃャ綽荀fpｨ絲 +с羌絨亥鴻違ｅ + + +... у羝＜綣違＜≪箙ｃ綽荀 +茹ｃ吾鴻推с吟 + +腓榊綣違紊у紊сopen +医сс + +違 __code f(int a, int b : int h, ...) { ... goto g(a,b,c : d,e,f,...) } -みたいな形で、stack 上に乗せる引数を明示する必要がある。 - -これは、なんなの? - - : の前の引数は可変に出来ない - : の後までは可変に出来る - -っていうことか。 - -構造体は、メモリ上に取るとしても.. - -まぁ、... のところまでレジスタで、それ以降は、メモリでも -十分だけどね。いずれにせよ、複雑すぎることは確か。 +帥綵≪сstack 筝箙綣違腓冴綽荀 + +? + + : 綣違紊堺ャ + : 緇障с紊堺ャ + +ｃ + +罕篏＜≪筝.. + +障... 障с吾鴻帥с篁ラ＜≪с +茲腆冴 __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 吾鴻帥箙ｃャ +箙ｃ＜＜с紊腓冴綽荀 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 綵≪ャ +絎ｈ __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) +ャｃ鏆荀綏с +ゆсg 眼уｃ純 +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 帥 + +ｃsyntax Wed Jul 25 14:48:16 JST 2007 -inline code __goto みたいな形にすると、 +inline code __goto 帥綵≪ __goto hoge(); -goto を reflection 出来る。 - -meta な、interface はどうするの? - -デフォルトで、,.... が入っていると思う方が良い。 +goto reflection 堺ャ + +meta interface ? + +с,.... ャｃ鴻 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 茵絎ｈゃscript хcompiler +茹ｆ浦鴻 + +tcc 鴻 goto f(); сgoto (*f)(); +綣桁吟ｃ + + ... ｃ紊у紊違帥? stack scope +сsub routine с? + + + + + + + + + +