Yasushi Shinjo wrote:
> Parrot って、Perl 用の VM の機械語なんですか。

違います。Perl 6 コンパイラがバイトコードを吐くそのターゲットとなる VM
のことだと思います。see: <http://www.parrotcode.org/>

>>Java VM とか、その MS パクリの .NET とか、オープンソース陣営の parrot と
>>か、そういうものが段々と頭をもたげてくるのを見ていると、とりあえず BIOS
>>レベルで parrot に対応しておいて、あとは OS でもなんでもかんでも parrot
>>の上で走らせちゃえば、OS すらハードウェア非依存にできてしまえる“可能性”
>>はあるわけです。
> 
> 標準理論では、OS の仕事は、ハードウェアの違いをソフトウェア
> から隠すものです。ですから、OS はハードウェアに依存してもい
> いというか、依存する部分を OS に押し込めます。標準理論ではね。
> Parrot の世界で、ハードウェアに依存する部分は残るんですか？
> それは、何と呼ぶんですか。単に言い換えただけですか。

その話は、ソフトウェアから見た場合、の違い、の吸収、ですよね？（API レベ
ルでの互換性とでも言うべき話でしょうか）

僕が言いたかったのは、再コンパイルなしに、OS のバイトコードを、異なる
ハード上でそのまま使えるということです（VM BIOS があれば、の話）。

Parrot の場合レジスタモデルの VM らしいので、CPU レベルでそのアーキテク
チャを仮想化してしまえば、もうコンパイラ（や、コンパイル時に利用するライ
ブラリ）レベルでは何もハードウェアの違いを吸収する必要はなる。バイナリ
コードの生成まで行うコンパイラの場合は、再コンパイルが必要になるのと対照
的だと思います。

もちろん、CPU のアーキテクチャを完全に仮想化することなんて、今現在の
Parrot はできないと思いますし、目標にしているわけではないと思いますが、
そんなことも「可能だな」と言ってみたわけです。

そうすれば、今までは、CPU アーキテクチャの違いを吸収するのは、OS を中心
とするソフトウェアベンダ側だったわけですが、VM BIOS のような考え方になれ
ば、むしろ CPU アーキテクチャの違いを吸収するのはハードウェアベンダ側の
問題となり、CPU も他の周辺機器メーカ同様に「VM BIOS という形の VM に対応
したドライバを提供」という感覚になる、可能性もなくはないわけです。

> ハードウェアの製造元は、ハードウェアを増やすのは簡単でしょう
> からね。生物の進化でもそうですが、世の中複雑化するというのは
> 自然の摂理なんでじょう。進化が行きすぎると、絶滅します。

進化の袋小路という奴ですね。
CISC のように分岐予測だとか、妙に小器用になっていくよりも、RISC のような
未分化でシンプルなやり方の方が、タフでパワフルだと思うんですよね。

-- 
Masanori HATA