Appleのせいでバイトオーダーの話再燃

まあ、それほど速度差のないものをエミュレーションするわけですから「そこそこ動く」ものが精一杯でしょう。そういう努力をしているという点は評価できると思います。

※wikipedia.orgへのリンクは以下の方がよいようです。
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%B3%E3%83%87%E3%82%A3%E3%82%A2%E3%83%B3

>>anonymousさん
リンクのURL文字化けしてましたね（何でだろー?）
直しました。どうもすみません。

冒頭の略称ですが、「Mactel」も使われているようですね。やはり微妙に苦しいので普及するかどうか、わかりませんが・・・、あ、いや、マシンではなく :-)

"Macintel"はゴロが悪いですが一応"int"は共通なのに対して、"Mactel"は一個も合ってないですね　:-)

エンディアンの解説が曖昧ではありませんか？
解釈によっては逆の意味にも。

たしかに。そういえば、メモリマップで0を上に書くか下に書くかも違うことがありましたね。今回の問題の本質は「バイトオーダーに差異があること」ですが :-)

あ、ほんとだ。ダンプリストで上位の桁に上位にデータが来るのがビッグ～というつもりで安易に書いてしまいました（ｽﾝﾏｾﾝ）。ちょっと直しました。

うむむ、本文を直すと必ずリンク部分のURLが文字化けする（直しましたが）。なぜ、半角英字なのに化けるの？

Appleの「せいで」とわざわざ書くというのは
エンディアンは業界の腫れ物に触るようなタブー話なのでしょうか？
「〜せいで」というのはあまり良い意味では使われない言葉ですが

特に深い意味はなかったんですけど、強いて言うと、Appleがこの件をあまりオープンにしないで「移行は無問題」と言い続けてる姿勢に対して無意識のうちに皮肉入れてしまったのかもしれません。

実際にMacを使ってみるとわかりますが、さほどエミュレーションのパフォーマンスは必要ではないんじゃないかなと。あと、実際にRosettaに触れた人の話からすると、さほどパフォーマンスは悪くないようです。

あー、本田さんどうも初めまして（記事はいつも読んでます）。自分はMacはPlus→Quadra700と使ってました（古っ）が、確かにGUIのサクサク感は、CPUのパフォーマンスでは上のWindows機より全然良かったですね。
まあ、ただベンダーの都合でCPUアーキテクチャ変えるからには、ユーザーにはパフォーマンスがものすごく良くなるという見返りがあってしかるべき（68040→PPCの時はそれがあった）ですが、今回はどうなんだろうか？というのはありますね。
個人的にはVMware環境でWindowsと同じマシンをシェアできるのであれば、是非Mac環境に戻って見たいですね。
#話し変わりますが、１８日のエントリーで書いた個人でExchange使うパワー
#ユーザーとはもちろん本田さんのことです。別会社の媒体（PCWatch）
#だったのでリンク張るのをちょっとはばかっただけで(名前を出さなかったことに)
#他意はありません。

トランジスタのスイッチング速度よりも、消費電力の大きさがCPU性能の上限を決める時代になると思います。そうなったとき、今見えている予定からするとインテルの方が遙かに上、というか先のロードマップが見えています。
だから継続的な成長のためにCPUのチェンジは必要です。68kからのトランジション時と違うのは、準備期間が今回かなり長く取られたこと（5年ぐらい前から？）や、エミュレーション技術の向上、CPUの余剰パワーなどの事情が違いますよね。一部のクリティカルなアプリケーションさえネイティブになっちゃえば、たぶん困りませんよ。
という僕は、PMG5ユーザーです（汗
Tigerになって、標準のアプリがかなり使い物になってきたのも大きいかな。

　「バイトオーダー変換が大問題（？）」とのことですが、一応XCHGとかBSWAP命令一発で済みますので、そんなものはあまり大きな問題ではない、ような気がします。
　 エミュレーションする上で一番大きな問題は、やはりPowerアーキテクチャと比べて圧倒的に少ないレジスタではないでしょうか。
　Intelの方がレジスタが少ないので、PowerPCのレジスタはどうしてもメモリ上にマップしなければなりません。ということはPowerPCではレジスタ間で済む演算が、必ずメモリアクセスを伴う、とんでもなく遅いものになると思われます。だからメモリアクセスに比べたら、BSWAPやXCHG命令１つ増えるぐらい（この場合のオペランドはレジスタでしょうから、１、２クロックか）、大したことないような気がします。
　で、実際どのくらいの速度になるのかよく分かりませんが、うまくいけば、（両CPUが同じ程度のクロックとすると）元のPowerPCの10分の1から20分の１くらいの速度になるのではないでしょうか（つまりPowerPC１命令がIntelの10命令かそこらか。メモリアクセスがあるので、命令数比よりも悪くなると思う←これはかなりベストなケースだと思う）。動的なコード変換すれば、5分の１も夢ではないかもしれませんが、1命令ずつ解釈→実行ではそうそう期待もできないような。
　でもまぁ、動くということが重要でしょう。長ーーーい目で見てあげましょう。

まあ、確かにLOAD、STOREごとに数クロック追加だと大問題というほどではないかも。だけど、レジスタ数が少ないということは相対的にLOAD、STOREも増えるということで相乗効果で結構厳しいのではないでしょうかね。トランスレーション（動的コンパイル）の最適化技術がどの程度かにもよりますが。
いずれにせよ、Mac環境の場合、少数のキラーアプリケーションさえ移行してれば、ほとんどのユーザーを満足させられるということは言えそうですが。

（う～む、anonymousというハンドル名には無理があったか^_^;）
勝手な推測ですが、おそらく、Rosettaは１命令ずつ解釈→実行するのではなく、PowerPCコードを仮想コードに見立ててIA32にJIT（Just In Time）コンパイルするのだと思います。だから最初の一回は遅いけれど、２回目以降は速くなると。今日のJavaや.NETみたいなものですね。
元が現実のCPUですから、JITにかけやすい作りではないでしょうが、レジスタが少なくても、他の処理は速いと予想されますから、うまくJITコンパイルできるのなら、そこそこの速度では実行できるように思います。ただ、そうした場合でも、メモリ上のデータを扱う場合には、必ずバイトオーダーの変換命令が必要になるというのが問題ですね。
もっとも、ファイル操作とかキー入力といったオペレーティングシステム側の処理は速度差はあまりないでしょうから、現実的なアプリケーションの多くはそれなりに使えるのだと思います。
それにしても、結局ネイティブIA32ベースにするということは、今後64bit（IA/AMD）化でパフォーマンスを最大化するためにはふたたび「再コンパイル」を要求することになるんですよね？　ちょっと「今時？」という印象があります。

レジスタ数が少ないのはトランスレーションの時よりもエミューレーション（最初の実行）の時の方が影響大きいでしょうね。
ただ、元のオブジェクトでPowerPCのレジスタ使い尽くすような最適化が行われてるとトランスレートした時でも一部のレジスタをメモリに退避することになるので、パフォーマンス劣化は無視できないかも。
EM64Tは採用しないのでしょうかね？Pentium-M系だと今はEM64Tはないですけど、来年あたりにはどうなんでしょうか？64ビットのコードを32ビットにトランスレートするのはかなり厳しそうな気が。
Itanium系が当時の目論見とは裏腹にハイエンドニッチになってしまったことでAppleも結構悔しがってるんじゃないでしょうか。Itaniumなら他CPUのバイナリをトランスレートしてもかなり高速で実行できそうですし。

たとえホストのIA32のほうがレジスタが多かったとしても、インタプリタ型のエミュレーションではPowerPCのレジスタを直接ホストのレジスタにマップするのは事実上不可能ないし無意味です。

>>furukawaさん
これは、PowerPCとIA32に限ってはということなんでしょうか？それとも他命令セットのエミュレーション全般のお話？

インタプリタ型のエミュレーションは、ほぼすべてが命令を読みだしてテーブルジャンプの繰り返しという実装になっていると思います。
PowerPCの場合ですと1命令は32ビットですので、数bitは削れるとしてもこれを直接テーブルのインデックスとするのはほぼ不可能です。
また、例えばオペランドとオペコードで別々のジャンプテーブルを使うことも考えられますが(ソースレジスタ2本で10bitと、オペコードとデスティネーションレジスタで10数bitなど)、テーブルサイズは現実的になるものの、非常に遅い間接ジャンプが二つになるためほとんど無意味です。

ものすごく遠隔レスですが^_^;
http://www.itmedia.co.jp/news/articles/0507/14/news055.html
にあるとおり、"MACTEL" が「公式」のようですね。
何しろ Apple が商標登録(#78644706)してます :-)
（MacIntel も誰かが登録してますけど）