CbC/old/device: Idea comparison

comparison Idea @ 0:d35df41eac69

Initial revision

author	kono
date	Thu, 13 Jan 2000 02:41:41 +0900
parents
children	bf602558130d

comparison

equal deleted inserted replaced

--1:000000000000
+:d35df41eac69
+Thu Nov 25 17:27:12 JST 1999
+subroutine call がない
+局所変数もない
+その代わり、大域変数を多用する
+大域変数のスコープは局所的
+Fortran の用に局所変数は静的に取る
+recursion する時には、自分で保存する
+subroutine call時のレジスタのセーブも局所的に行う
+それは、ちょっと変じゃない?
+やっぱりデフォルトのフレームは持ち歩くか?
+recursive call とそうでないのを区別するか?
+fp は用意する方が良い
+関数定義と同時に、それ専用のfpの構造体を用意する
+C をcompileする時には、stackを持ち歩く
+fp = (struct func_state *)stack
+えっと、どこに代入するの? そういう問題もあるわけね。
+じゃあ、fpは特別? それは気に入らないな。static
+なfpにすれば良いわけね。
+func(void *stack) {
+static struct func_state {
+	static struct func_state *fp;
+	int local1;
+	brahbrah...
+} func_state;     // ここまで hidden
+func_state.fp = (stack -= sizeof(struct func_state));
+}
+func_state をとってくる演算子があった方が良い? そうね。
+func.state
+ぐらい?
+fp->local1 みたいなことだけするなら、C と同じになる。
+call する時のarguemnt も、
+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 からのコンパイラも書かないといけないのか...
+Mon Dec 13 18:53:04 JST 1999
+compiler based で、内部で partial evaluation できる?
+func をdatabaseとして扱えないなら、それはできない。
+しかし、状態遷移としては取り扱える。
+func.state
+func.code
+みたいな形にしてpartial evaluationすれば良い
+でも止まるのか?
+textual でない、中間的なコード表現があった方が良い? <-> interpreter?
+Prolog ではなんでいけないの? --> Unification が重いから
+Sat Nov 27 13:50:41 JST 1999
+func.state とか作るのだったら、
+struct {
+	struct {
+	    int i;
+	} state;
+	state *code = {
+	    i = i+1;
+	};
+} name;
+みたいな形で、それ自体を構造化すれば? で、代入すると部分評価される。
+代入も可能。なるほど。
+	*name.code;
+値はあるわけ? 値は &state でしょうね。
+self があれば、
+struct {
+	struct {
+	    int i;
+	} state,
+	*code = {
+	    self->i = self->i+1;
+	};
+} name;
+かな。self = state だよね。
+union の拡張もあわせて議論すると...
+Partial evalutator をセマンティクスや実行系にいれておくことは可能か?
+byte code とか仮想マシンだったら可能。そうでない場合は?
+いずれにせよ、構造体のタグのunique性を修正しないとだめだな。
+ヘッダファイルはどうするの?
+Mon Dec 13 18:53:18 JST 1999
+library との整合性は?
+exec sequence では、
+(--(struct func_state *)stack) = fp;
+call callee(&fp->arg);
+という形でpointerだけ渡すの? それは変だよね。
+値渡しにするとすれば、複数の値を渡せたほうが良い。
+func(void *stack) {
+	static struct func_state {
+	    static struct func_state *fp;
+	    int local1;
+	    brahbrah...
+	} func_state;     // ここまで hidden
+	func_state.fp = (stack -= sizeof(struct func_state));
+}
+の引数自体が、構造体であるべき。
+func(
+	struct void *stack
+	) {
+	static struct func_state {
+	    static struct func_state *fp;
+	    int local1;
+	    brahbrah...
+	} func_state;     // ここまで hidden
+	func_state.fp = (stack -= sizeof(struct func_state));
+}
+で、構造体に register storage を許す。
+func(
+	static struct argment {
+	    register void *stack;
+	    register void *continuation;
+	}
+	) {
+	static struct func_state {
+	    static struct func_state *fp;
+	    int local1;
+	    brahbrah...
+	} func_state;     // ここまで hidden
+	func_state.fp = (stack -= sizeof(struct func_state));
+}
+すると、caller の方も、構造体を引数とするのが自然。
+call caller(
+	static struct argment {
+	    register void *stack;
+	    register void *continuation;
+	} arg = {a,b};
+)
+みたいな。もちろん、この構造体はインタフェースと呼ばれる。
+argument は、callee にあった方が良いけど、caller 側にあっても
+良い。register なんかは、そう。
+	caller(interface caller_arg = {a,b,c})
+みたいなsyntax かな。
+	caller->interface = {a,b,c};
+	*caller->code;
+を、
+	caller(a,b,c);
+と称する。
+function には、interface と code と state があることになる。
+state にアクセスする時のlockは? protected state? synchonized state かな?
+もちろん、sequential implementatoinでは、そんなものはいらない。
+function {
+interface:
+	register int a;
+	register struct self self;
+state:
+	int b;
+	serialized int c;
+code:
+	b  = a;
+}
+int にvoid value を定義する。実装は重くなるけど...
+serialzed の semantics は?
+もう少しmicro-Cに近く!
+carring state と static state。
+Mon Dec 13 19:42:41 JST 1999
+interface に regsiter keyword を使うのは、あまりに
+実装よりすぎる。でも、でないと状態にできない?
+そんなことはないか。やっぱりcaller側のstatic 領域に
+直接書き込む?
+だとCより遅そう。でも、引数に40個とかかかれたら...
+Wed Dec 15 14:09:49 JST 1999
+C と互換にする?
+	goto function(argments);
+	goto *continuation(argments);
+みたいな感じで。
+stackの管理は? どうせ、library との互換はとらないと
+いけないんだから...
+local 変数がある場合は stack を動かす。でも、戻す奴がいない。
+closure 化するか?
+return した時の挙動が複雑になる。大域returnするわけだら。
+argments をstatic 領域にかきこむ方式だと互換性がとれない。
+stack 上の frmae pointer 上にないとダメだから。
+両立させるのは無理か? つまり、これだと、呼び出された方の
+frame semantics は、C と互換になる。だから、stackの直後に
+frame pointer があると思っている (そうか? ) frame pointer
+stack pointer に沿って移動した直後に、そこからのoffset
+で引数を操作することになる。
+つまり、それはだめだったことじゃない? つまり、goto だと、
+frame pointer は、stack の直後とは限らないから。前の
+frmae pointer 相対に引数にアクセスしてくれれば別だけどね。
+stack に引数を積むのは容認して、goto の場合は、向こう側で
+stack を畳むってのは?  ということは、普通の関数と定義の
+方法を変えるってことか。ま、悪くはないか。
+すると、goto のsemantics は、C と互換になる。それを受ける
+方が異なることをする。それは、なんかおかしいな。それに、
+それだと関数呼び出しが軽くならない...
+ということは、やはり、C のcall は、call funciton で
+実現して、その他の呼び出しは、すべて、goto 扱いに
+する方が正しいだろう。
+問題は、この言語の関数をcallされた時だな。dual entry にして、
+call の時と、goto の時を区別するか。
+	func:	stack processing
+	func_goto: normal processing
+...
+みたいな感じ。でも、return はないから...
+このあたりも自分で記述できる言語であるべきだよね。その通り。
+つまり、C とのstub も自分で記述すると言うことか。
+protocol function {
+interface c {
+	register "%esp" struct {
+	    entry code ret(int);
+	    void *fp;
+	} *sp;
+	register "%ebp" void *fp;
+};
+code function_code {
+	fp = sp;
+	sp += sizeof(struct local);
+	struct local *local = sp;
+	local->i = 1;
+	goto *fp->ret(local->i),sp=fp;  // return(local->i);
+};
+}
+みたいな感じでさ。さっすが、アセンブラ。いまいちreturnが汚いけど。
+まぁ、return はそのままreturnでもいいけどさ。
+あ、これは良いかも知れない。code が複数かけるから。
+state 以外は、consitent state であることを保証しない。ってのは?
+local 変数は使っても良いけど、call/goto の前後で、値を保証しないか...
+うーん、だんだん炸裂してるなぁ。
+だから、レジスタに対するマッピングの記述と、そうでない部分の
+記述は分離するべきでしょうね。
+全部一辺に実装するわけにはいかないからぁ...
+Thu Dec 16 13:44:21 JST 1999
+lock は状態遷移レベルで実現するのだから、self などを
+使ってlockする必要はないはず。
+全体の直列化は、状態遷移レベルで、
+	lock(storage) -> transition
+みたいな形で記述すれば良い。この当たりを、どのように記述するかは
+もう少し先送りしよう。
+引数はレジスタ渡しにしよう。長い引数は、呼び出し側の領域への
+ポインタとする。実装を規定しても良い。そうすれば、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 aguments in save area
+	# set extra argument pointer in %edx
+	    jmp function
+という形式になるわけね。second を処理するのはめんどくさいから一つ
+にしよう。
+えーと、frame pointer はないけど、コンパイルの手順からすると
+あった方が良い。しかし、frame pointer そのものをstatic
+にとるのはまずい。だから、frame pointer がfirst argment
+ということにする方が正しい。とすると引数は、さらに、その
+後と言うわけか。
+	f(fp,argment)
+fp を渡すのにさらにargment をレジスタで渡すのはおかしい。おかしいけど、
+ま、良いか。
+return しないなら、return type の定義をとるのは変だな。
+f(fp,arg1,arg2,arg3) とすると、それぞれが決まったレジスタに入って、
+多い分は配列にあると思われる。ふむふむ...
+fp->xx
+でアクセスすれば、そのまま局所変数になる。全部、配列で
+送っても良い。
+.set label,value
+で as は値をセットするようですね。
+関数コールの後は戻って来ないから後始末の心配はしなくてよい。
+frame pointer を使ったら自分で面倒を見ること。
+だと
+	a = atoi(s);
+みたいなことはできない...
+普通のCの定義と交じると間違いやすい。
+とすると、struct と同様に、
+	protocol
+	code
+	interface
+	state
+を用意するわけね。時間あるのかぁ?
+とりあえず、register 渡しのfunction 定義とgoto文を実装する。
+code name(register "%ebp" void *arg) {
+goto name(arg);
+}
+ぐらいかな? で、first argment が必ずregisterにのるようにしないと
+いけない。register storage class を入れて、
+register "%ebp" void *arg
+とかするわけね。
+ってことは、まず、レジスタを実装しないといけないわけね。
+で、stack を使った演算は、一応、そのままにする? それでも動くはず。
+式の途中でgotoは使えないんだから、それでいいはず。
+で、それから、これを拡張していく。
+interface c {
+register "%ebp" void *arg;
+}
+code name(interface c) {
+goto name(c.arg);  // c. は省略可能
+}
+とかね。さらに、
+protocol name {
+interface c {
+	register "%ebp" void *arg;
+}
+code name(interface c) {
+	goto name(arg);
+}
+code name1(interface c) {
+	goto name(arg);
+}
+}
+などとするわけか。なんと、これが 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 name (c,a)
+struct state *c; struct arg *a;
+{
+	goto name(arg);
+}
+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を選択できるようにする。
+Sat Jan  1 22:40:22 JST 2000
+とーにかく、 storage class regisgter を実装しよう。
+stmode=REGISTER
+で、local storage とおなじ扱いとする
+	static register? は、ない。
+symbol table に storage class をたせば? dsp==EXTRN で判定しているから、
+local 変数が36以上あるとおかしくなるぞ?
+sc  は GVAR/LVAR だけど、regsiter は LVAR の特殊な奴だから、
+sc に入れるほうが正しいか...
+Sun Jan  2 01:47:17 JST 2000
+register 変数はできました。けど、regsiter を二つ使うと、
+一杯になってしまうので、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"
+gcc2_compiled.:
+.text
+#
+# code name(c,a)
+	.align 2
+.globl code
+code:
+	.type	code,@function
+#    struct state *c; struct arg *a;
+# {
+#	goto name(c);
+	movl %esi,%esi
+	jmp	name
+_5:
+	.size	code,_5-code
+	.ident "Micro-C compiled"
+う、すごい。
+goto 文がめんどくさい。stack をたたんで、jmp すれば
+よいだけだが..
+Sun Jan  2 11:17:50 JST 2000
+普通のcallをcontinuation baseにすることができる?
+Sun Jan  2 20:28:45 JST 2000
+goto 文だけど、やはり、一度、expr で生成してから、top level
+で jump code を生成しよう。
+Tue Jan  4 03:32:55 JST 2000
+code をtypeにしないと、
+	code *p;
+とか書けないね。
+	int *p();
+と同じだけどさ。
+main(ac,av)
+int ac;
+char *av[];
+{
+	goto code1(ac,av);
+}
+code code1(ac,av)
+int ac;
+char *av[];
+{
+	if (ac)
+	    goto code1(ac,av);
+	else
+	    goto ac(ac,av);
+}
+Tue Jan  4 04:56:56 JST 2000
+うーん、なんかレジスタにつむ順序が違う
+これは、adecl がreverseにつむから。
+code のretrun
+やはりcodeはtypeにしないとだめ。
+main()
+{
+goto code1();
+}
+とかだと、main に戻って来れない。もちろん、code1() 以降で、
+return するわけにはいかない。(main の disp をcode1 は知り得ない)
+goto label をcode1の引数に送れば?
+main()
+{
+goto code1(ret);
+ret:
+}
+これだと、ret がforward labelかどうか分からないけど?
+code1 中で使う中間変数を stack 上にとるのは悪くない。しかし、それを
+%ebp 経由でアクセスするということは、main の中間変数を壊すということ。
+それを防ぐには、main 中のgoto codeで、%ebp を修正してやれば良い。
+(今は戻って来ないので問題ない)
+code1 のgoto では、戻って来ないから、その必要はない。しかし、
+label をcode1 中で渡されると、ちょっと気まずい。
+とすると、それは禁止して、main() 中でstackをたたんでからgotoするか?
+そうすると、無限後退して、結局、帰れないことになる... うーん。
+main() 中のlocal code を許せば、それは解決するが..
+main()
+{
+goto code1(code2);
+code code2() {
+	return;
+}
+}
+みたいな感じ。でも、そうするとscope rule を変える必要があるので厳しい。
+ま、悪くはないけどね。
+continuation を明示する方法もある。
+main()
+{
+goto code1(continuation);
+}
+code code1(ret)
+code (*ret)();
+{
+goto *ret;
+}
+かな? call/cc ?
+label へのgotoを許すのもいいけど、
+でも、label を許すと、すごくspagettyにならない?
+Tue Jan  4 11:47:24 JST 2000
+contiunation じゃなくて、return keyword を使おう。
+(実際、continuation と少し違うし)
+type が少し変になるけど、まあ良い。
+int
+main()
+{
+goto code1(return);
+}
+code code1(ret)
+code (*ret)(int);
+{
+goto *ret(3);
+}
+だな。prototype も付けないといけないか。
+Tue Jan  4 12:21:44 JST 2000
+これだとmethodがすべてstatic になってしまう。dynamic なmethod
+呼び出しにするには? dipatcher を自分で作ることになる。かなり
+めんどくさいが...
+code method(obj,arg)
+{
+}
+か、あるいは、inline にするか... #define のかわりに inline ねぇ。
+これはあとで考えて良い。
+Tue Jan  4 14:22:19 JST 2000
+main の変数を書き潰すのと、gotgo (*reg)(123) での値は、
+register 渡しで、current register にのらないので、
+結局、return label は専用に作る必要がある。
+Tue Jan  4 18:14:07 JST 2000
+stack を継ぎ足して、呼び出す方式を取れば、call by value
+のregister 渡しを制限する必要は無くなる。
+複数の値を返すことも容易だ。
+	.file "tmp.c"
+	.version	"01.01"
+gcc2_compiled.:
+.text
+#
+# code name(a,b,c,d,e,f)
+	.align 2
+.globl code
+code:
+	.type	code,@function
+#    struct arg *a,*b,*c,*d,*e,*f;
+# {
+#	int g;
+#	goto name(a,b,d,e,f);
+	jmp	name
+_5:
+	.size	code,_5-code
+	.ident "Micro-C compiled"
+おお?!
+	%esp  new %esp = old %esp - 12 -4
+	%ebp-4     = g
+%esi       = a
+%edi       = b
+%ebp = old %esp   0
+%ebp+4     = c       code_arg_offset=0
+%ebp+8     = d
+%ebp+12    = e
+%ebp+16    = f
+interface は付けよう! というか、
+	goto name(struct {xxxx})
+みたいな感じで良いわけね。どれをregisterにいれるかと言う問題はあるが。
+で、どうやってcallすればいいわけ? emit_pushするかわりにpush
+する?
+うう、これでは、だめか。code argument の数が変わると、
+ebp をいちいち動かすことになる。そこにはold sp があるから
+そいつもコピーする必要がある。
+	%esp  new %esp = old %esp - 20
+	%ebp-20   = g
+%esi      = a
+%edi      = b
+%ebp-16   = c code_arg_offset= -16 ((nargs-max_reg)*int_size)
+%ebp-12   = d
+%ebp-8    = e
+%ebp-4    = f
+%ebp = old %esp   0
+そうか、function からcallする時には、local 変数を書き潰して良い。
+#	goto name(a,b,d,e,f);
+	%esp  new %esp = old %esp - 20
+	%ebp-20   = g
+%esi      = a
+%edi      = b
+%ebp-16   = c code_arg_offset= -16 ((nargs-max_reg)*int_size)
+%ebp-12   = d
+%ebp-8    = e
+%ebp-4    = f
+%ebp = old %esp   0      disp=0 (*)
+local1 <----16 local variable
+%edx        -12   <- disp_offset
+%ecx         -8
+%ebx         -4
+%ebp = %esp   0
+%eip          4   <- arg_offset
+となる。ということは、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 が値を持つようになる。
+	a = label:;
+とか。うーん。label:(a,b,c) {}; みたいな形で、parallel 代入を許すと言う
+手もあるね。
+こちらの方がCとの相性は良いが... main() { label:(){ ... } }
+みたいなnestを許すかどうかと言う問題がある。
+変数の参照を許さなければ、特に問題はない。
+a = label: は、二重の意味があるなぁ。
+言語の名前。DinnerBell II とか? join も入れる?
+	code entry_a().entry_b() {}
+ですか? parallel call も?
+Fri Jan  7 19:53:53 JST 2000
+いまのままだと return が環境を持ってないから、大域脱出できない。
+まぁ、環境を入れてもいいんだけど、どこに置くかと言う問題が
+あるね。
+そうじゃなくて、return 側で判断するか?
+	retrun(ID)
+みたいな形でIDで判断する。そうすれば、return 側でID
+を見て判断できる。けど...
+まぁ、はやり、環境を持って歩く方がいいかなぁ。でも、
+引き渡しているから、二つ引き渡して、片方を使われたときに、
+反対側が消えてしまうのはいたいよね。今のままならば、
+そういうことは起こらない。
+continuation 特有の問題を避けるなら、このままでもいいんだが...
+contrinuation や環境は、このシステムでは自分で作ることが
+できるからね。
+そうなんだけど.... retlabel や retcont は実はオブジェクト
+全体に一つあれば良い。
+引数を渡すときに、そこに環境へのポインタをいれてやれば良いので、
+解決は割と簡単だが、そうすると、例の構造体を引数で渡すと言う
+問題を解決する必要がある。
+でも、今の実装ならば、まったく同じ変数の構成ならばコピーは
+実際には起こらないわけだから問題ないはず。特に、それを保証するために、
+interface を実装する必要がある。
+return ->
+	(void *)old bp
+	return address
+bp を直接操作できるようにするといいんだけど....
+Sat Jan  8 08:49:59 JST 2000
+今は、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 return0(i) int i; { return(i); }
+を許して、そこで、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 で良いわけだが、
+このあたりは、言語外の問題で、それを明示的にしたいから、この言語を
+作っているわけなのだから、これを内部で処理するのはおかしい。
+	code return0(i) int i; { return(i); }
+これだと、return の型が合わないと言う問題が生じるな。簡単には
+チェックできない。
+	int
+	main() {
+	    code a() {
+	    }
+	    code b() {
+		return(i);
+	    }
+	}
+にすれば、check はできるようになる。でも、これだと、
+	int
+	main() {
+	    a: {
+	    }
+	    b: {
+		return(i);
+	    }
+	}
+と差がない。module 化を言語外でやるというのが主旨なのだから、これでは
+まずい。これは高級アセンブラなのだから。
+あそうか、return と、大域脱出時のabortとは、状況が違う。だから、
+別なcode を呼び出さないとだめ。あるいは、値で区別するか。これは、
+logic programming のfail/success と似ている。
+	main() { } abort { ... }
+でもいいけど?
+	main() {  code abort { ... }; code return { ... }}
+かな?
+本来、subroutine call自体が、かなりの省略形なわけだから、これは
+仕方がない。今のままで通常のsubroutine callをシミュレートできるのか?
+	code (struct arg {...},void *sp) {
+	    struct env;
+	    push(sp,arg);
+	    push(env,arg);
+	}
+できるけど、ちょっと重い。やはり、frame pointer を直接操作しないと
+だめ。
+goto 文のほうに、env を一緒に送るものを作ったほうがいいのかも。
+	goto (*ret)(),environment;
+かな。type は? (void *)?
+	goto ret(),environment;
+にはならないの? そうすれば、自分でthreadを制御できる。environment
+の正当性を評価しなくて良いの? まぁ、ねぇ。
+これは実装は容易だが... goto といちいち書くのが本当にいいのか?
+env に対するoperationがあった方がいいなぁ。push とか?
+	code return0(i) int i; { return(i); }
+を認めれば、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 の、
+	self message: arg
+と同じ。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
+に積んでいるわけだから。
+いずれにせよ、
+	struct p = q;
+は実装する必要がある。localな、
+	code p = {func,env};
+も動くはずだが...
+	code (*p)();
+	goto (*p)(arg);
+はだから少しおかしい。これは、goto がenv を補っていると考えるべき。
+このようにすると、常に、
+	func,env
+の組をcodeとみなすことになる。これは、object と呼ぶべきだ。
+ただ、既存のobjectとは別だよな。actor の方が良い?
+うーん、これでjoinを入れれば、完璧なDinnerBellだな。並列送信はないけど。
+Sun Jan  9 01:40:05 JST 2000
+local 変数の初期化はallocation の後に遅らせる必要がある。
+nptr に入れられるはずだよね? nptr に初期化フラグを足すか?
+文途中で出現するlocal変数の初期化。ちゃんと動いているの?
+構造体のcopyは、lcheck を修正すべきでない。
+Sun Jan  9 08:49:43 JST 2000
+うーん、なんか修正が多いなぁ。あと、関数呼び出し、goto 文の
+構造体への対応か。
+	goto (*code)();
+が、self env を使うのか、code の先の値を使うのかを区別する
+必要がある。もし*を使わないとするとlabel(FNAME)との区別が
+つかないぞ。あ、でも、環境を持ち歩くことにしたから、label
+へもjumpしようと思えばできるね。
+並列送信はなくても、この構成ならばstatement単位の並列性を検出するのは
+容易だろう。
+やればできるけど、この修正の量だと1日じゃ終らないかなぁ。
+不動小数点も入れるのでしょう?
+Mon Jan 10 09:00:12 JST 2000
+引数に構造体を許すには、必ず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 は?
+一応、できたけど、やっぱり汚い。
+Wed Jan 12 16:12:27 JST 2000
+あは。ANSI prototype はめんどい。
+	bexpr()
+で、関数での引数の順序と、そのあとの宣言の順序が変わることがある。
+そうすると、うしろの方が優先されてしまう。これは、こまる。
+そうか、code_arg_offset のような方法だと、ANSI style では、
+困ってしまう。

Mercurial > hg > CbC > old > device

comparison Idea @ 0:d35df41eac69