--- a/Changes	Sun May 06 20:31:56 2007 +0900
+++ b/Changes	Fri May 25 19:28:25 2007 +0900
@@ -9369,6 +9369,44 @@
 
 展開するしかないんだろうなぁ。
 
-
-
-
+実は    Sun Jan  1 10:59:19 JST 2006 の時点で気づいていたのだが、
+忘れてしまったらしい....
+
+resgister save すると、({  goto hoge; .... }) で、かなり困る。
+
+Fri May 25 19:12:04 JST 2007
+
+
+関数をparse する時に、inmode == INLINE でcompileして pfdecl して
+やれば、parse tree base になる。
+
+fdecl/doif などで !inmode のコードは通らなくなるので、全部、
+取り除いてしまって構わない。mc-inline.c の st_if などは、
+むしろ、codegen.c にあるべきだったのか。こうなると、mc-parse は、
+parser のみになるので、その意味でも正しいね。
+
+こうすると、大抵のものはglobal heap に置かれてしまうので、GCが
+必須になる。もともと、getfree は複雑すぎるので... local heap
+stack を縮めるのは止めて、
+
+(1)
+    全部local heapにとり、関数をcompileして、pfdecl したあと、
+    型宣言とかinline funcitonのみを global heap にコピーする。
+(2)
+    汎用のGCを書いて、statement のtop levelで、それを読んでやる。
+    あるいは、スタック上のlocal heapを含めて任意の時点で GC する
+       (こちらの方が正統的だが、遅そうだ...)
+
+という手があるね。まぁ、そのままでも kernel compile とかしない
+限りは、だいじょうぶだとは思うが...
+
+parse tree を取った後の、最適化に関しては、まぁ、いろいろ可能だが、
+そんなに無理してもしょうがない。
+
+arg_register は、もっと頭が良い方がいいが...
+
+UDPCL 側に影響が出る可能性を否定できないが... コード生成は、
+st_if 側に限るんだろうな。
+
+GC やるんだろうなぁ。変更的には、結構大きくなるが...
+