LowLevel Future
2008
~ 低レイヤー技術が生み出す可能性とその未来 ~
プログラム 「古い言語,新しい言語」 セクション
(パネルディスカッション資料)
2008.8.30
なかの ZERO
若槻俊宏 (alohakun)
自己紹介
• 普通の大学院生 (D1)
– 北海道大学 大学院 情報科学研究科 複合情報学専攻
– プログラム構築における形式的仕様記述からア
ルゴリズム探索,実コード生成までの統一的な理
論化に興味を持っている
• 現在は低レイヤーの方の理論化に関わっている
• 研究テーマ 「等価変換の原理に基づいたアルゴリズ
ム探索により実行環境や実行例に適応するプログラ
ムの理論と構築」
– 要するに進化適応するプログラムを作るための理論
– blog : http://alohakun.blog7.fc2.com/
なぜ今回呼んでいただいた ?
(根本的過ぎる疑問 w)
• OSC 2008 do で GCC Hacks という発表をした縁 ?
– 今回は llvm-gcc 関係で呼ばれた ?
• GCC や LLVM は趣味兼サーベイ (しろうと)
• 低レイヤーの方の既存研究として興味を持っている (だけ)
• しかも,実は GCC はあんまり今回関係ない
– LLVMはomoさんとかsyoyoさんの方が明らかに詳しい
• Syoyo さん : LLVM 勉強会の主催者
• 人選ミスの可能性大
• いらない子ですいません!!
いろいろ素人ですががんばります
よろしく
お願いします
ここから LLVM の話
• ちなみに LL Future の LL とは全く関係無い
– LLVM is NOT a Lightweight Virtual Machine.
– LLVM is NOT a Virtual Machine design for
Lightweight Language.
• ようこそ LowLevel の世界に !
– 話者のレベルが LL という噂も
LLVM (Low-Level Virtual Machine)
•
RISC ライクな低水準命令セット
–
about 49 opcedes (llvm 2.3)
•
–
•
•
llvm 2.3 で多値サポートのための getresult 命令が追加
豊富なビルトイン関数 ( Intrinsic Function) llvm.*
レジスタマシン (SSA)
– 特定の言語やオブジェクトモデルをサポートしない
プログラムのライフサイクル全体に渡る変換と最適化
– Offline code generation and optimization
•
•
Install-time target-specific optimization
Link-Time interprocedural Optimization (LTO)
–
–
whole program analysis
User-based profiling and optimization
•
run-time & idle time
参考文献
• The LLVM Compiler Infrastructure
– http://llvm.org/
• "LLVM: A Compilation Framework for Lifelong
Program Analysis & Transformation", Chris Lattner and
Vikram Adve. Proceedings of the 2004 International Symposium on Code Generation
and Optimization (CGO'04), Palo Alto, California, Mar. 2004.)
– http://llvm.org/pubs/2004-01-30-CGO-LLVM.html
– この時点では only 31 opecodes という記述が
• LLVM 勉強会資料 (syoyo さん,omo さん)
– http://groups.google.co.jp/group/llvm_study/web/
LLVM の使いどころ
• 設定ファイルやオプションが多い環境で有利
– 多様な環境に配布されるアプリケーション
• 毎回毎回,起動するたびに設定ファイル読んで,環境依存のオプショ
ン設定して… (無駄無駄無駄)
– バイナリ自体を書き換えて最適化してしまう!
• offline optimization
– (Java などのような) JIT に限定されない部分計算
• Mac OS X Leopard の OpenGL スタックなどに採用
– デスクトップ ⇔ iPhone などで同じアプリを使える可能性
• 多様な実行環境において
• 移植性と効率性を両立できる可能性
パネルディスカッションの元ネタ
• Running C and Python Code on The Web
– http://www.toolness.com/wp/?p=52
– Scott Peterson (Adobe) ‘s toolchain
– C code to be targeted to the Tamarin VM
• C言語をブラウザで実行、Ruby/Python/Perlも然り
– http://journal.mycom.co.jp/news/2008/07/10/031/ind
ex.html
• 移植性 ⇔ 効率性のトレードオフを解消できる技術と
来たら,ブラウザへの応用は自然と言える
ちなみに
• 私は LL とかウェブアプリケーションとか完全
に素人なので
• 識者からのツッコミ前提の資料です
– 私より詳しい人,いくらでも会場にいるような…
• ABC コード ?
– http://gihyo.jp/dev/serial/01/ll-future/0006
– 3 度の飯よりも ABC が好きな大人が多いらしい
• 何それ Concurrent Clean ? (って人)
– ActionScript Byte Code らしいですよ
背景知識 (ぁゃしぃ )
• from Adobe, Mozilla, and Tamarin
–
http://hecker.org/mozilla/adobe-mozilla-and-tamarin
• Tamarin プロジェクト
– Flash player 9 から採用された新しい JIT VM が AVM2
– コードネーム Tamarin として OpenSource 化し Mozilla プロジェクトに提供
• Flash player 9 = AVM2 + graphics, musics, videos, networking, etc components
– JRE (Java Runtime Environment) が JVM + 膨大な標準クラスライブラリなのと同じ ?
• ActionScript 3.0 (Flash 5 から ActionScript と呼ばれるように)
– JavaScript の兄弟 (プロトタイプベース vs クラスベース)
– ECMAScript 4 (ECMA-262) に準拠 (完全ではない)
– クラスベース (Java / C# に近い ?)
• Free Flex 2. SDK などで foo.as を foo.swf にコンパイル (javac に相当 ?)
• Flash player 9 により foo.swf 内部の abc file が実行される
Tamarin Project
•
http://www.mozilla-japan.org/projects/tamarin/
• 目標
– ECMAScript 第4版 (ES4) をパフォーマンスの高いオープンソースの
コードとして実装すること
– Tamarin VM は Mozilla の JavaScript コアエンジン SpiderMonkey
内部と Adobe Flash Player の AVM の一部として利用されている
• AVMPlus のソースコードを公開している
– http://developer.mozilla.org/ja/docs/Tamarin_Build_Documentation
– AVMPlus (VM library), MMgc (garbage collection library),
avmplus (実行ファイル) を提供
– avmplus コマンドは ABC file format を JIT 実行
– Adobe Flex 2 SDK に含まれる ASC (ActionScript Compiler) など
で foo.as を foo.abc に変換
• asc.jar のために jdk 1.4 以降が必要
– Mozilla SpiderMonkey ベースの JavaScript コンパイラ esc で
foo.js から foo.abc を生成できる (まだ完璧ではないらしい ?)
Scott Petersen’s toolchain
1. C プログラム→ LLVM 命令 (bitcode file format)
– llvm-gcc (既存) でコンパイル
2. LLVM コード → AVM2 命令 (ABC file format)
• Flash にアクセスする API など,マルチメディア
API
– カスタム POSIX システムコール
3. AVM2 命令 → ネイティブコード
• ブラウザ上
– Tamarinで JIT 実行 (既存)
過去の C 資産の再利用を重視 ?
• C で書くメリット自体は (ほとんど) 無い
– どのみち Flash 上で実行 (効率は変わらない)
– 使える API も限定される
• ブラウザ上で C 資産がそのまま活用できる
– 安全なサンドボックス実行が可能
• ゲームなどが有力 ? (Scott 氏による Quake デモ)
• エミュレータよりも効率的に実行できる可能性
– Python など,言語処理系はその一部
なぜ LLVM コードを一度生成する?
Q. C, Perl, Python, Ruby, Lua, etc… → 直接 ABC
コードを出力するコンパイラでも良くない ?
A. llvm-gcc が既に存在しているのが大きい ?
– GCC のバックエンドだけが LLVM target 対応
• 他は全て普通の (?) GCC
• C/C++ 以外の言語も使える
– Ada, Fortran, Objective-C,Objective-C++
– GNU C にまで対応する C コンパイラを作るのは大変 (既
に stable が存在しているのは大きい)
– バイトコード to バイトコード translator の方が実装が楽 ?
関連プロジェクト
• Nested VM
– http://www.cs.rit.edu/~bja8464/NestedVM.pdf
– 実マシンコード(機械語)をJavaプログラムに逆コンパイル
– 既存資産の再利用,サンドボックス実行
• IKVM.NET
– http://www.ikvm.net/
– .NET MSIL (CIL) ⇔ JVM バイトコード
– Mono や Microsoft .NET Framework 上で動く JRE
• JVM, class libraries, 相互運用のためのツール郡を含む
空気読まない疑問
• ブラウザの上で既存言語資産を動かして未来
が開けるのか ?
– 相互運用技術で,既存の資産に縛られなくなる ?
– 純粋に言語の能力でシステムの記述言語を選択す
ることができるようになる ?
– Software As A Service (SaaS) ブームの時も Paul
Graham が似たようなこと言ってたけど…
• 結局世界は Java だよね
• Java との相互運用がキー ? JRuby, Jython, Scala など
• そもそも LL に Future はあるのか ?
個人的なうれしさ
• GCC フロントエンドの重要性が増す ?
– 他の VM や環境への相互変換が確立されれば
– llvm バックエンドさえあれば良くなる
• http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
• LLVM ⇔ GIMPLE トランスレータ ?
• LLVM to RTL なんていう話も
• 俺言語 GCC フロントエンド向けに書いたコー
ドが,ブラウザなどでも動くようになる ?
– GCC : コンパイラインフラ
– LLVM : 実行環境インフラ
ダウンロード

ppt