Mercurial > hg > CbC > old > device
changeset 325:b51b87ddf60c
*** empty log message ***
| author | kono |
|---|---|
| date | Sat, 19 Jun 2004 21:45:19 +0900 |
| parents | 575481408653 |
| children | e5d40f8c4cce |
| files | Changes |
| diffstat | 1 files changed, 72 insertions(+), 64 deletions(-) [+] |
line wrap: on
line diff
--- a/Changes Sat Jun 19 20:05:58 2004 +0900 +++ b/Changes Sat Jun 19 21:45:19 2004 +0900 @@ -38,7 +38,7 @@ fp->local1 みたいなことだけするなら、C と同じになる。 -call する時のarguemnt も、 +call する時のargument も、 static な func_state に置く stack 上の func_state に置く という二通りの選択肢がある。Cと互換なら、当然、後者。 @@ -108,7 +108,7 @@ union の拡張もあわせて議論すると... -Partial evalutator をセマンティクスや実行系にいれておくことは可能か? +Partial evaluator をセマンティクスや実行系にいれておくことは可能か? byte code とか仮想マシンだったら可能。そうでない場合は? @@ -152,7 +152,7 @@ で、構造体に register storage を許す。 func( - static struct argment { + static struct argument { register void *stack; register void *continuation; } @@ -168,7 +168,7 @@ すると、caller の方も、構造体を引数とするのが自然。 call caller( - static struct argment { + static struct argument { register void *stack; register void *continuation; } arg = {a,b}; @@ -189,8 +189,8 @@ function には、interface と code と state があることになる。 -state にアクセスする時のlockは? protected state? synchonized state かな? -もちろん、sequential implementatoinでは、そんなものはいらない。 +state にアクセスする時のlockは? protected state? synchronized state かな? +もちろん、sequential implementationでは、そんなものはいらない。 function { interface: @@ -205,15 +205,15 @@ int にvoid value を定義する。実装は重くなるけど... -serialzed の semantics は? +serialized の semantics は? もう少しmicro-Cに近く! -carring state と static state。 +carrying state と static state。 Mon Dec 13 19:42:41 JST 1999 -interface に regsiter keyword を使うのは、あまりに +interface に register keyword を使うのは、あまりに 実装よりすぎる。でも、でないと状態にできない? そんなことはないか。やっぱりcaller側のstatic 領域に 直接書き込む? @@ -223,8 +223,8 @@ Wed Dec 15 14:09:49 JST 1999 C と互換にする? - goto function(argments); - goto *continuation(argments); + goto function(arguments); + goto *continuation(arguments); みたいな感じで。 stackの管理は? どうせ、library との互換はとらないと @@ -235,8 +235,8 @@ return した時の挙動が複雑になる。大域returnするわけだら。 -argments をstatic 領域にかきこむ方式だと互換性がとれない。 -stack 上の frmae pointer 上にないとダメだから。 +arguments をstatic 領域にかきこむ方式だと互換性がとれない。 +stack 上の frame pointer 上にないとダメだから。 両立させるのは無理か? つまり、これだと、呼び出された方の frame semantics は、C と互換になる。だから、stackの直後に @@ -246,7 +246,7 @@ つまり、それはだめだったことじゃない? つまり、goto だと、 frame pointer は、stack の直後とは限らないから。前の -frmae pointer 相対に引数にアクセスしてくれれば別だけどね。 +frame pointer 相対に引数にアクセスしてくれれば別だけどね。 stack に引数を積むのは容認して、goto の場合は、向こう側で stack を畳むってのは? ということは、普通の関数と定義の @@ -256,7 +256,7 @@ 方が異なることをする。それは、なんかおかしいな。それに、 それだと関数呼び出しが軽くならない... -ということは、やはり、C のcall は、call funciton で +ということは、やはり、C のcall は、call function で 実現して、その他の呼び出しは、すべて、goto 扱いに する方が正しいだろう。 @@ -293,7 +293,7 @@ あ、これは良いかも知れない。code が複数かけるから。 -state 以外は、consitent state であることを保証しない。ってのは? +state 以外は、consistent state であることを保証しない。ってのは? local 変数は使っても良いけど、call/goto の前後で、値を保証しないか... うーん、だんだん炸裂してるなぁ。 @@ -333,7 +333,7 @@ # register save # set 1st argument in register %eax # set 2nd argument in register %ecx - # set extra aguments in save area + # set extra arguments in save area # set extra argument pointer in %edx jmp function という形式になるわけね。second を処理するのはめんどくさいから一つ @@ -341,11 +341,11 @@ えーと、frame pointer はないけど、コンパイルの手順からすると あった方が良い。しかし、frame pointer そのものをstatic -にとるのはまずい。だから、frame pointer がfirst argment +にとるのはまずい。だから、frame pointer がfirst argument ということにする方が正しい。とすると引数は、さらに、その 後と言うわけか。 - f(fp,argment) -fp を渡すのにさらにargment をレジスタで渡すのはおかしい。おかしいけど、 + f(fp,argument) +fp を渡すのにさらにargument をレジスタで渡すのはおかしい。おかしいけど、 ま、良いか。 return しないなら、return type の定義をとるのは変だな。 @@ -382,7 +382,7 @@ goto name(arg); } -ぐらいかな? で、first argment が必ずregisterにのるようにしないと +ぐらいかな? で、first argument が必ずregisterにのるようにしないと いけない。register storage class を入れて、 register "%ebp" void *arg とかするわけね。 @@ -471,7 +471,7 @@ Sat Jan 1 22:40:22 JST 2000 -とーにかく、 storage class regisgter を実装しよう。 +とーにかく、 storage class register を実装しよう。 stmode=REGISTER @@ -481,12 +481,12 @@ symbol table に storage class をたせば? dsp==EXTRN で判定しているから、 local 変数が36以上あるとおかしくなるぞ? -sc は GVAR/LVAR だけど、regsiter は LVAR の特殊な奴だから、 +sc は GVAR/LVAR だけど、register は LVAR の特殊な奴だから、 sc に入れるほうが正しいか... Sun Jan 2 01:47:17 JST 2000 -register 変数はできました。けど、regsiter を二つ使うと、 +register 変数はできました。けど、register を二つ使うと、 一杯になってしまうので、REGISTER6 でコンパイルしないと 結構ひどい。が、register 変数を%esi,%edi に割り当てれば いいか。 @@ -565,7 +565,7 @@ うーん、なんかレジスタにつむ順序が違う これは、adecl がreverseにつむから。 -code のretrun +code のreturn やはりcodeはtypeにしないとだめ。 @@ -625,12 +625,12 @@ かな? call/cc ? label へのgotoを許すのもいいけど、 -でも、label を許すと、すごくspagettyにならない? +でも、label を許すと、すごくspaghettiにならない? Tue Jan 4 11:47:24 JST 2000 -contiunation じゃなくて、return keyword を使おう。 +continuation じゃなくて、return keyword を使おう。 (実際、continuation と少し違うし) type が少し変になるけど、まあ良い。 @@ -650,7 +650,7 @@ Tue Jan 4 12:21:44 JST 2000 これだとmethodがすべてstatic になってしまう。dynamic なmethod -呼び出しにするには? dipatcher を自分で作ることになる。かなり +呼び出しにするには? dispatcher を自分で作ることになる。かなり めんどくさいが... code method(obj,arg) @@ -662,7 +662,7 @@ Tue Jan 4 14:22:19 JST 2000 -main の変数を書き潰すのと、gotgo (*reg)(123) での値は、 +main の変数を書き潰すのと、goto (*reg)(123) での値は、 register 渡しで、current register にのらないので、 結局、return label は専用に作る必要がある。 @@ -759,7 +759,7 @@ あとは、 ANSI-C prototype ANSI-C prototype check - Interface Definietion + Interface Definition GC support Direct handling of Frame だね。簡単に出来そう? たぶん... @@ -796,7 +796,7 @@ あるね。 そうじゃなくて、return 側で判断するか? - retrun(ID) + return(ID) みたいな形でIDで判断する。そうすれば、return 側でID を見て判断できる。けど... @@ -806,7 +806,7 @@ そういうことは起こらない。 continuation 特有の問題を避けるなら、このままでもいいんだが... -contrinuation や環境は、このシステムでは自分で作ることが +continuation や環境は、このシステムでは自分で作ることが できるからね。 そうなんだけど.... retlabel や retcont は実はオブジェクト @@ -1020,7 +1020,7 @@ でも、汚いなぁ。read only属性をhardware supportできればなあ。 -sched_yeilds() 相当を書けるかな? lock は? +sched_yields() 相当を書けるかな? lock は? 一応、できたけど、やっぱり汚い。 @@ -1059,7 +1059,7 @@ Thu Jan 13 13:38:24 JST 2000 だいたいできたけど、test/tmp7.c のprintf のtype mismatch は -なんなんだろう? ASNI の副作用だろうなぁ。 +なんなんだろう? ANSI の副作用だろうなぁ。 これだと、プロセスの切替えのときには、結構な量のデータを コピーすることになる。それでもいいんだけど... @@ -1191,7 +1191,7 @@ 38 0044 3000BD27 j $31 39 .end main -これと同じようにするならば、regiterの使用数を最初に調べる必要が +これと同じようにするならば、registerの使用数を最初に調べる必要が あるのだけど、one path compiler である micro-C では、それは できない。したがって、enter は後ろでする方が良い。 @@ -1354,7 +1354,7 @@ Thu Feb 6 11:47:03 JST 2003 -Code Segement を単位として使うときに、大域変数はどういう +Code Segment を単位として使うときに、大域変数はどういう ように分けるの? static なんかは意味ないよね。 もちろん、自然にグループ分けされるわけだけど。 @@ -1508,7 +1508,7 @@ type に -1 とheapの引数が混在しているやつだけど.. やっぱまずいんじゃないか? -temproal struct は再利用できるんだけど、dispの変更ができないので +temporal struct は再利用できるんだけど、dispの変更ができないので 新しく作るしかない。大きいときだけ新しく作るなんていうセコイ 技はあるけど。(そうすると、帰って来た値へのポインタを使えなく なるが.... 別にいいよね。戻り値それ自身を直接 return する @@ -1585,7 +1585,7 @@ Tue Feb 18 11:56:10 JST 2003 -overraped 用の emit_copy +overlapped 用の emit_copy float/double long long @@ -1609,11 +1609,11 @@ って、きっと return 文がないと、文句を 言われるよね。むむむ。 -post processing する時にoverrapしてないという保証がない。 +post processing する時にoverlapしてないという保証がない。 Wed Feb 19 15:38:55 JST 2003 -自分自身とのoverrrapを見てないので、 +自分自身とのoverlapを見てないので、 struct a a,int i int i,struct a a みたいな時に自分自身を壊してしまう。なので、emit_copy @@ -1847,7 +1847,7 @@ Mon Mar 3 12:38:08 JST 2003 -float/duble は順調に進んでるけど、3日はかかるでしょう。 +float/double は順調に進んでるけど、3日はかかるでしょう。 binop を書いちゃうとmc-parse.c は、ほとんど終り?! 代入と関数呼び出しが残っているか。あと single もあるね。 @@ -1898,7 +1898,7 @@ 困らないか? ほとんどの場合でだいじょうぶだが、だめだった 時にerrorぐらい出せば? でも実行時にしかわからないか... -I2D でさ、singned/unsigned の区別がいるね。 +I2D でさ、signed/unsigned の区別がいるね。 やっぱり FCONST いるんじゃないの? @@ -1932,7 +1932,7 @@ i = i+1; なんてのでも、ひどい目にあってしまう。 -local variable も最初に move mutilple register で大半は +local variable も最初に move multiple register で大半は レジスタに読み込んじゃうみたいね。pointer で参照されると 困るんでしょうけど。まぁ、31個もあれば、そういうことを してもあまり問題ないのかも知れないけど。 @@ -2185,7 +2185,7 @@ やぁ... まぁ.... バグだらけだな。 -function call のレジスタの処理がでたらめ。RISCの場合は、parallel_assing +function call のレジスタの処理がでたらめ。RISCの場合は、parallel_assign した方がいいんじゃないか? Sun Mar 16 20:59:10 JST 2003 @@ -2538,7 +2538,7 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -なので、r1/r30 を常に移動させる必要がある。前のcode segement/ +なので、r1/r30 を常に移動させる必要がある。前のcode segment/ function がどこにr1/r30を持っていたかを知る手段はないので、 jump する前に糢とに戻す必要がある。r30が固定ならばr1のみの 修正で良く、前に戻す必要はない。 @@ -2559,8 +2559,8 @@ reg_save disp max_func_args*size_of_int lvar>0 lvar<0 lvar>0x1000 0000 -というわけなので、* にそろえる方が intel 版とも一致する。 -ってことは、ebp の移動は intel でもやっていたってこと? +というわけなので、* にそろえる方が Intel 版とも一致する。 +ってことは、ebp の移動は Intel でもやっていたってこと? いやfunctionではこうなっているんだけど、code では違う。 @@ -2583,7 +2583,7 @@ の#にr30を固定してr1をずらすことになる。やっぱ、こっちだよね。 zz はから。xx に、base となる関数呼び出しが来る。から、 -calle arg は破壊される。 +callee arg は破壊される。 どっちも可能だな。両方実装する? やっぱり後者からかな。gcc は 前者の方が簡単だろう。 @@ -2622,7 +2622,7 @@ これだと environment は持ち運ぶ必要はない? いや、ある? 逆に戻り番地を持ち運ぶ必要はなくなるわけね。そっちの -方がきれいかな。goto-cotinuation みたいな感じか。 +方がきれいかな。goto-continuation みたいな感じか。 返り側は、 @@ -2695,12 +2695,12 @@ 戻って来ないから。register を使ったことにするには、used_max_register_var を設定してやれば良い。 -Interl版で goto が動かなくなったのは、arg_offset が、register 変数分 +Intel版で goto が動かなくなったのは、arg_offset が、register 変数分 も取るようになったから。save することを考えると、その方が良い。実際、 function call があるとsaveされてしまう。ということは、別に r20-r29 である必要はないってことか。通常のinput register varで良い。とすると、 register変数をsaveする必要もないね。 -ただ、input regsiter var は、function callの前には saveする必要が +ただ、input register var は、function callの前には saveする必要が ある。でも、これは、やっぱり手遅れか。ってことは、やっぱり、 r20-r29が良いってことか。 @@ -2770,7 +2770,7 @@ .include を使うと良いらしい。(そんなんでいいのか?!) -csvalue() で取って来たregiserを誰がfreeするの? +csvalue() で取って来たregisterを誰がfreeするの? Tue Apr 8 14:52:06 JST 2003 @@ -3208,7 +3208,7 @@ C から変換したコードは動いたけど。まぁ、cast は動くのは 良いんだけど、こういうのじゃなくて、link を使った変換 -でもいいんじゃない? そうすれば、spagety stack でもOk +でもいいんじゃない? そうすれば、spaghetti stack でもOk だな。ただ、GC がないと使い物にならないだろうが。 Link にすれば、型整合のある変換も可能だよね。ただ、union @@ -3651,10 +3651,10 @@ 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 のregistger +ふむ。(?::)+(?::) みたいな時には、code-set-fixed-register のregister が二ついるわけね。push できないの? - case COND: /* a?0:1 should consider non-brach instruction */ + case COND: /* a?0:1 should consider non-branch instruction */ case DCOND: case FCOND: d = (car(e1)==COND?INT:car(e1)==DCOND?DOUBLE:FLOAT); @@ -3682,7 +3682,7 @@ ということになっているみたい。おんなじ順序じゃないのね。どうしようかな。 これは、わかりました。 - case COND: /* a?0:1 should consider non-brach instruction */ + case COND: /* a?0:1 should consider non-branch instruction */ case DCOND: case FCOND: d = (car(e1)==COND?INT:car(e1)==DCOND?DOUBLE:FLOAT); @@ -3752,7 +3752,7 @@ (本気? どれくらいかかる? 2-3日かなぁ...) (実際には半年かかった...) -getsym の数字の扱いはunsingedでするべきだよね。 +getsym の数字の扱いはunsignedでするべきだよね。 で、- があった時にoverflow を検出するのが良いよな。 あと、strol とかのoverflowの検出をさぼってるな。 @@ -3832,7 +3832,7 @@ stack は、 system wide に一つ ( classical environment) - code に一つ ( fortran type ) + code に一つ ( Fortran type ) object に一つ (like message buffer in ABCL) っていう選択もあるね。 @@ -3842,7 +3842,7 @@ shift/reset をCで実装するのは簡単だが... reset{ - shfit(); + shift(); } みたいな感じ? @@ -3866,7 +3866,7 @@ 間違えて3日分消しちゃったい。 -int でも RLVAR とかの unsigned/singned の区別がないとまずいよね。 +int でも RLVAR とかの unsigned/signed の区別がないとまずいよね。 包括的なテストルーチンがあった方が便利。long.c を消しちゃったし。 @@ -4052,7 +4052,7 @@ 構造体の戻値を持つ場合に、引数がないとうまくいかない。 -#include "" は、今読んでいるファイルのcurrent directry も探す。 +#include "" は、今読んでいるファイルのcurrent directory も探す。 まぁ、ia32 は、eax,edx にlong,long を積んで、あとは、 対メモリで計算するわけね。そうだろうな。むしろ、 @@ -4175,7 +4175,7 @@ cploat $25 の $25 は、stack offset みたいね。$sp を変更するときに、 なんかのフラグを壊さないようにするための処理みたい。 -だとすれば、code segement 側でstackを頻繁に移動するのはまずい? +だとすれば、code segment 側でstackを頻繁に移動するのはまずい? float/double のフローは mc-parse では、少し、齟齬があるみたい。 @@ -4456,7 +4456,7 @@ slt $r1,$r2,12 みたいなコードも出したいが... -parallel_rassign って target=soruce で無限ループしない? +parallel_rassign って target=source で無限ループしない? Sun May 23 21:21:22 JST 2004 @@ -5005,7 +5005,7 @@ builtin_expect かぁ。 -bit filed が少しある見たい。 +bit field が少しある見たい。 結局、全部、実装しないとだめか。 q = (struct spin_lock) { }; @@ -5028,3 +5028,11 @@ bit field 実装したくないよ〜 まぁ、構造体の代入と同じような形にすれば良いわけだけど。 + +bit field の初期化ってのもあるのか。(うげ〜) + +うーん、やっぱ、果てないな。 + ASSOP, PREINC, POSTINC.... +まぁ、 + BASSOP, BPREINC, BPOSTINC.... +でもいいんだけど。