LowLevel Future 2008 ~ 低レイヤー技術が生み出す可能性とその未来 ~ プログラム「古い言語，新しい言語」セクション ( パネルディスカッション資料 )

LowLevel Future 2008~ 低レイヤー技術が生み出す可能性とその未来 ~プログラム「古い言語，新しい言語」セクション(パネルディスカッション資料) 2008.8.30 なかの ZERO 若槻俊宏 (alohakun)

自己紹介 • 普通の大学院生 (D1) • 北海道大学大学院情報科学研究科複合情報学専攻 • プログラム構築における形式的仕様記述からアルゴリズム探索，実コード生成までの統一的な理論化に興味を持っている • 現在は低レイヤーの方の理論化に関わっている • 研究テーマ「等価変換の原理に基づいたアルゴリズム探索により実行環境や実行例に適応するプログラムの理論と構築」 • 要するに進化適応するプログラムを作るための理論 • blog : http://alohakun.blog7.fc2.com/

なぜ今回呼んでいただいた ?（根本的過ぎる疑問ｗ） • 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/index.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 • C プログラム→ LLVM 命令 (bitcode file format) • llvm-gcc (既存)でコンパイル • LLVM コード → AVM2 命令 (ABC file format） • Flash にアクセスする API など，マルチメディア API • カスタム POSIX システムコール • 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 : 実行環境インフラ

LowLevel Future 2008 ~ 低レイヤー技術が生み出す可能性とその未来 ~ プログラム「古い言語，新しい言語」セクション ( パネルディスカッション資料 )