--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Idea	Thu Jan 13 02:41:41 2000 +0900
@@ -0,0 +1,1035 @@
+
+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 では、
+困ってしまう。