🚀 go-pugleaf

kono@ie.u-ryukyu.ac.jp (Shinji Kono) writes:

> 河野 真治@琉球大情報工学です。
> 
> In article <pypd8h558rn.fsf@tp560e.sowa.is.uec.ac.jp> , 
> 	maeda@is.uec.ac.jp writes 
> >結局、よっぽどtrivialな言語を除いて、完全な自己記述は不可能ですから(こ
> >れを言語意味論における不完全性定理といいます(ウソ))、言語からはみ出す
> >部分は何らかのマホウ、あるいはズルを使わざるを得ません。
> 
> それって記述と実装をごっちゃにしてませんか? Turing powerful
> ならば、完全な自己記述は可能だと考えるのが普通ですよね。でき
> ないのは、実装の方で、それは、常に言語の外にあるものです。

うーんと、そうですね。メタレベルでの自己記述は可能ですね。今はオブジェ
クトレベルのどこまでがその言語自身で書けるかという話で...

まあ実装の話といってもいいかもしれない。

> だから、リフレクションという、実装と記述を対応させる仕組みが便利。

そうなんですか(いまいち良く判っていない^^;)。例えばCのva_argの(そのへ
んの処理系での)実装を、 リフレクションを使って説明するとどういう事にな
るんでしょう。

va_begin, va_arg, va_end等はメタレベルのデータをreifyするプリミティブ
であって、もとよりオブジェクトレベルのCで書けるはずもない...とか?

> >ま、仮にvoid *sbrk(ptrdiff_t size)でOSからメモリを取って来るのを許した
> >としてもですね、複数回のsbrk()呼び出しが返したメモリブロックを互いに比
> >較した結果は不定ですから、freeをC言語の範囲内で書く事はできません。
> 
> これって、 static char memory[0x100000000]; みたいんじゃ、なんでいけないの?
> そうすれば、freeもsbrkもmallocも問題なく書けますけど... マルチユーザとか
> にしたいのかな? だったら、 static char memory[0x100000000][MAXUSER];
> これってインタプリットしているわけでもないし、マイクロプロセッサの時には、
> 実際にそういうのを使っていました。

元ネタとの関連が良く判りませんが...こうやればそのへんのUnixの
malloc/freeも、すべて標準規格のCで作れるという事でしょうか。

＃ 確認： 「普通の」環境ではOSからライブラリまですべてCで書いてある。
＃        ところがJava(など)ではOSやGCが書けない。
＃ という主張が正しいかどうか、という文脈の話ですよね。で、「効率を度
＃ 外視すれば原理的には可能」という解決はとりあえず却下として。
＃ 私の答えは、「Cだってズルしてる。同じようなズルをすればJavaだって
＃ OSやGCがそれなりに実用的に書ける」というものです。

> 要は、このmemoryが、実際のハードウェアのメモリに対応しているのか
> を信じられるかどうかですよね。このまま、仮想記憶まで対応しようと
> 思うと、ちょっと面白いかもね。
> 	page_table pte[0x1000];
> 	char *tlb;
> とかあってさ...

やっぱり難しくて判りません。

MMUを持った仮想マシンをCで書いてるわけですか...?  ユーザプログラムとは
メモリ参照の仕組みがまるきり別なんですよね?

				前田敦司