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 では、
困ってしまう。

Thu Jan 13 04:46:12 JST 2000

#       goto name(a,b,d,e,f);
        code name { int g; ...

        %esp  new %esp = old %esp - 20
        %ebp-20   = g code's local variable
        %ebp-12   = f <- new_disp
        %ebp-8    = d
        %ebp-4    = d
        %ebp-0    = c
        %edi      = b
        %esi      = a
        %ebp = old %esp   0      disp=0 new env
         local1 <----16 old local variable       ( to be erased )
        %edx        -12   <- disp_offset
        %ecx         -8
        %ebx         -4
        %ebp = %esp   0   <- old env
        %eip          4   <- arg_offset


Thu Jan 13 13:38:24 JST 2000

だいたいできたけど、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 を用意すると良いね。

Mon Jan 17 15:23:34 JST 2000

    struct aa f1() {
	return bb;
    }

みたいなのは? 関数の型か代入の型を見て、crn にpointerを渡して、
あとでcopyしてから stack を畳む。

    # 	bb=f1(aaa);
	    movl $bb,%eax
	    pushl %eax
	    movl $aaa,%eax
	    pushl %eax
	    call	main2
	    popl %edx
	    copy %eax,%edx,$400
	    addl $400,%esp
    #     return a1;

あ、でも、それだと、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;
	    .align 2
    .globl main
    main:
	    .type	main,@function
	    pushl %ebp
	    movl %esp,%ebp
	    pushl %ebx
	    pushl %ecx
	    pushl %edx
    # char *av[];
    # {
    #     register int i;
    #     register char *p;
    #     int j = 3;
    #     struct { int b; void (*c)(struct aa); } q = {3,main1},r;
    # 
    #     j = 3;
	    subl $20,%esp

このsublを後から指定してやればOk。

でも、それだと jump の時にずれない? ずれるか? ずれるね。うーん。
実行時にチェックしてやるのも変だし。

まぁ、それほど必要な機能ではないんだけど。

これもcontinuationを渡してやると言う手法が使えないことはないんだが...

関数呼び出しの最初にやってやればいいか。それでできるかな?