C/C++でFlashアプリが開発できるAdobe Alchemy 78
ストーリー by nabeshin
各種エミュレータもWeb上で動き出すか 部門より
各種エミュレータもWeb上で動き出すか 部門より
あるAnonymous Coward 曰く、
C/C++で開発されたコードをFlash Playerで動作させる「Alchemy」というプロジェクトが、プレビュー版ツールキットを公開している。
マイコミジャーナルの記事によると、AlchemyはC/C++コードをActionScript仮想マシンで動作するコードにコンパイルするもので、先日/.でも話題になったLLVMを活用するものだ。OSに依存するようなコードはもちろんコンパイルできないが、Alchemyにより生成されたコードはActionScriptで記述されたものよりもかなり高速に動作するとのこと。
LLVMの仕組みを使えば、C/C++以外にも対応言語を増やせるとのことで、将来的にはPerlやPython、RubyなどでFlashアプリを開発することもできるようになるかもしれない。期待したいところだ。
よし! とりあえずこれだ (スコア:5, おもしろおかしい)
コンパイラが文字列をパースし、中間言語に変換し、それを最適化していくさまを Flash で表示し続ける。で、それをみんなでお茶を飲みながら眺める…
「あ、今の所、ソースコードにバグがありますっ」
一人の観察力溢れる若者のせいで、ゆとりの時間が台無しに…
あなたがデバッグしている様を Flash として世界中に公開だ。
「あ、何を見落としてんだこいつ」
老練なる技術者から突っ込みコメントが…
make とたたくとウルトラマンが怪獣を倒す。一つのターゲットごとに一匹づつ倒す。
しかし、途中で Warning を食らうとカラータイマーがぴこーん、ぴこーん。
Error を食らうと赤のままピーーーーーー
「私はソースを2つ持ってきた」
謎な事を言い出すゾフィーを表示してくれる
以上が全て Flash 内に作られた Sandbox 上で実行されるので、いくら頑張っても結果はディスクに保存されない。
「これはいい、と思ったら製品を買ってね」
というマイクロソフトからの広告をもって、全プログラムが終了する。そんなVisual Studioトライアル版を作るのに、最適な環境である、という気がした。
fjの教祖様
どちらかというと AIR向けの感じがする (スコア:5, 興味深い)
デスクトップアプリケーションとして十分な速度を AIRは出せますよ。もちろん C/C++ですから(ActionScriptを知らないプログラマでも)安心ですよね。お客さまのところで利用されているC/C++ライブラリも有効利用できますよ〜、などという Adobeのセールストークがふと思い浮かびました。
MIYAZAKI Yasushi
無限最適化？ (スコア:3, おもしろおかしい)
＞Alchemyにより生成されたコードはActionScriptで記述されたものよりもかなり高速に動作するとのこと。
さあ、そのActionScript仮想マシンをAlchemyでコンパイルする作業に戻るんだ。
vorbisストリーミング (スコア:2, 興味深い)
ActionScriptで再実装するのもなぁ…と思っていました。これはいけるかも。
# 既存のがあったらそっち使いますので教えてください
Re:vorbisストリーミング (スコア:2, 参考になる)
Re: (スコア:0)
Re:vorbisストリーミング (スコア:2, 参考になる)
http://barelyfocused.net/blog/2008/10/03/flash-vorbis-player/ [barelyfocused.net]
ここ [jeroenwijering.com]で見つけたよ
対抗技術 (スコア:1, 興味深い)
Re:対抗技術 (スコア:1)
朗報 (スコア:1)
一体、何の意味が？ (スコア:1)
自分もパールやルビーで書けると面白そうだなあ
と思ってしまうので、そういう層がターゲットなんでありましょうか
それとも、近年余りがちなＣユーザーの再雇用対
うわあ！何をするおまえら
Re:一体、何の意味が？ (スコア:4, すばらしい洞察)
それによって作られるものに意味があるのです。
Re:一体、何の意味が？ (スコア:1, 興味深い)
ffmpegを使ったクライアント側動画変換システムとか、X serverやVNCクライアントとか色々できそうですね。速度が残念な事になりそうですが。
rubyやpythonなどのインタプリタをAS byte codeにしてスクリプトを動かすこともできるかもしれません。夢が溢れます。
Re: (スコア:0)
X serverなどサーバー関連はちょっと違うと思います。
Re: (スコア:0)
X clientがアプリケーション側で、X serverは表示側です。
Re: (スコア:0)
リモート(webサーバ)側で折り返せば、できないこともない....かな？
C プログラマの価値はまだあるか (スコア:1, おもしろおかしい)
DOOMデモ (スコア:1)
DOOMってたぶんOpenGL使ってるんですよね。OpenGLのwrapはどうどうしてるんだろう？
AVG anti-virus data base out of date
このデモはDOOMじゃなくてQuake (スコア:1, 参考になる)
Flashでもフレームバッファへの自前描画ができれば、移植は可能でしょう。
後からOpenGLを使ったWindows版Quakeが出ましたから、その時代からしか知らなければ
誤解するのも無理はありませんけど。
もしかしたら本当にOpenGLの操作ができるのかも知れないけれど…。
それなら色々楽しいことができそう。
Re:このデモはDOOMじゃなくてQuake (スコア:2, 参考になる)
Re: (スコア:0)
Re:DOOMデモ (スコア:2, 参考になる)
DOOM は NeXTSTEP で開発されたと、何度言ったらわかるんだ!
オリジナルの DOOM っていうと、NeXTSTEP版を言うんだよ!
Re:DOOMデモ (スコア:2, 興味深い)
それって、オリジナルは開発に使ったWS/PC版がオリジナル、って言います？
まあ、そいつらには大抵ハードウェアエミュレータが刺さってるので、NeXT
上のDOOMとはちょっと事情が違いますけど、開発者側の意図としてはたぶん
一緒じゃないかと思いますけどね。
貧弱なハード用のソフトを作る事自体はそこそこ面白いけど、貧弱な環境で
開発するのは耐えられないという。
レンガの錬金術師 (スコア:0, オフトピック)
で、結局ＬＬＶＭって何？ (スコア:0)
LLVM使うと結局どうなんの？
C++でもGCとかがサポートされるってことなの？
サポートされないんだったら、javaやらperlやらはどうなんの？
教えてプリーズ
Re:で、結局ＬＬＶＭって何？ (スコア:2, 参考になる)
llvmでコンパイルしてactionscript bytecodeを生成するという話です。
c++でもgcがサポートされるということは無いと思いますが、bohem gcなどは使えると思います。
javaはgcj付きでビルドしたllvm-gccで動くかもしれませんが分かりません。
perlはインタプリタをactionscript bytecodeにコンパイルすれば動くかもしれませんが分かりません。
Re: (スコア:0)
なんとなくイメージわいてきた。
今回のは
c++ ->(ここから Adobe)-> (コンパイル)->LLVM->(コンパイル)-> (Alchemy ここまで)->Flash
っていうのが新しいってことね。
perlやらネイティブコードに変換する代わりにflashにしてみました、と。
実行時最適化とか、静的にコンパイルするより速くなるってことでLLVMにワクテカしてた時期があったんだけど、
そういう風にも使えるってことで、別にそのための技術じゃないってことね。
Re: (スコア:0)
boehem gc「を」そのVM上で動くよう移植する必要が有りますね。
そしてその移植は常に可能とは限らず、CPUだのなんだのの機能に依存する面が有りますし、
またイロイロなワザを使うことを禁止される環境では成功率は下がる恐れも有ります。
Boostあたりのメモリ管理はイケルだろうけど。
Re:で、結局ＬＬＶＭって何？ (スコア:2, 参考になる)
ただし、このドキュメントが語っているのは、タイトルの通り"accurate" garbage collection向けの機能であり、おのずとcooperative garbage collectionを想定しているようなので、あくまで"conventional" garbage collectorとしてのBoehm-GCを移植したいという場合に、このドキュメントが役に立つかどうかは(よく読んでいないので)分かりません。
おっしゃる通りBoostのメモリ管理とは相性が良さそうです。
個人的には、実用的なcopyingもしくはgenerational collectorがどの程度のパフォーマンスでLLVM上に実装できるのかに興味があります。LISP好きなので。 :-)
ところで、このドキュメントを読んで、OCamlがすでにLLVMで動くらしいことを知りました。 ということは、OCamlで書いてFlash Playerで実行するなんてこともできるのでしょうか? (と、無理矢理ストーリーに関連付ける。)
こういう挑発的なことをすると (スコア:0)
Re: (スコア:0)
メモリ破壊コード (スコア:1, 興味深い)
Re:メモリ破壊コード (スコア:2, 参考になる)
別に何を再現する必要も無いのでは？
不定というのは、結果がどうなっても構わないという意味です。
暴走、例外はおろか、鼻から悪魔が飛び出しても言語規約上許されますし、
そんな分かりやすいリアクションではなく、一見正しく動作しているフリをしても構いません。
数多くのプログラマを苦しめてきた、Ｃの暗黒面の筆頭といって良い仕様です。
Re:メモリ破壊コード (スコア:1, おもしろおかしい)
指定された壊れたメモリ領域を律儀に読み込んでとんでもない動作を実行し続けるだけで。
壊れていようがなんだろうがお構い無しに実行するのがCという言語の仕様。
まあコードからだけでは動作を予測し切る事は一般にできないもんだけど。
Re:メモリ破壊コード (スコア:2, 参考になる)
なんかprintfをつけたら症状が出なくなったからデバッグ完了、と同じ類のvoodoo臭がぷんぷん漂ってきますよ。
Cの規格では確保したバッファの範囲外を読んだり書いたりアドレスを生成するだけで不定になります。
確保したバッファ+1のアドレス生成だけは認められていますが。
Re:メモリ破壊コード (スコア:1, 興味深い)
アドレスを生成した時点で不定だったっけ？
void* pv = (void*)(0xDEADBEEF);
このコードが存在するだけで不定って意味になるけど、pvを使ってアクセスしなければ不定にはならないと思うよ。
Re:メモリ破壊コード (スコア:2, 興味深い)
はポインタの指す先を読み書きしなければ大丈夫です。
整数はどんなポインタにも変換可能と規格で決まっています。
undefined なのは
char buf[1]; や char *buf = malloc ( 1 );
があったときに、(buf-2) や (buf+2) を含む式を評価した場合です。
例えば オーバーフローがあると例外を発生させるような種類の CPU で、
buf がメモリ空間の端っこ付近に割り当てられていたりすると
ひどい目にあうかもしれません。
一方 (buf-1) や (buf+1) は評価できることになってます。
一個までなら配列の範囲外を指すポインタを生成しても
オーバーフローしないと規格で決められています。
先の例で言うと、 buf はメモリ空間の端っこに配置されません。
必ず一要素分以上隙間があります。
嘘を書くな嘘を（Re:メモリ破壊コード） (スコア:2)
ポインタが指し示す先のオブジェクトの中には
alignment が問題となるものがある（たとえば、奇数ア
ドレスを持ち得ないなど）ので、整数→ポインタの結果
については実装依存です。
逆もしかり（実装依存）で、特にポインタ→整数で保持
しきれない環境では undefined-behavior です。
余計にアドレスを生成して良いのは配列へのポインタの
場合のみで（対象が malloc では駄目）、配列の最後の
要素を一つだけ越えて生成する場合に限られます（一つ
前は駄目）。
Re:嘘を書くな嘘を（Re:メモリ破壊コード） (スコア:2, 興味深い)
だから、「変換するまで」は OK 。
変換した後のポインタをいじくるとどうなるかわからないし、
何が入っているかもわからない、
と理解していました。
may だからコンパイルエラーにしても良いということですか？
> 余計にアドレスを生成して良いのは配列へのポインタの
> 場合のみで（対象が malloc では駄目）
これは本当ですか？
と、malloc の返すポインタは an array を指せるようになっているのですが、
binary + の項目には malloc で作られた object を指すポインタと
そうでない object を指すポインタを区別する記述は見つかりませんでした。
どこにその記述があるか教えて頂けると助かります。
>（一つ前は駄目）。
ごめんなさい。そうでした。
Re:嘘を書くな嘘を（Re:メモリ破壊コード） (スコア:1)
int i;
t_hoge a[10], *p=a;
for( i=0; i<10; i++ ){
*(p++) = hoge();
}
みたいなコードを許容するためだ、と書いてあった記憶があります。
この例では計10回 p++ が走りますが、10回目の p++ がエラーになってはいけない、ただそれだけだと。
なので、配列の後ろにアドレス空間上の余白を空けるかどうかとは別問題です。
そもそもポインタが実アドレスや論理アドレス、あるいはそれに準じる値を保持する約束も無いのです。
(もちろん実装するにあたり、常に後方にアドレス空間を空けておくという解決策もありでしょう。)
記事では10回 ++ した p を他の t_hoge* と比較できるかどうかも考察していたと思いますが、
そっちは忘れてしまいました(汗
Re:嘘を書くな嘘を（Re:メモリ破壊コード） (スコア:2)
これはその通りで、実装がどう動くかを理解して書く分
には構わない（実装依存でないのは 0 をポインタに変
換したときだけ、というのを勘違いしてた）。
これも私の嘘でした（何を勘違いしてたんだか…）。
Re:嘘を書くな嘘を（Re:メモリ破壊コード） (スコア:1)
そっちもオッケーだったはず。
t_hoge array[10], *ptr;
for (ptr = array; ptr < array+10; ptr++) {
…
}
みたいなコードでも正しく動くようにってことで、
「array+10」は「ポインタ」としては正しく存在し演算可能。
ただし、大丈夫なのはポインタを扱うところまでで、*(array+10)をやったらアウト。
Re:メモリ破壊コード (スコア:1, 興味深い)
Re:メモリ破壊コード (スコア:1, 興味深い)
言語仕様上は不定として、じゃあ Alchemy はどうしてくれるんだろうって話じゃね？
いけないアソコをおさわりしちゃった時に、Alchemy も何らチェックせず本当にリアルのアソコをおさわりしちゃうのか、それともそこらへんはきっちりチェックして、なんか例外を出すのかと。
あるいは本当におさわりするわけじゃないけども、仮想マシンの中で“世界のアドビ”フラグでも立てて、0xAD0BE の倍数でアホになる挙動をエミュレートするとか。
鼻から悪魔を出してもいいのなら、“じゃあ Alchemy ではこーし(ますっ|ませんっ)”と宣言してくれても何ら違反じゃないよね、っていう。
Re:メモリ破壊コード (スコア:2, 参考になる)
コードの中でそれをトラップさせる仕組みを追加しても構いません。
ある意味盲点ですが「そのまま正しく動作」させても規格上は問題ありません。
MS-DOS の頃など、V-RAM や OS のワークエリア等を直に読み書きしていたのがこれにあたります。
処理系を実装するにあたって何も定められていない以上、
そのようなコードを放置して、あるがままに動作させても言語仕様には違反しませんし、
処理系としてそのような動作を保証しても構いません。
でもそれは特定の処理系における実装の例に過ぎず、
他の環境でどうなるかは分からないし、環境ごとに異なる結果となっても、
そのいずれもがＣの仕様に準じた正しい処理系だと言えるということです。
Re:メモリ破壊コード (スコア:1, すばらしい洞察)
そろそろ知ったかぶりが痛々しい
Re:メモリ破壊コード (スコア:1, おもしろおかしい)
元コメには、初級C言語を学んで欲しい。
http://www.st.rim.or.jp/~phinloda/cqa/cqa7.html [rim.or.jp]
Re:メモリ破壊コード (スコア:1)
C だけじゃなく C++ も可能と言ってるのだから、throw や try/catch くらい視野に入っているでしょう。
Re: (スコア:0, オフトピック)
もしその手の問題があっても、原因はこの仕組みを使ってコードを書いた書き手じゃなくて
Flash上のVMの実装の問題でしょう。
ということは別に他の穴と問題は同じなわけで特別視する意味がわからない。
Re: (スコア:0, オフトピック)