コラム：Intel Macを考える（第3回）
〜　ソフトウェアを探る　〜

32bitか64bitか？　(2005/07/01)

Intel製CPUのアーキテクチャには、32bit CPUであるIA-32 (x86)と、64bit CPUであるIA-64の2種類があります。パソコン用に用いられているのはIA-32であり、Macに採用されるのもこれ、つまり32bit CPUです。PowerMac G5から64bit CPUを採用し始めていたMacは、再び32bit CPUへ戻るのでしょうか？

EM64T

2003年に米国AMD社がAMD64アーキテクチャのCPUを発表しました。IA-32との互換性を維持したまま64bitに拡張したアーキテクチャです。これを受けて2004年には、Intel社もEM64Tを発表。EM64TはAMD64とほぼ同じアーキテクチャであり、AMD64と共にx64と総称されます。

2005年現在、デスクトップ用CPUのラインナップにはEM64T対応CPUが増えつつあり、2006年のロードマップではEM64T対応が基本となります。

Memory Spcace

64bit CPUの最大の利点は、メモリ空間の広さです。32bit CPUの場合、OSとアプリケーションで4GBのメモリ空間を分け合っていました。しかし、64bit CPUの場合、既存の32bitアプリケーションごとに4GBのメモリ空間を割り当てることができ、64bitアプリケーションでは更に広いメモリ空間を利用できるようになります。つまり、大量の物理メモリを搭載して、それを活用できるようになります。

C MAGAZINE：x64の3つの動作モードを知る　(2005/06/27)

これはPowerPC G4に対するPowerPC G5の利点でもあります。Mac OS Xはカーネル部を除き32bit OSで、アプリケーションも32bitです。しかしアプリケーションごとに4GBのメモリ空間を利用できますし、Mac OS X 10.4 Tigerでは、対応アプリに限ってですが4GB以上のメモリ空間を利用できるようになりました。

ADC：Developing 64-bit Applications　(Update : 2005/06/01)

General Register

PowerPCなどほかのCPUと比較すると、IntelのIA-32には汎用レジスタが少ないという欠点があります。そのため、64bitに拡張する際に汎用レジスタを追加しました。これによって、プログラムの実行速度が向上するそうです。ただし、それは64bitアプリケーションに限ります。64bit対応OS上であっても、32bitアプリケーションでは追加された汎用レジスタを利用できません。

MYCOM PCWEB：64bit環境で試すコンパイラ - アセンブルコードに見るその実力　(2005/05/25)

C MAGAZINE：x64のレジスタ拡張　(2005/06/29)

IA-32

メモリ空間の広さと汎用レジスタの多さ。この２つを得るために、Intel MacのCPUはEM64T対応を必須とし、OSもアプリケーションもすべて64bit版にするという方針があり得ます。過去との互換性を考える必要がないので、Windowsの場合よりもむしろ簡単とさえいえます。

個人的にはこれを希望しますが、実際にはその逆。TigerのIntel Mac版は32bit OSであり、アプリケーションも32bit版のみになりそうです。根拠はApple社が公開している技術文書（下記）です。6月現在の文書には64bit対応にするための記述がひとつもありません。

既存のPowerPC版アプリケーションのほとんどが32bit版なので、その移植を容易にすることを優先した結果ではないでしょうか。PowerPC G4に対してG5があったように、IA-32用の32bit OSと32bitアプリケーションの環境を最初に構築し、将来的に64bit対応をオプション機能として盛り込んでゆくのだと思います。

ADC：Introduction to Universal Binary Programming Guidelines　(Update : 2005/11/09)

ADC：Universal Binary プログラミングガイドの紹介　(更新 : 2005/06/06)

Universal Binaryとは何か？　(2005/07/01)

PowerPCのMacintoshと、Intel CPUのMacintosh。その両方で動作するアプリケーションが、Universal Binaryです。まるで異なるCPUに共に対応できるのは、どのような仕組みなのでしょうか？

Multi Architecture Binary (MAB)

Mac OS Xのルーツは、NeXT社のNeXTSTEPというOSです。このOSには、Multi Architecture Binary (MAB)という技術が使われていました。MAB技術を使うと、複数のアーキテクチャで動作するアプリケーションを作成できます。NeXTSTEPの場合、Motorolaの68k、Intelのi386（現在のIA-32）、Hewlett PackardのPA-RISC、そしてSun MicrosystemsのSPARCに対応していました。そのため、Mac OS X登場当時から、Intel CPU対応Mac OS Xの可能性が予言されてきました。

現在でも、32bit版PowerPCと64bit版のPowerPC G5に両対応するアプリケーションを作成する場合、MABが使われています。Apple社による開発用アプリケーションXcode 2.1以降を使うと、さらにIntel CPUにも対応するアプリケーションを作成できます。近い将来には、64bit版のx64にも対応することでしょう。

つまり、Universal Binaryの元になっているMAB技術は、NeXT STEPの昔から、現在のPowerPC G5用アプリケーションに至るまで使い続けられてきた、実績のある技術なのです。

MYCOM PC WEB：OS X ハッキング!第3回　OS X for Intelの可能性　(2001/12/07)

MYCOM PC WEB：今、「Intel版Mac」についてわかること - ユニバーサルバイナリを検証する　(2005/06/20)

Application Bundle

Mac OS X用アプリケーションの多くが、実はフォルダであることはご存知ですか？controlキーを押したままアプリケーションをクリックしてメニューを表示し、「パッケージの内容を表示」を選んでください。Contentsフォルダが入った、アプリケーション名のフォルダウインドウが表示されます。このフォルダが、アプリケーションの正体です。

Contentsフォルダのなかに、MacOSフォルダがあります。そこに入っているファイルこそが、アプリケーションの心臓部。プログラム（コード）そのものです。あとは、画像・音声・文字情報などのUI要素と、稀に専用フレームワークやプラグイン。Mail 2.0.1の場合、総容量は約43.9MBですが、MacOSフォルダの中身は約1.8MBでしかありません。UI要素が約42.1MBを占めています。

Universal Binaryになったアプリケーションは、コードの量が概ね倍増します。しかし、倍増するコードは、Mailでは約1.8MBしかないMacOSフォルダのみです。アプリケーション全体では、ファイルサイズの増加は大したことにならないといえましょう。

なお、ContentsフォルダのなかにIntel CPU用のフォルダが作られる訳ではありません。MacOSフォルダのなかのファイルも、1つのままです。

Cocoa and Carbon

Mac OS Xのアプリケーションには、大別するとCocoaアプリケーションと、Carbonアプリケーションがあります。CocoaはNeXTSTEP由来のAPIで、CarbonはMac OS 9由来のAPIです。Mac OS 9とMac OS Xの両方で動作するアプリケーションや、両方のバージョンがあるアプリケーションは、まずCarbon APIを使っています。

伝統的に、Cocoaアプリケーションの開発にはApple社のXcode（旧Project Builder）が使われ、Carbonアプリケーションの開発には、Metrowerks社のCodeWarriorが使われてきました。Universal Binaryアプリケーションの開発にはXcode 2.1以降が必要なので、CarbonアプリケーションはCocoaアプリケーションとして作り直す必要があると誤解されがちです。

Carbonアプリケーションであっても、Universal Binaryにすることは可能です。Apple社の技術文書に、このことは明記されています。ただし、バイナリ形式にCode Fragment Managerを使っている場合は、Cocoaと同じMach-O形式に作り直す必要があります。

とはいえ、CodeWarriorは販売終了しており、Universal Binaryに対応する可能性はありません。これで作成したアプリケーションの場合、Xcodeで作り直す必要があるのは間違いありません。その際にCocoaで完全に作りなおすか、部分的にCarbon APIを使ったCocoaアプリケーションにするか、Mach-O形式のCarbonアプリケーションに留めるか。それは、デベロッパーの自由です。

Xcodeで開発したアプリケーションであっても、Cocoa APIのみを使っているものと、Carbon APIを使っているものとでは、Universal Binaryにするための作業量が違うそうです。特にMac OS 9用から移植したCarbonアプリケーションの場合、目的の機能を自前のコードで実現し、同様の機能がCarbon APIにあっても使っていないことがあります。コードの量が多いほど移植は大変になるはずです。

以上を鑑みると、Intel Macの登場によって、アプリケーションのCocoa化が進むように思えます。それでも、大型アプリケーションでは、Carbonのオブジェクトが名残のように残り続けると考えます。

ADC：Introduction to Universal Binary Programming Guidelines　(Update : 2005/11/09)

ADC：Universal Binary プログラミングガイドの紹介　(更新 : 2005/06/06)

Rosettaで何ができるのか？　(2005/07/01、更新 2006/01/22)

CPUをPowerPCからIntelのIA-32 (x86)に変更するということは、本来ならば、従来のMac用アプリケーションがすべて動作しなくなることを意味します。これではMacからWindowsに切り替えるのと大差ありません。そこでApple社はRosettaという機構を用意し、従来のMac用アプリケーションを動作させることにしました。

Compatibility

Apple社の技術文書（下記）によると、Rosettaは以下のプログラムをサポートしません。

1. Mac OS 9用、およびそれ以前のMac OS用のアプリケーション
2. Classic環境
3. AltiVec専用のプログラム（2006/01/10版で削除）
4. PowerPC用のスクリーンセーバー（2006/01/10版で追加）
5. システム環境設定の「その他」ペイン用のプログラム
6. PowerPC G4またはPowerPC G5を必要とするアプリケーション
7. PowerPCカーネルエクステンションに依存するアプリケーション
8. カーネルエクステンション
9. JNIライブラリを使っているJavaアプリケーション
10. Rosettaがサポートするアプリ内で動作するJavaアプレット、たとえばRosettaによって動作するWebブラウザ内ではJavaアプレットは動作しません。

リストにはありませんが、Intel Macにネイティブ対応するアプリケーションのプラグインも、ネイティブでなければなりません。PowerPC用のプラグインは動作しません。４番と５番がサポートされないのは、このためです。

ADC：Introduction to Universal Binary Programming Guidelines　(Update : 2006/01/10)

ADC：Universal Binary プログラミングガイドの紹介　(更新 : 2005/11/09)

PowerPC G4 Emulator

Apple社はエミュレータという用語を避けていますが、RosettaはCPUエミュレータの一種には違いありません。語弊を承知で換言すると、上記6番から、RosettaはPowerPC G4エミュレータといえます。

ただしRosettaは、仮想マシンという意味でのエミュレータではありません。PowerMac G4をエミュレートする訳ではないので、Mac OS Xのカーネル関連のプログラムや、ハードウェアに依存するプログラムをサポートしません。上記の非互換性リストは、それを意味しています。

CPU移行の障害と予想されていたエンディアン変換機能も、Rosettaが行います。もちろん、ネイティブアプリケーションのエンディアン変換は担当範囲外です。

QuickTransit

詳細なエミュレート（Apple社曰く、コード変換）の仕組みは、明かされていません。しかし、手がかりはあります。下記の記事にあるように、Transitive社の開発したQuickTransitがRosettaに使われていると考えられているのです。

PowerPC用のコードが使われた場合、Rosettaはそれをx86用のコードに変換してCPUへ渡します。同時に、変換後のコードをキャッシュしておき、次に同じコードが使われた場合に変換済みのコードをCPUへ渡します。もっとも、これだけなら、古いモトローラ68k CPU用プログラムをエミュレートしているPowerMacの第二世代ダイナミックエミュレータと同じです。

QuickTransitと同じであれば、Rosettaは変換済みのコードを最適化し、同じタスクをより高速に実行できるようにしています。いわば、プログラム作成時にコンパイラが行っているような最適化処理を、プログラム実行時に瞬時に行っているのです。最適化の処理時間が低速化に繋がりかねませんが、よく使われる１割程度のコードに限って最適化することで、全体的には高速化を実現します。

CNET Japan：アップルのコード変換ソフト「Rosetta」をめぐる期待と不安　(2005/06/09)

後藤弘茂のWeekly海外ニュース：x86 Macintosh移行のカギを握るTransitive　(2005/06/21)

Classicアプリは使えるのか？　(2005/07/01)

上記「Rosettaで何ができるのか？」で述べたように、Intel MacではClassicアプリは使えません。Mac OS X上での直接の実行はもちろんのこと、Classic環境内での実行もClassic環境が動作しないため不可能です。

The Classic Environment

Classic環境が動作しない理由は公表されていません。しかし、RosettaがCPUエミュレータであることが理由でしょう。Classic環境は、Mac OS 9の動作する古いPowerMacのハードウェアエミュレータではありません。ハードウェア依存の要素はアプリケーションから巧妙に隠されていますが、処理速度を優先したため、その隠し方は不完全です。Apple社も、Classic環境の登場当時に、これをエミュレータとは呼びませんでした。

Virtual PowerMac G3

ClassicアプリをIntel Mac上で動かすためには、現在のClassic環境よりも完全なハードウェアエミュレータが必要です。PowerMac G3をエミュレートする環境を作成すれば、Rosettaとの併用を考えても都合が良いでしょう。Classic環境と比べて処理速度が低下することは避けられませんが、Mac OS 9当時のパソコンと比べれば十二分に速くなっているので、実用上は問題ないはずです。

PowerMac G3を完全にエミュレートすることの困難さは、その上で動作させるMac OS 9を同エミュレータ専用版としてしまうことで、多少は軽減できることでしょう。Classic環境で動作しないハードウェア依存型のアプリケーションが使えるようになる余録も期待できます。

MoM (Mac-on-Mac)

Linux上で仮想Macintoshを動かすソフト、MOL (Mac on Linux)があります。これをMac OS Xに移植したものが、Mac-on-Macです。Mac OS X、Mac OS 9、Linuxなどを動作させられます。現在は未完成ですが、このソフトが進歩すれば、ClassicアプリをMac-on-Mac内で使うことができるようになるでしょう。

ただ、2007年にPowerPCベースのMacintoshが終了するまでに間に合うとは限りません。また、業務で使う人にはとっては、より安心感のある選択肢が必要です。Macintoshのハードウェア仕様を知り尽くしているのは、やはりApple社なのです。

その他のMacエミュレータ　(追記 : 2006/07/17)

PowerMacエミュレータ：SheepShaver(Wikipedia日本語版、日本語による解説)

68k Macエミュレータ：Basilisk II for Mac(日本語による解説)

Please!

PowerMac G3エミュレータを開発し、現在のClassic環境と比べて遜色のない使い勝手を実現する。この困難に挑戦せねばならない理由をApple社が見いだしている様子は、今のところありません。Intel MacでClassicアプリを使えるようにするという発言は、一度もありません。

Classicアプリを今も使っていて、今後も使い続けたい。そのような方は、Apple社に声を届けてください。米国では、そのような需要は少ないのかもしれません。

アップル社のフィードバック窓口：Mac OS Xフィードバック

私の行ったフィードバック：IntelベースのMacにもClassic環境を望む　(2005/06/08)

For English

米国Apple社に直接フィードバックすることも、有効な手段と考えます。

米国Apple社のフィードバック窓口：Mac OS X Feedback

私の行ったフィードバック：We wish to have the Classic environment for the Intel based Macintosh computer.　(2005/07/12)