パスワードを忘れた？ アカウント作成
Close
86429 story
プログラミング

MS、「Common Compiler Infrastructure」をオープンソースで公開 28

ストーリー by hylom
開発ツール開発ツール 部門より

あるAnonymous Coward 曰く、

Microsoftが4月17日、コンパイラおよび関連するプログラミングツールに共通する機能を提供するコンポーネントライブラリ「Common Compiler Infrastructure（CCI）」をMicrosoft Public License（Ms-PL）で公開した（SourceForge.JP Magazineの記事）。

CCIは.NET Frameworkの実行エンジン（仮想マシン）であるCommon Language Runtime（CLR）で動作するコードやデバッグファイルの読み込みや作成、操作を行うコンポーネントで、これを利用することで.NETアプリケーションを作成するコンパイラなどを作成しやすくなるようだ。Microsoftも、このコンポーネントを利用して開発ツールを作成しているという。

タレコミ子としては利用するケースがあまり思いつかないのですが、コンパイラを作ろう、という人は触ってみると面白いかもしれません。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

MS、「Common Compiler Infrastructure」をオープンソースで公開 More

  • SUIF（http://suif.stanford.edu/ [stanford.edu]）やTrimalan（http://www.trimaran.org/ [trimaran.org]…なぜか繋がらない）やCOINS（http://coins-project.is.titech.ac.jp/ [titech.ac.jp]）みたいなのを想像したがかなり違うのね。

    元ソースじゃなくて紹介記事読んだだけの印象だと
    普通のプログラミングにおけるアセンブラの出力部分やリンカの仕事に当たる部分を作る際のCLR向け共通インターフェースに近いのかな？CodeDOMとの関係はない？のかな？

    • その後、一応、リンク先http://ccimetadata.codeplex.com/ [codeplex.com]も覗いてきた感想：

      PEファイル（ポータブル実行可能ファイル）の読み書き
      PDBファイル（プログラム・データベース・ファイル）の読み書き

      がAPIの中心みたいですね。確かに実行可能ファイルの生成や加工、デバッグ用情報（プロファイルとかにもつかえる）ファイルの生成や加工というのはコンパイラのインフラには違いないですか…。特にPEは普通の実行可能ファイルではないわけなので専用APIを整備する必要もあるんでしょう。

      私も実際コンパイラ・フレームワーク/インフラストラクチャとしてCOINSを使っていますが、そういうものはパーサ→最適化→出力といったコンパイラ自身のフレームワークであって、その辺はない（外部プログラムとしてasやldを呼んでいる）ですからね。

      AST風なCodeDOMといいMSはコンパイラ用に使えるデータ構造やAPIを徐々に整備して.Netコンパイラ・フレームワーク的なものを構成していくつもりなのかしらん？

      シェア
      親コメント

      • バイナリファイルをダウンロードすると、いくつかのDLLとそれに対応する
        XMLファイルが添付されており、XMLファイルを確認するとどのような
        インタフェースがあるのか確認することができます。

        インタフェースとしては、PE(COFFの亜種)の読み書きや、このシンボル情報
        (gcc -g で生成されstripで除去するアレですね)の操作・参照を行うための
        ものが中心ですが、中にはMicrosoft.Cci.ILGeneratorというファイルもあり
        このファイルには以下のようなコード生成に関するものも含まれていますので、
        もう少しいろいろなことができそうです。

        - <member name="M:Microsoft.Cci.ILGenerator.Emit(Microsoft.Cci.OperationCode)">
          <summary>Puts the specified instruction onto the stream of instructions.</summary>
          <param name="opcode">The Intermediate Language (IL) instruction to be put onto the stream.</param>

        ドキュメントがもう少し整備されるとよいですね。

        シェア
        親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        つーと、monoのCecil [mono-project.com]みたいなもの？

        #あれ？逆？

      • Re: (スコア:0)

        by Anonymous Coward

        PEファイル（ポータブル実行可能ファイル）のPって、ポータブルって意味だったんだ。
        俺はてっきりプロテクトモードのPだと思ってたよ。

        # と、どうでもいい知識を修正した

  • FireBird (スコア:1, 参考になる)

    by Anonymous Coward on 2009年04月22日 3時24分 (#1553218)
    コードネーム FireBird の一部が出てきました。

    MicroSoft の目標は .PDB デバッグ情報をヒントにした、Native <-> Managed 相互コンバーターの作成です。
    Managed コードは、それ自体が中間言語ですから十分な情報がついていますが
    一般 Native コードにはそれがない。力業で逆アセンブルしても完全には内容が把握できない。
    だが .PDB に十分な情報が入っていれば何とかなる。

    ここで .PDB 付き Native バイナリを生成した元言語は必要ないことに注意。
    アセンブラだろうが C++ だろうが、.PDB 付き .EXE/.DLL から C# ソースを作成してしまうことができるわけ。
    いったん Managed コードに変換してしまえば、異種 CPU に最適化することが可能になります。

    FireBird の存在を前提にしたアセンブラは、おそらく元ソースコードの情報をリッチに PDB に押し込みます。
    そして実行環境下で実行時 CPU に適したアセンブラコードに落として実行されるでしょう。C# のコードが実行時最適化されるのと同様に。
    元ソースコードの CPU アーキテクチャと実行時 CPU アーキテクチャが異なっていても良いわけです。

    C# も、これら１０年越しの研究の成果の一部分なのですね。

    • CLRで統合する利点としては以下のような感じになるでしょうか。

      1. 全てのコードがCLRのmanaged codeで揃えばいちいち
        言語毎にstatical analyzer(バッファオーバーフロー
        が発生しないかどうか解析するツールね, 例えばllvm-GCC)
        を作らなくてもCLR managed codeに対するanalyzer
        だけ作れば済む。
      2. CLRベースで解析してもシンボル情報があれば
        managed codeのある命令に該当する元のソースコードの
        行数なんかもわかる。
      3. managed codeのひとつに、Javaのバイトコードがありますが、
        JavaバイトコードだとJavaの世界から外に出れないという難点がありま
        す。CLRならOSのほとんどの部分(もしかするとドライバも)
        を記述できる。

      相互コンバーターということで逆もあってもいいと思いますが、
      実際一度高級言語からバイトコードまで落としてしまうと
      逆コンパイルして可読性のあるコードを保つのは難しいでしょうね。

      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward
        既存のコード資産を最新 CPU に対応させるのが目的なのでしょうから
        可読性は必要ないのでしょう。

    • Re: (スコア:0)

      by Anonymous Coward
      MS ResarchではSingularityプロジェクトでも従来型のNativeOSモデルとManagedOSモデルを実用的に共存させる研究を行っていたことを思い出しました。
      　
      ftp://ftp.research.microsoft.com/pub/tr/TR-2006-43.pdf [microsoft.com]
      　
      CPUのみならずOSやManaged-Nativeの壁すら旧来の資産を保ったまま往来する、というかスムーズに移行できる、というのがMSが描いているゴールなのかもしれません。

      • Re: (スコア:0)

        by Anonymous Coward

        MSの本業は言語屋って事なんですかね
        この目論見が成功するとx86もろともWindowsの独占力も吹き飛ばしてしまいかねないのでは

        • Re: (スコア:0)

          by Anonymous Coward
          日にちがたったから、もう誰も見に来ない。かな？

          FireBird のすべてが公開されるとは限らない。でしょ？
          恐らく、変換エンジンそのものは Windows という名の OS から外には出てこないでしょう。

          もしすべてが成就したら....
          MS の売る「Windows」と言う名前の OS は、x32/x64/i64 だけではなく PowerPC / ARM / SPARC からメインフレーム CPU まで一つのバイナリで
          サポートします。小さな .NET Framework カーネルと FireBird エンジンだけが真の Native コードとして提供される。
          （デバイスドライバとかは、とりあえず忘れてください）

          その「Windows」上では、過去のある特定の「Windows」OS で動く/動いていたアプリケーションは、そのまま無変更で動作可能。
          古い MS Office や Windows CE アプリが、そのまま起動する。

          ということになります。うまくいけばね！
  • またLLVMの時のような大嘘を書き散らさないで下さい。
    コンパイラインフラストラクチャとは何か、はLLVMのストーリーで解説しておきました。
    • 「解説しておきました」っていわれても、ACで書き込まれたらどれが解説なのかわからないんですど。 とりあえず、LLVMのストーリーは過去に１個しかない [srad.jp] ので特定できたけど。コメントIDを教えていただけませんか。
      シェア
      親コメント
      • これは失礼いたしました。ここで書きます。

        コンパイラインフラストラクチャはコンパイラを実装するためのツール群で、特にバックエンドを細かく再利用できるようになっており、そこがありがたみの源泉になっています。
        つまり既存の最適化ルーチンを変更したり独自のものを追加したりといったことが容易にできるようになっています。

        gccはバックエンドは一枚板になっていますので、インフラストラクチャ度は相対的に低いと言えますね。
        Javaのクラスファイルは伝統的な意味でのターゲットコードですので、これもインフラストラクチャ度は低いですね。
        シェア
        親コメント

        • コンピューター言語について語る前に普通のコミュニケーション能力を身につけて欲しいものだ

          • Re: (スコア:0)

            by Anonymous Coward

            コンピューター言語について語る前に普通のコミュニケーション能力を身につけて欲しいものだ

            あーあ、どっちもできない自称エンジニア達を一斉に敵に回してしまいましたね。

            • Re: (スコア:0)

              by Anonymous Coward

              相手にする価値も無いから、別にいいよ。

              • Re: (スコア:0)

                by Anonymous Coward
                何か一言いわないと気がすまないのに気の利いたことが何も思いつかないのって辛いよね

      • Re: (スコア:0)

        by Anonymous Coward

        >ACで書き込まれたらどれが解説なのかわからない

        それ以前に、今回の記事に対するArtaneのコメントがどこにあるのかわからない。

        #一体(#1552996)は、今回の記事に対するArtaneのコメントをどこで見つけたんだろうか。
        #「またLLVMの時のような大嘘を書き散らさないで下さい。」 なんて言ってるんだから、どこかにあるんだろうけど。

  • N88-BASIT.NET (スコア:0)

    by Anonymous Coward on 2009年04月21日 20時11分 (#1553003)

    を所望する。

  • 参照するなら (スコア:0)

    by Anonymous Coward on 2009年04月21日 20時13分 (#1553004)
    反面教師
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond