ここで .PDB 付き Native バイナリを生成した元言語は必要ないことに注意。 アセンブラだろうが C++ だろうが、.PDB 付き .EXE/.DLL から C# ソースを作成してしまうことができるわけ。 いったん Managed コードに変換してしまえば、異種 CPU に最適化することが可能になります。
FireBird の存在を前提にしたアセンブラは、おそらく元ソースコードの情報をリッチに PDB に押し込みます。 そして実行環境下で実行時 CPU に適したアセンブラコードに落として実行されるでしょう。C# のコードが実行時最適化されるのと同様に。 元ソースコードの CPU アーキテクチャと実行時 CPU アーキテクチャが異なっていても良いわけです。
FireBird (スコア:1, 参考になる)
MicroSoft の目標は .PDB デバッグ情報をヒントにした、Native <-> Managed 相互コンバーターの作成です。
Managed コードは、それ自体が中間言語ですから十分な情報がついていますが
一般 Native コードにはそれがない。力業で逆アセンブルしても完全には内容が把握できない。
だが .PDB に十分な情報が入っていれば何とかなる。
ここで .PDB 付き Native バイナリを生成した元言語は必要ないことに注意。
アセンブラだろうが C++ だろうが、.PDB 付き .EXE/.DLL から C# ソースを作成してしまうことができるわけ。
いったん Managed コードに変換してしまえば、異種 CPU に最適化することが可能になります。
FireBird の存在を前提にしたアセンブラは、おそらく元ソースコードの情報をリッチに PDB に押し込みます。
そして実行環境下で実行時 CPU に適したアセンブラコードに落として実行されるでしょう。C# のコードが実行時最適化されるのと同様に。
元ソースコードの CPU アーキテクチャと実行時 CPU アーキテクチャが異なっていても良いわけです。
C# も、これら10年越しの研究の成果の一部分なのですね。
statical analyzer for all platform(Re:FireBird) (スコア:2)
CLRで統合する利点としては以下のような感じになるでしょうか。
言語毎にstatical analyzer(バッファオーバーフロー
が発生しないかどうか解析するツールね, 例えばllvm-GCC)
を作らなくてもCLR managed codeに対するanalyzer
だけ作れば済む。
managed codeのある命令に該当する元のソースコードの
行数なんかもわかる。
JavaバイトコードだとJavaの世界から外に出れないという難点がありま
す。CLRならOSのほとんどの部分(もしかするとドライバも)
を記述できる。
相互コンバーターということで逆もあってもいいと思いますが、
実際一度高級言語からバイトコードまで落としてしまうと
逆コンパイルして可読性のあるコードを保つのは難しいでしょうね。
Re: (スコア:0)
可読性は必要ないのでしょう。
Re: (スコア:0)
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-43.pdf [microsoft.com]
CPUのみならずOSやManaged-Nativeの壁すら旧来の資産を保ったまま往来する、というかスムーズに移行できる、というのがMSが描いているゴールなのかもしれません。
Re: (スコア:0)
MSの本業は言語屋って事なんですかね
この目論見が成功するとx86もろともWindowsの独占力も吹き飛ばしてしまいかねないのでは
Re: (スコア:0)
FireBird のすべてが公開されるとは限らない。でしょ?
恐らく、変換エンジンそのものは Windows という名の OS から外には出てこないでしょう。
もしすべてが成就したら....
MS の売る「Windows」と言う名前の OS は、x32/x64/i64 だけではなく PowerPC / ARM / SPARC からメインフレーム CPU まで一つのバイナリで
サポートします。小さな .NET Framework カーネルと FireBird エンジンだけが真の Native コードとして提供される。
(デバイスドライバとかは、とりあえず忘れてください)
その「Windows」上では、過去のある特定の「Windows」OS で動く/動いていたアプリケーションは、そのまま無変更で動作可能。
古い MS Office や Windows CE アプリが、そのまま起動する。
ということになります。うまくいけばね!