--- a/Changes	Sun Nov 26 14:59:54 2006 +0900
+++ b/Changes	Sun Nov 26 21:54:03 2006 +0900
@@ -9161,40 +9161,3 @@
 offset は、結構複雑になるので、直す方が良いらしい。
 
 時間かける価値あるの? 少しかかりそうだな...
-
-      | frame pointer               | stack pointer
-      v----> argument      local <--|-----v
-                                    caller_arg
-
-ではなくて、
-
-      | previous $fp
-      |<-intr_size---><--------r1_offset----------->|
-      |               | frame pointer               | stack pointer
-      v<--- interface-+---- local ----->|<--------->v
-              <0          >0              caller_arg
-
-なら、いいんじゃない? caller_arg は sp 相対で積めば良い。
-
-これだと、frame pointer がgoto で可変になる。interface がarugment
-扱いになるので、限りなくsubroutine call に近くなるけど。
-(まぁ、そうだよな、そういう狙いだし...)
-
-だったら、完全にfunction callに合わせることも可能なんじゃないか?
-可変長引数の場合とまったく同じになる。gcc の(予定ししてる実装と同じ)
-
-      | previous $fp
-      |<-intr_size---><-------------r1_offset------------>|
-      |               |frame pointer                      | stack pointer
-      v<--- interface-+-------|--- local ----->|<-------->v
-              <0      >0  xxx                    caller_arg
-                         |frame pointer                      | stack pointer
-      v<--- interface----+-------|--- local ----->|<-------->v
-              <0         >0  xxx                    caller_arg
-
-caller_arg はsp上に積むと。そうすれば、alloca も問題ない。
-
-でも、めんどくさいよ。めんどくさい。めんどくさいです。
-
-でも、やるしかない。
-

--- a/Idea	Sun Nov 26 14:59:54 2006 +0900
+++ b/Idea	Sun Nov 26 21:54:03 2006 +0900
@@ -1733,3 +1733,242 @@
       }
 
 みたいな感じ?
+
+Sun Nov 26 21:14:57 JST 2006
+
+      | frame pointer               | stack pointer
+      v----> argument      local <--|-----v
+                                    caller_arg
+
+ではなくて、
+
+      | previous $fp
+      |<-intr_size---><--------r1_offset----------->|
+      |               | frame pointer               | stack pointer
+      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 と、まったく同じになる。
+
+      | previous $fp
+      |<-intr_size---><-------------r1_offset------------>|
+      |               |frame pointer                      | stack pointer
+      v<--- interface-+-------|--- local ----->|<-------->v
+              <0      >0  xxx                    caller_arg
+                         |frame pointer                      | stack pointer
+      v<--- interface----+-------|--- local ----->|<-------->v
+              <0         >0  xxx                    caller_arg
+
+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が発生しやすく
+なる。いや、そんなことはないのかな?
+
+      __code f(int a,int b) {
+	goto g(int c,int b,int a);
+      }
+
+      v<---|----+----local ----->|<-------->v                before f
+        a,b
+      v<--- interface-+-------|--- local ----->|<-------->v  f
+        a,b
+      v<--- interface-+-------|--- local ----->|<-------->v  goto g
+        a,b,c
+
+みたいな感じですか? 後ろをそろえるわけね。その方が自然か。
+
+これだと、やっぱり、max_interface が問題になる。やっぱり、それで、
+fp を下にしてあるんだろうな。
+
+      __code f(int a,int b) {
+	goto g(int c,__code *f,int a,int b);
+      }
+
+      __code g(int c,__code (*n)(...),...) {
+	goto n(...);
+      }
+
+      |<----------------------------r1_offset------------>|
+      |frame pointer                                      | stack pointer
+      v<--- interface---------|--- local ----->|<-------->v  f
+        a,b,(n,c)
+      |frame pointer                                      | stack pointer
+      v<--- interface---------|--- local ----->|<-------->v  goto g
+        a,b,fp,n,c
+            |frame pointer                                | stack pointer
+            v<-interface-+-------|-- local --->|<-------->v  g
+        a,b,fp,n,c
+       |frame pointer                                     | stack pointer
+      v<--- interface---------|--- local ----->|<-------->v  goto n
+        a,b
+
+えーと、goto n(...); で、どうやってfp を元に戻すの? ... の位置で、
+前の fp を覚えておけば良い。(*)
+
+これだと、function call を、そのまま実現できそうだけど? みたいだね。
+
+      __code f(int a,int b,...) {
+	goto g(int c,f,int a,int b,...);
+      }
+
+      __code g(int c,__code *n(int a,int b,...),...) {
+	goto n(int d,int e,int g,...);
+      }
+
+とかすると、無限にstackが延びる。ふーん。
+
+      __code g(int c,__code *n(...),...) {
+	goto n(int d,int e);
+      }
+
+は、どうする? fp は、そのままなんだろうね。
+
+      |<----------------------------r1_offset------------>|
+      |frame pointer                                      | stack pointer
+      v<--- interface-+-------|--- local ----->|<---------v  f
+        a,b,(n,c)
+      |frame pointer                                      | stack pointer
+      v<--- interface-+-------|--- local ----->|<---------v  goto g
+        a,b,fp,n,c
+            |<----------------------r1_offset------------>|
+            |frame pointer                                | stack pointer
+            v<-interface----+----|-- local --->|<---------v  g
+        a,b,fp,n,c
+               v<-interface-+----|-- local --->|<---------v  g
+               d,e
+
+で、fp は上書きか。それは、良くない。なので、fp の分ずらす。
+というよりは、fp の次を指すようにするのが良いのか。
+
+      __code f(int a,int b,...) {
+	goto g(int c,__code *f,int a,int b,...);
+      }
+
+      __code g(int c,__code (*n)(...),...) {
+	goto n(...);
+      }
+
+      |<----------------------------r1_offset------------>|
+      |frame pointer                                      | stack pointer
+      v---- interface-+-------|--- local ----->|<---------v  f
+        a,b,(n,c)
+      |frame pointer                                      | stack pointer
+      v---- interface-+-------|--- local ----->|<---------v  goto g
+        a,b,fp,n,c
+               |<-------------------r1_offset------------>|
+               |frame pointer                             | stack pointer
+               v<-interface-+----|-- local --->|<---------v  g
+        a,b,fp,n,c
+      |frame pointer                                      | stack pointer
+      v---- interface-+----------|-- local --->|<---------v  goto n
+        a,b
+
+というわけか。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 と差がないかも。
+
+
+あ、そうか。
+
+      __code g(int c,__code *n(int a,int b,...),...) {
+	goto n(int d,int e,int g,...);
+      }
+
+の n は、自動的に定義された方が便利だろう。
+
+      __code g(int c,...) {
+	goto __cotinuation(int d,int e,int g,...);
+      }
+
+みたいな感じ。
+
+      go g(int c,int b,...) to hoge(...);
+
+ですか? それは、だめか... だめでもないんだけど、型の設定が
+難しすぎる。
+
+K&R style の宣言の方が綺麗なのか...
+
+Sun Nov 26 21:53:05 JST 2006
+
+(*) interface の大きさの増減は、自分のinterface を見れば
+わかるはずだよね? だから、fp のsaveは必要ないはずだが...
+
+      __code f(int a,int b,...) {
+	goto g(int c,__code *f,int a,int b,...);
+      }
+
+      __code g(int c,__code (*n)(...),...) {
+	goto n(...);
+      }
+
+確かにわかるんだけど、宣言を間違えたときに、おじゃんになる。
+どうせ、だめではあるんだが。引数の型は一段階までしか、
+チェックしないので、だめだね。
+
+このあたり、理論的な問題があるみたいだな。
+
+    stack を含めた有限な型付け
+    と、その表現
+
+って問題があるわけね?
+
+そうか、parallel assignment では、同じ部分を前もって探した
+方が効率がよいわけか。(どうせ、やっていることだが)
+