by
Anonymous Coward
on 2008年11月15日 23時34分
(#1456285)
おいこら、毎度毎度大嘘つくんじゃねえ、この半可通がいい加減にしろ。
LLVMの命令セットは > A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands. だよ。何がバイトコードだ。
> みんなもArtane.の適当な放言に騙されないように > http://llvm.org/docs/LangRef.html [llvm.org] > を読もう！ 読んでみたところイントロダクションに >The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. とあるのだけれど、バイトコードって書くと間違いなの?
中間コード… (スコア:0)
gimple,rtlとかは違うの？
というか、まじめにC/C++のコンパイラを書こうとしたら、
構文木はどこかにして保持したくなるんじゃないの？
それがあるからってどこが単なるコンパイラじゃないの？
llvmがよさげなのは、実行時プロファイルを元にvm用のコードを最適化してくれるところでしょ。
Re:中間コード… (スコア:2, 参考になる)
中間コードでも意味が違う(Re:中間コード… (スコア:1, 興味深い)
# RTL式を動かすインタプリタは出来ないことはないけど、あんまし効率がよくないのではないかと思うのですが…
つまりは、この手のコンパイラの工程を簡略に表すと、以下のような感じになります(斜体は中間でVM吐く場合に追加)
ソース
↓
RTL
↓
最適化・(必要なら)リンク
↓
仮想マシンバイトコード出力
↓
最適化・リンク
↓
実マシン実行コード
つまりは、多分最近のgccもある程度手を出してるような気がするのですが(gcc4になってからソース見てないから自信ない)、この手のコンパイラでは共通仮想マシンで動かすための最適化と「リッチな」共通仮想マシンのコードからレジスタ資源がより厳しい(と思われる)マシン固有の実行コードに落とすときの最適化の二回最適化を行っています。
後者に付いてはJavaのバイトコードインタプリタのように仮想マシンで動かして(遅くなるけど)ソースコードのデバッグをやってしまう事も出来るようになる。
こうすることで、gccがハマっていたターゲットの機械語依存のコード生成とソース解釈レベルでの中間コード生成がぐちゃぐちゃになりかねないリスクを(理論上)完全に排除できます。
これはコンパイラのソースコードを書く工程での不具合発生可能性を劇的に減らせるだけでなく、コンパイラの内部でコード生成のバグが出たときやその可能性が出たときのデバッグ工程の工数を大きく減らせる可能性も持ち得ます。
その結果(というよりは目的その物だろうけど)、コンパイラでのバグの最大要因であるターゲット向け最適化の部分を全く綺麗なコードで書けるようになると同時に、利用者も大概の場合は高級言語で記述する部分のデバッグに専念出来るようになって、デバッグの負担をかなり軽減できる筈です。仮想マシンが練り上げられていれば。ですけど。
ターゲット向け最適化は中間コードになった物からターゲット向けコード生成の部分だけを・高級言語に依存した構文内最適化はソースコードから中間コード生成の部分だけを考えて書けば済むので、あらゆる工程でDIRTY HACKの必要な部分を非常に減らせます。あくまでも理論的には。
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1, 参考になる)
LLVMの命令セットは
> A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands.
だよ。何がバイトコードだ。
みんなもArtane.の適当な放言に騙されないように
http://llvm.org/docs/LangRef.html
を読もう！
Re: (スコア:0)
> http://llvm.org/docs/LangRef.html [llvm.org]
> を読もう！
読んでみたところイントロダクションに
>The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation.
とあるのだけれど、バイトコードって書くと間違いなの?
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1, 参考になる)
バイトコード [e-words.jp] とあるように中間コードの意味でなら「バイトコード」と書くのは間違いでは無いように思うが、 という使い方が多いことを考えると「バイトコード」と書くのは間違いだと思う。
引用されている文章も"as an on-disk bitcode representation"って表現を変えてるし。
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1, 参考になる)
バイトコードの意味を広くとらえるなら間違いではないでしょう。
しかし実際のところLLVMは型付きSSA+αなので、Artane.の分類に従うならバイトコードではなくRTLとほぼ等しいものになります。
だからArtane.は一知半解なんですよ。
> んー、llvmの吐く中間コードはUCSD Pascal仮想マシン [wikipedia.org]やJava仮想マシン [wikipedia.org]のように完結性の高い仮想マシンで共通して「One write,All run」(だっけか)動くバイトコードであって、RTL式のようなコンパイラが内部で使うための構文木とは違います。
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1)
# もう、AC氏は見てないかもだけど。
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1)
この一文は余計。「元のコメントにはこのような間違いがある」といった文でいい。横から見ている人間にとっては正しいのか、一部に間違いがあるのか、まるっきり正反対のことを言っているのか、その内容が重要なので。
こんなことを言ってうまく通じるのか分からないが、どっちかの味方をしているというわけではないです。個人攻撃が含まれると書いている内容が参考にならないので残念なだけです。
LIVE-GON(リベゴン)
Re: (スコア:0)
C - LLVM -------------- 機械語
C ------- gcc RTL ------ 機械語
C ---------------- CLI - 機械語
こんな感じ？
Re:中間コードでも意味が違う(Re:中間コード… (スコア:1, 興味深い)
何言ってんだか。その正反対ですよ。各CPUの機械語に落とし込みやすいLLVM IRを定めるための、現存CPUの差異を捨象した仕様こそがLLVMですよ。
Re:中間コードでも意味が違う(Re:中間コード… (スコア:2, 興味深い)
LLVMはcompiler infrastructureであり、最適化やセマンティクスの拡張などコンパイラの実装に必要な情報を可能な限り保持し抽象化したものです。
だから伝統的な内部表現とは違い型情報がついている。
コンパイラ実装者以外には、基本的には無用の長物。
> 各CPUの機械語に落とし込みやすいLLVM IRを定めるための、現存CPUの差異を捨象した仕様こそがLLVMですよ。
これはまあ、結果的にはそうなってはいるんだけども。
Re: (スコア:0)