Today アクセスカウンター Yesterday アクセスカウンター

ホワット・ア・ワンダフル・ワールド

私は知識に何ものかを付け加え,また他の人々がより多くのものを付け加える手助けをした --- G.H.ハーディ

全記事一覧 << 2008/06 12345678910111213141516171819202122232425262728293031 2008/08 >>

プロフィール

あろは (alohakun)

  • Author:あろは (alohakun)
  • 若槻俊宏 (WAKATSUKI toshihiro)

    連絡先 : alohakun ___at___ gmail.com
    mixi : http://mixi.jp/show_friend.pl?id=182927
    twitter : http://twitter.com/alohakun

    abstract

    プログラミングという人間の知的行為を体系化し,単なる職人芸ではなく,サイエンスにするための研究をしています.

    具体的には,等価変換計算モデルに基づいた,仕様記述からのプログラム合成の研究をしています.

    もっと噛み砕くと,プログラムの正しさをどのように定式化し,どのような枠組みで,どのように変換を進めていけば,正しさを保証したまま,効率的なプログラムを手に入れることができるのか,ということについて研究しています.

    キーワード : equivalent transformation, computation model, programming paradigm, formal specification, program synthesis













    あわせて読みたい


    この日記のはてなブックマーク数


    スカウター : ホワット・ア・ワンダフル・ワールド


    Map









    FC2 BLOG RANKING

FC2カウンター

ブロとも申請フォーム

この人とブロともになる

ホーム

call とか ret は無くてもなんとかなる

2008/07/11(金) 01:02:33

Linux Kernel の include/asm-i386/system.h の switch_to() マクロとかで使われていたりして,わりと有名なテクニックなのかもしれませんが,

call foo

とかは,機械的に

pushl $1f
jmp foo
1:

みたいに,スタックの頭に戻り番地をプッシュして,関数にジャンプする感じに書き換えられるのではないかと思いました.

ret もまぁ,

pop %ecx
jmp *%ecx

みたいに,適当に壊しても良いレジスタに戻り値を pop して間接ジャンプすれば大丈夫な気がします.

もちろん,本来一命令で済むものを,わざわざメモリ触った挙句命令数増やすのはバカバカしいので,実用性は無いわけですが.

アセンブラとか,x86 命令レベルのクロック数とか μOP (マイクロオペレーション) レベルの話とか全然わからない子なので,大きな勘違いをしている恐れがあります (ツッコミ期待)

最近の x86 は,インタフェースだけは x86 のままでも,中身は全然別物らしいです.一個の x86 的 CISC 命令が複数の μOP に分解されて実行されたり,逆に複数の命令が一個の μOP で実行できたり.

x86 レベルではレジスタは 8 つしかありませんが,たとえば Pentium 4 は,物理レジスタは 128 本あるそうです.なので μOP レベルでは,x86 命令からさらにレジスタ割付みたいなことが行われて,レジスタリネーミングとかいう最適化技術が使われていたりも.

アセンブリのレベルの見た目と,実際の速度が全然異なるようです.なので,よく 「高級言語なんて当てにするな,アセンブリリスト出して見ろ」 とか言う古いプログラマの人がいたりするようですが,最近の CPU はアセンブリ自体がある種の高級言語で,x86 命令が内部的には μOP に JIT されて,命令が分解されたりまとめられたり実行順序が勝手に変更されたり同時実行されたりレジスタリネーミングされてものすごいパイプライニングされたり,わけわからんことになってみたいなので,アセンブリ見ても本当に早いのかどうかはわからない気がします.

なんかとりとめなくなってしまいましたが,要するに niha さんとかが最近アセンブリプログラミングについて書いてるみたいなので,僕もなんとなく思いついたことを書いてみたくなっただけなのでした.

CPU って,ガチガチのハードウェアみたいに思われてますけど,現在の x86 CPU は,IA-32 っていう高級な CISC 命令セットを実行するための仮想機械 (VM) なんですよね.本当にガチのハードウェアは,μOP っていう,もっと細かいオペレーションを実行する,レジスタがいっぱいある RISC プロセッサです.そういう非常に複雑な二重構造になっているのに,あれだけの性能が出ているという奇跡.すごいなぁと思います.

# icc の最適化がすごくて,gcc とかは一生かなわないってのも,ある意味当たり前です.インテル社だけが,μOP の仕様や,それへの変換アルゴリズムなど,もろもろの内部の秘密テクノロジを知っているのですから,他のコンパイラベンダは,ベンチマークの結果から内部を推測して,最適化ルーチンを作るしかありません.そりゃ,一生追いつけませんよ

ということは,実は x86 命令セットに限らず,ppc とか sparc とか arm とか,他のプロセッサの命令セットもハードレベルで JIT して実行できるポテンシャルはあるのでは ? と.

インテルが μOP の仕様を公開してくれれば,それの上の LLVM みたいなフレームワークを被せて,ハードウェアとソフトウェアが協調して,高速に低レベル命令を実行する VM フレームワークみたいなのが作れて良いのになぁ,とか妄想したりも.




んでまぁ,ここまで巨大なブラックボックスの上で世界が動いているという現状を考えると,やっぱりフォーマルメソッドには一定の限界があるのかなぁ,とか思うわけです.

原理的には,全てをロジックで記述し尽くして,プロファイルとか泥臭いことしなくても,(実時間の許す範囲で) 可能な限りの最適化とか可能だと思うんですけど.企業が秘密を握っている限り,それは不可能.実験と計測の世界のままです.

やっぱり,プロセッサアーキテクチャもオープンになって欲しいというか,やはり究極的には,FPGA とかで,全て明確な世界に持ってくる必要があるのだと思います.アプリケーションの仕様に合わせて,逆算的に命令セットや,最適なハードウェアをロジカルに生成すると.まぁ,今のところは夢物語ですが.




あー,分岐予測か.確かに.call/ret の組が無いと,どこからどこまでが関数なのかわからないとか,そういう話なのかな ?

http://d.hatena.ne.jp/scinfaxi/20080711/1215724490

そういえば JVM とかも,手書きで作った変なパターンのバイトコードに対しては,あんまり JIT が効かないので,javac とかはむしろほとんど最適化しない,素直な構造のコードを吐くようになってるとかいう話があったような.つくづく x86 って,ハードウェアというよりは VM に近いよなぁ.




追記

敬愛している id:shinichiro_h さんと id:w_o さんに同時に dis られるという快挙を達成しましたので,大満足です!書いたかいがあるというもので,非常にうれしい.天にも昇る気分です (ドM)

http://d.hatena.ne.jp/shinichiro_h/20080711#1215786569
http://morihyphen.hp.infoseek.co.jp/log2/200807.html#07110
C 言語/コンパイラ/BinaryHacksTB:0CM:8 このエントリーを含むはてなブックマーク | livedoorクリップ livedoorクリップ BuzzurlにブックマークBuzzurlにブックマーク newsing it!

最近のコメント

リンク

このブログをリンクに追加する

最近のトラックバック

人生の残り日数

日本人男性の平均寿命は 28700日.

RSSフィード

カテゴリー