【急ぐべきか】OSXの64bit化はいつ?【待つべきか】

http://pc.watch.impress.co.jp/docs/2003/0626/apple.htm
「カーネルも64bitに対応している。G5は32bitと64bit、両方の命令を同じように高速に実行でき
る。カーネル内部で64bitレジスタが有効な部分では、64bitのメリットが生きる。また最適化は64bit
命令に関する部分だけではない。G5のアーキテクチャに合わせた最適化を32bitの部分でも行なう。た
だしAPIを64bit化しているわけではない」
「各アプリケーションが利用できるアドレス空間は32bitのままだ。個々のプロセスは4GBのメモリ空
間に制限される。しかし、システム全体では64bitのアドレス空間を活用可能だ。従って、多くのプロ
セスが同時に動作する環境においては64bitの意味が出てくる。また、演算ライブラリの中で64bitレジ
スタを使っており、そこでの高速化もある。たとえば平方根などは大幅な高速化が行なえる」
「現在のところ、32bitの現行APIを維持する方針だ。今後、その方針がどのように変化するかはわか
らない。しかし、APIの64bit化といった大きな変更を行なうときには、あらかじめきちんとアナウンス
する」
「先ほども話したように、我々は32bitアプリケーションの開発にフォーカスを当てている。Xcodeは
非常に素早く優れたアプリケーションを開発できる環境だ。しかし64bitアプリケーションへの移行を
促すものではない」


CPUは64bitになったものの、未だ詳細の分からないOSX64bit対応のロードマップ。
上記資料によればDarwinマイクロカーネルそのものは64bit化しているようだが
APIが64bit化しアプリが64bitアドレス空間を使えるようになるのはいつになるのか?

Opteron用WinXPも発表されている中、64bitアプリのサポートは急ぐべきなのか?
それとも32bitCPUであるG4もまだまだ現役である現状をふまえ、
アプリの64bit化は急ぐべきではないのか?

熱い技術論を期待します。

2bit化get!!

プロセスが複数たててうまく並列処理すれば、現状でも4Gの壁を越えられるわけね。

>>3
そういうことのようです。
カーネルが64bit対応しているというのがよく分からないんだけどね。
額面通り取れば、Darwinのマイクロカーネル部(mach+BSD)は
64bitネイティブサポートしているということだろうけど。

とりあえず、ロードマップぐらいは示して欲しいのだが。

300GBのHDDを全域メモリー空間にマッピングしてランダムアクセスするとか出来ないんですカ

>>4
64bit 化でメリットを受けるユーザーが少ないから
今のところは大きな変更はしなくていいと思われ

64bit の恩恵を受ける一部のアプリ用に 4G+ への
アクセス手段を用意してあげればよい

いきなり完全対応させると改良点が見つかったときに対応の早さが確保できないかも知れないからね。
クロックの高速化と共にじわじわと完全対応化していけばいい。
現在10.3には満足だし。

参考文献です。

セカンド・オピニオン 執筆＝大原雄介
http://pcweb.mycom.co.jp/column/sopinion.html
【第1回】〜【第31回】 64bit Rhapsody

PowerPCには触れてないようですが、参考にはなるかと。

>>6
昔あったfarポインタみたいでいやだなぁ。
farポインタは16ビットのOSで64KB以上のメモリをいじるポインタ。

　　　　　　.....宝の持ち腐れ.....

●PC Watchが、AppleのPowerMacプロダクトマーケティングプロダクトマネージャのトッド・ベンジャミン氏、
WWWソフトウェアプロダクトマーケティングシニアディレクタのブライアン・クロール氏へのインタビューを掲載していました。
インタビューを行なったのは「週刊モバイル通信」でお馴染みの本田雅一氏で、鋭い質問がバシバシされてます。
この中で、クロール氏は、G5は32bitと64bitの両方の命令が実行出来るため、カーネルも64bitレジスタが有効な部分は64bitのメリットが生きると説明しています。
しかし、

MacOS XのAPIを64bit化する予定は今のところなく、

Mac OS X v 10.3 Pantherでも、個々のプロセスは4GBのメモリ空間に制限されると述べたそうです。

OS, Photoshop, Illustrator, AfterEffects が対応したらG5買う。それまでは爆速OS9。

>>12
http://www.adobe.com/aboutadobe/pressroom/pressreleases/200306/062403PHOTOSHOPPLUGIN.html

>>6
PowerPC G5(970)は32bit/64bitをネイティブサポートしているので
おそらくはタスクスイッチの時に両モードを切り替えることになると思うのです。
32bitプロセスがタスクスイッチの割り込み時にOSに切り替わるときに64bitモードになると。

PPC970のマニュアルは読んでないのですが、少なくともItaniumでは
32bit/64bitを切り替えつつジャンプする命令がありました。

なので64bitアプリと32bitアプリが混在することには問題がないんじゃないかと思います。
>>1によるとすでにカーネル自体は64bit化の準備が出来ているようだし。

>>12
現行バージョンのAfterEffectsが既に爆速みたいだよ。

>>9
16bitの時はメモリの壁が 64KB だったから far ポインタを
使う必要のある人が多かったけど、今度の壁は 4GB だから
大多数の人間には無関係だと思われ

フォトショも８月に対応するらしいよ。
倍速になるらしい。

>>17
フォトショップの対応っていうのは>>1の演算ライブラリの
64bit化(64bitレジスタ化)を利用するって事なのかな?

コピペだよ。

コピペが64bitに対応!?

>>20
4GB を超えるデータもコピペ出来るようになったよ。

>>21　　　　　　　 ＿人人人人人人人人人人人人人人人人人人＿
　　　　　　　　　　 ＞　　　　な　なんだってー！！　　　　＜
　　　　　　　　　 　￣^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^Ｙ^￣
　　　　　　　　　　 _,,.-−..,,､　　　　　_,,−v--..,,
　　　　　　　　　／　　　　　''.v'ν　Σ′　　　　　`､,,.-'""`´""ヽ
　　　　　　　　 i' 　 ／￣""''`--i7　　 | ,.ｲ!,!,!,､ ､,､ Σ　　　　　　ヽ
　　　　　　　　 !へ/ -−、u.　　|' 　 　|.ﾉ-､ ' ` ` _`　| /!'!^iﾍ､,,、　　|
　　　　　　　　 |'' !ﾞ　i.oﾆ'ｰ'〈ｭﾆ!　　　iiﾍ~oj.`< o7 ,!'_,' ' ``_,,.. ､　l
　　　　　.　　　,`| u 　　　　.ゝ!　　　‖　 .j　　　 (} 'o〉 `''o'ヽ |,`i
　　　　　_,,..-<:::::＼ 　 ( 二> ／　　　　! 　_`-っ　/ |　7　　￣ u |i/
　　　　　. |、　 ＼:::::＼　'' ／　　　 　 　＼　''　／〃ヽ `"⊃　　,, 'v>、
　　　　　.. !､＼　　＼　,￣　　　　　　　 γ/|￣　〃　 ＼二-‐′／／`　

>>22 のコピペは 1KB 未満だね。よって漢字 Talk で十分なりよ。

アドビの発表がのってるとこ。無償プラグインでってリコンパイルとかさせるのかな？
なんやようわからん？
ttp://www.adobe.com/aboutadobe/pressroom/pressreleases/200306/062403PHOTOSHOPPLUGIN.html

ごめん。上のカキコは
>>18
さんへです。
インタビュー記事とかみてると、やっぱりプラグインで64bit演算ライブラリ
を使うようにするってことなのかな。すべての処理が倍早くなるわけでもないのか。

>>25
> "The future of Photoshop on the Macintosh
> platform is being geared around exploiting the power of Mac OS X and tapping the
> hardware performance of a new generation of G5 systems."

> The Photoshop plug-in technology and software enhancement will be made available as
> free downloads from Adobe's web site, when Apple ships its Power Mac G5.

このあたりの記述かな?

http://www.zdnet.co.jp/products/0306/25/nj00_pmgrint_2.html
これによると、演算ライブラリは他の記事によるとMath Libというライブラリの内部を64bit化するということだから
アプリ側では特になにもしなくていいっぽいな。APIは変わらないということでしょう。

とすると、Adobe自身が64bitレジスタを使って高速化するためのプラグインを作るという事かな。

昔に書いた話すけど，参考になるすか？
http://www.megabbs.com/cgi-bin/readres.cgi?bo=mac&vi=0046&res=563&fi=no

>>27
オタさん待ってましたw

> 3. 970搭載の機種とともにOSのみ64bit化して大容量メモリに対応。しかしBook Eプロセッサ
> 　が出る迄，64bit APIわ未公開（またわOS Xサーバー限定で公開）

Book Eというのは分からないのですが、このシナリオに近いって事でしょうか?

>>28
まあ，4番目としてPPC64でそのまま行く。。。というのもあるすけどね。

>>29
俺はBook Eというのを知らなかったので、そうなのかなぁと思ってましたが。
Book Eってどんなものなんですか?

Book EわIBMとMotorolaがAIM連合解体後に定めた，新しいPowerPCの命令セットす。
組込向けにコアと命令セットが拡張可能になっていることと，32-bitコードと64-bitコードが
モード切替無しに実行可能なのが特徴す。

調べてみた。

http://www.google.com/search?q=%22Book+E%22+PowerPC&lr=lang_ja

>>31
サンクスです。970はIBMが独自にPowerPCを64bit化したという認識でOKですか?
32bit/64bitはモード切替が必要?

>>33
もともとAIM連合が定めたPowerPCの規格わ64-bitのPPC64命令セットがあって，このサブセット
としてPPC32があったす。古くわPowerPC 620やIBMの64-bit POWER/PowerPCプロセッサわ，
このPPC64命令セットをサポートしているす。

http://pc.watch.impress.co.jp/docs/2002/1022/kaigai01.htm
この記事によるとPPC970もBook Eベースで切り替えは必要なしみたいですね。

>>35
それ間違いで，その後の記事で訂正しているす。
http://pc.watch.impress.co.jp/docs/2002/1107/kaigai01.htm
　　--------------------------------------------------------
　　まず最初に、先々週の記事の訂正から。「PowerPC 970はApple Computerに何をもたら
　　すのか」のPowerPC 970の記載には大きな間違いがあった。PowerPC 970にインプリメ
　　ントされているのは、Power4同様にPowerPCのオリジナルの64bitモードでBook Eの64bit
　　ではない。だから、32bitモードと64bitモードの切り替えは「Machine State Register」
　　の制御bitで行なう。モードbitによる切り替えは、x86系CPUで言うと「Extended
　　Feature Enable Register (EFER)」の制御bitで64bitモードに切り替えるx86-64に近い。
　　こういうばかな間違いをして本当にもうしわけない。
　　--------------------------------------------------------
優秀な方すけど，所詮PC畑のライターさんすから，こんなモノす。

>>34
サンクスです。PPC64とBook Eは違う命令セットなんですね。
970がBook Eベースって事は以降はシームレスに行けそうな感じですねぇ。
マニュアル読んでみようかな。

するとセグメントレジスタ云々ってのも間違い？セグメントレジスタは使えないの？使いたいのに！　嘘

>>36
（´Д｀;）!!
記事を鵜呑みにしちゃいけないですね。

結局、切り替えが必要なんですね。
ということはOS側のサポートがしっかりしてないといけないですねぇ。
サンクスです。

AIX は PPC64?

>>26　さん
そうかなと思ったんですけど。

MACオタさんたちの３０番代の意見交換を拝見すると、
やはり、プラグインで64ビットモードに切り替えるということ
だと思っていいんだと思います。

>>40
Power4のことがいいたいのだろうか? Power4は970の親玉だからPPC64だと思われます。

>>42
Yes. Thanx!!

しかしスレタイに反して? かなり低レベルな実装の話題になってますね。自分の知識ではついて
いけませんが、興味深いのでもっと続けて欲すぃ。

>>42
まぁ、PPC970のマニュアルとDarwinのソースを嫁って話なんですけどね。
なかなか骨が折れそうなんで…

64bitアプリを開発したことのあるunixプログラマの話とか聞きたいなぁ。

Macオタ氏はマニュアルとか読んだりしてるんですか？

ていうか、結局いつになるんだ？

>>45
64bitアプリといっても、でかいファイルをあつかうのに何も考えず mmap ()
するだけとかいうのがほとんどだぞ?
シミュレーション屋さんとかだと64bitレジスタフルに使ったりもするんだろうけど。

>>48
やっぱりそういうもんか。
前に解析中の遺伝子配列のファイルをいじったことあるけど
ATGCだけなのに数GBあったなぁ、そういえば。
そういうのは楽に扱えそう。

オタさんへ質問

PPC64は Machine State Register の制御ビットによって32/64bitモードを切り替えるとのことですが
Machine State Register への書き込みは特権命令ですか?

>>50
　　-------------------------
　　Machine State Register への書き込みは特権命令ですか?
　　-------------------------
特権命令す。

>>48
ま、そうだわな。

16bit→32bitの時は望まれてなったんだけどね。
RAM16MBはあきらかに16bit空間には狭すぎた。
今RAMはまだギガに手が届いた程度。この広さはまだ32bitに収まる上、CPUの速度からして十分に広い。
後5年先には少し狭く感じるようになるだろうが、しかしバス速度がそれほど増えない以上、
メモリの増設にそれほどの意味がない。

また、今の32bitCPUの速度で動画も扱える現在、個人需要を喚起できるような用途はないわな。

巨大RAMディスク作ちゃえばいいのよ。複数プロセスから共通ファイル群に高速でアクセスできる。

>>53
既にOSXは一度アクセスしたファイルはキャッシュしてるしさ。。
ちょっとキャッシュしすぎ、って気が昔から(NeXTの頃から)
してるのだが。。machの癖なのか?

1ファイルの最大サイズが増えてくれればそれでいいのだがなー。
今どうなってるんだっけ?
libcの

うっうっ途中なのに。。

fseekとかはlongだけど、NSFileHandleとか使えばunsigned long long
だから、今でも問題無いのだっけ?

>>54
ふぁいる丸飲みしなくて言いじゃん。
　おいしいとこどりする。

>>54
linuxとかもそうだよ。
普通、一般的なunixはみんなそうだと思うがなぁ。

DarwinのLARGEFILEの扱いがどうなってるかはよく分からない。
識者の意見求む。オタ氏はソフト系には詳しくないのかいな。

linux/unix系はそうなんだけどさ。。
machの場合こんなにswapoutしてまでキャッシュするのか?
って気になる時ない?

>>58
うーん。その辺のバランスが良くないのかもしれないけどね。
ていうか、swapfsをサポートして欲しいと思う。

>>59
swapfsって今みたいにswap領域をHFS+のファイルとして確保
しているのとは違うの?

>>60
ごめん、swapfsは別物かも。

スワップスペース(スワップ専用のパーティション)って事が言いたかった。
HFS+をスワップ専用に割り当てても結局swapfileを作るよね?
linuxのスワップパーティションってそうじゃないと思うんだが。

うまく説明できなかったので探してきたよ。

http://www.linux.or.jp/JF/JFdocs/Unix-and-Internet-Fundamentals-HOWTO/disk-layout.html

> 個々のパーティションは、(仮想メモリを実装する ために利用される) スワップスペース (swap space) か、ファイルを保持する
> ために利用される ファイルシステム ( file system) かのどちらかです。スワップスペースのパーティション は、連続した一連
> のディスクブロックとして扱われます。

つまり、メモリの延長として(ファイルシステムを通さずに)連続的にアクセスできるスワップスペースって
とりあえずOSXでは使えないよね。HFS+なりUFS上のswapfileとしてしかできないと思うんだけども。

なる。
けど、NeXTの頃の記憶を辿ると、swap専用のパーティションを
確保しなくても良いって発想の方が新しいというか先進的だった
気が。。

というか、swap(pager)関係を外部プロセスとして実装して
設計の自由度を高くするって発想が新しかったのか。。

だから、スワップ専用パーティションて言われても、今更・・・って
感じなのかと。
今はフラグメンテーションとかが嫌ならば、swap用のHFS+とかの
パーティション作るしか無いねー。
あとは、dynamic_pagerの引数工夫するとか。

>>63
なるほど。スワップスペースというのがすでにmachと矛盾しているのかｗ
でもこっちの方が絶対速いんだよねぇ。その辺の自由度が欲しいところ。

>>64
多分darwinのdynamic_pagerの代わりに、そういうpagerを
実装すれば可。そういう自由度はある(w

速度はねー。現在のハードウェアでこのオーバヘッドがどのくらい
影響あるのかって所で、この路線で話が進むと、
マイクロカーネルvsモノリシックカーネルの宗教論争の道を
歩みそうなので・・・ここいらで寝る。。

>>65
なるほど…もうちょっとmachを勉強してみます。おもしろいなぁ。

あたしはコンピューターの詳しい知識はまるっきり無いのですが
とりあえずスワップファイルができたらできっぱなしなのはどうにかならないんでしょうか。
アプリの側の問題なんでしょうかね？

10.2のFinderでアイコン表示で画像のプレビューを表示させる事ができますが、
これやってるとスワップファイルがガンガンできることに気づきました。
私iBookなんでメモリもHDDも少ない（と言ってもOS9の基準ではとても多い）ので
一日使ってるとスワップファイルがHDDの限界に達して再起動が必要になって困ります。
PMG5でメモリスロット８つというのは、むしろこのあたりの体質がパンサーでも改善される見込みが
ないって事なのかと思うと複雑な気分です。
メモリ保護と引き換えって事でしょうがないんでしょうか？でもフリーズすんのとあんま変わらない気も。

パンサースレどこいっちゃったのよう

>>67
それが64bit化となんの関係が? ってことでスレ違い。

ＯＳ�]やAPIを６４bit化するなら
いっそのことインテル対応版にしなよ
だめ？

>>70
64bit化することとx86アーキテクチャに移植することは全くの別問題だよ。独立した問題。
どちらかといったらAPIを64bit化してから移植を考えた方がいいと思うけどな。

>>71
別問題だから「いっそのこと」って言ってるんじゃない？

>>72
いや、大変なことをわざわざまとめる必要ないと思うんだが。

OSをフルに64bit化けすることは、何もメリットないとも思いますが？
あと10年立てばどうか分かりませんが、少なくともこれから5年間は不必要でしょう。
モジュール的に必要なとこだけ、64bit化けする&アプリが64bit使えるAPIを追加する
とかでいんでないですか？ インテル対応が移行を意味するなら死しかないでしょう。

>>73
合わなければWINをインストールできるとかIntelのCPUでOS11を走られられるとかっていう一種の保険があれば、
スイッチ派の購買意欲になるんじゃないかってことじゃ？

>>75
俺も移植は大歓迎なんだが別に急ぐべき事じゃないと思うのです。
G5になって速度的にはそれほど劣るものでもなくなったわけだし。
ていうかスレ違い下げ。

ってか64bitなんか必要ないんだけどね...
ただの宣伝だよ。この手のは新技術乗ってﾏｽﾀってのが大事だからね。
64bitってきいて”なんかすごそう”とかわけもわからず買うﾔﾂ多いしな。

>>77
無理じゃない？
こんな風に128bitとか煽ってても、売れなかったでしょ。
http://www.apple.co.jp/imac/processor.html
>従来のプロセッサなら32ビットもしくは64ビット単位で処理していたデータを、
>Velocity Engineは128ビット単位で処理します。

>>77
ただ64bitCPUなだけなら意味がないと思う。
今の時点で64bitが必要ないのは確かだけど3年後、5年後は分からないからね。
着実にAPIの64bit化、64bitアドレス空間のサポートを進めていくべきだと思う。

Xserveを本気で売りたいんだったらなおさら。
とりあえずPOSIX APIだけでもちゃんと64bit対応させて行くべきだね。

>79
>今の時点で64bitが必要ないのは確かだけど3年後、5年後は分からないからね。
ということは、G4デュアルあたりで、しばらくは十分使えるの？

>>80
>>1の記事から推測するにしばらくはなさそう。
ここでまた切り捨て騒動みたいな事は出来ないでしょう。
ノートにもG5はとりあえずのせられそうもないし。

あらためて、>>1の記事を読みました。
全体的な動作の中で64bitによる恩恵は一部で､結局
体感的にその速さは感じれなさそですね。

>>82
とりあえず4GB超の物理メモリ以外には大きなメリットはなさそうです。
今のところ「世界初の64bitパーソナルコンピュータ」は単なる宣伝ってとこですね。

32bitの命令でも内部的には64bitで実行されるってことじゃろ。
メモリにしか目が向かないとは、パパは悲しいぞ。

G5にはベロシティーエンジンスーパーチャージャーターボユニットテクノロジーは搭載されているのでしょうか

>>85
8087が

>>83
OSが64bitになってから名乗らないとね。

>>84
意味が分かりませんが。
いずれにしろ64bitレジスタ(整数の64bit化)や64bit仮想アドレス空間(ポインタの64bit化)は使えないと思う。

>>85
ヴェロは入ってるようですよ。

>>88
> いずれにしろ64bitレジスタ(整数の64bit化)や64bit仮想アドレス空
> 間(ポインタの64bit化)は使えないと思う。
64bitレジスタの方はコンパイラの修正だけで使える。今でも32bit仮想
空間内で64bit FPUや128bit AltiVecレジスタを使っている。
現状アドレス空間4GBと言っているがまるごと使えるわけではない。連
続して空いているのは2GB程度しかないし、プログラムがヘボで断片化
させると数十KBしか使っていないのにアドレス空間が枯渇することもあ
る。

>>89
え、でもFPUの方でしょ? 整数レジスタじゃないよね?
Darwinは2GBがカーネル用なのね。Linuxだと3:1が普通な気がする。

ちなみに参考資料
http://www.imit.chiba-u.ac.jp/services/ed_rsch/sr8000/manual/6a303022/html/m0060118.htm

windowsはLLP64なんだってね。long long が64bitで、longは32bit。
そんなところで変えるなよ。

いずれ出るG5搭載のXServeでは、鯖用パンサーは64bitOSとか
じゃないのかな？

いま問題なのは、G5入れると、廃熱のため、今の1Uのデザインには適さないということらし

>>90
long longやint64_tを使うだけ、PPC970専用コード生成を指示す
れば直接64bitレジスタを使う。PPC汎用コードならライブラリを
使う。
http://developer.apple.com/technotes/tn/tn2086.html

逆に（？）、Windowsの64ビット版って、32ビット版に対してという意味で
どうなってるんでしょう？
もうバイナリ実行環境としては別物？

エミューは、ダチョウより一回り小さく走るのも遅い。

プロセッサの寿命も開発速度も変わってきているわけだが
現状の２ＧＨｚのＧ５というのは、きっと16MHzのi386とか
386SXなんだろうな。
そして、「２８６で十分」という話も出てくるだろうし
３８６に搭載されたメモリ空間を活かした、仮想８６EMSとか、DOS4Gの
ようなものが普及してくるかもな。

だけど、32bitＯＳの上で32bitアプリがちゃんと動いたのはその後
結局クロックがその【百倍】ぐらいになってからだった。

・・俺はプログラミングもハード設計も知らんが、そんな事思いだした。

>>96
i386にはふつうにUNIXがあって、IBM PCでも普通に32bit UNIX使えたし、
そのころMacにもUNIXあったよ。そちらも当然32bit。
クロックが100倍って、GHz越えてるじゃん。いってること微妙にずれてるような。
Mac OSだけの話ならたしかにそういえなくもないけど。

>>94
微妙に何をいってるか分からないんだが…。

Itanium用の話であれば32bitアプリも普通に動くよ。
OSそのものは64bitで動作していて、割り込み時に適宜32bit/64bitモードを切り替えていると思う。
おそらくOpteron用も同じようなイメージだと思うが。

>>89
64bitモードへ切り替えは特権命令だっつってんだから
コンパイラ変えただけじゃ使えないでしょ。
少なくともOS X上じゃ。

連続して空いているって表現がいまいちわからんけど、
単にメモリに2GB、I/Oその他に2GB割り当ててるって
だけの話でCPUの制限と違うよね。

>>99
OSわアプリのロード時にコードのヘッダ情報か何かを見て32-bitアプリと64-bitアプリを
区別している筈す。
BSD layerで64-bitアプリが使えるなら、なんとかなりそうすけど。。。

>>100
あ、オタさんだ。
linuxは既に64bitアプリに対応していると思うんだけど
ELFヘッダのどこで区別してるのか分からないんです。
オタさんはご存じですか?

このスレの内容が一切理解できない俺ですが、
このままマック使っててもいいですか？

>>102
もちろんです。ここは物好きのスレですからｗ

>>101
一応、32-bitヘッダと64-bitヘッダが定義されているとのことす。
http://www.caldera.com/developers/gabi/2000-07-17/ch4.eheader.html

>>104
サンクスです。探したけど見つからなかったんですよね。
よりによってカルデラだけどｗ

e_machine メンバにバイナリの対象マシンを判別するコードが入っているようなので
ここをみて例えばIA-32なのかIA-64なのかを区別しているという事かな。

おたから
＞(ということでPowermac G5はしばらく独走となるようです)

AMDは無視かい…
普段少数派Appleが無視されっぱなしだからって…

ところでもし一般市場で64bit需要が高まる兆しがあればIA64とは別にIA32系に64bit拡張を行う系統の64bitなCPUも提供する選択肢も用意してる、って噂ですよね。
Intelにとっては出来るだけ選択したくない選択肢なのだろうけど。
ゲーム機市場では「64bit」のハッタリはさほど効果を示さなかったけど
（とは言っても今市場を支配してるのは「128bitマシン」だもんなぁ・・・）
パソコン市場ではどうだろう。或いはハッタリ以上の価値を認められる事になるのか…。

にしても、今のところはまだOpteronも高価ですね。
PPC970はデュアルプロセサ級におけるコストパフォーマンスではやや優位に立てるかも…。
でも、64bit需要においてコストパフォーマンスで勝負できる市場はそう広くは無いかもしれない？

・Xeon3.06GHz/Dualよりもアプリベンチでで2倍の速さという結果がでている。

・Athlon64はいいCPUかも知れないがDualにできなかったり、1.8GHzからのスタートだったり、
今までさんざん開発の遅れが目立っていたりとあまりいい印象はない。
今後の性能UPは見込めるのか？インパクトがない。

・Itanium2に至っては、130Wも消費されたんじゃ電気代が大変すぎ。ｗ

・OpteronもItanium2もPC用ではないし、比較するとすれば12月に出荷されるPOWER5だろうな。

・POWER5をダウンサイズしたPowerPC980や、FXの改良版であるPowerPC750GXも気になる。

・nikkeibpにあったけどPOWER5ってPOWER4よりも４倍性能向上してるんだね。POWER4+は３倍。
これでまたitenium2とは大きく差を付けた。さすがは世界最強技術力IBM。

>>99
64bitデータを扱うのに64bitモードに切換える必要は無いが...

>>107
Yamhillってヤツね。
新Itaniumも相当鳴り物入りで発表してるし、どうなるかわからんね。
ただ一つ言えることは「Yamhillの登場 = Itaniumの終焉」って事だけだね。

>>107-108,110
だから、OSX とはまったく関係ない話をすんな。消えろ。

>>112
別に他の64bit CPUのどうこうだって参考になるんだし
いいと思うが。特に>>107なんてそうでしょ。

他の *BSD の64bit対応状況とかはどうなんでしょうねぇ。

マイクロカーネルってmachだけだと思ったら、L4っていうがあるんですね。
GNU hurdもL4ベースに移植するらしいし。
どうなんでしょ。

64bit化まで生き残りましょう

●Mac Rumorsが、MacBidouilleにも寄せられた同じ情報筋の話しとされる
次期IBM PowerPC G5シリーズに関する内容を伝えていました。それによると、
既にプロトタイプが存在するらしいPower 5のシングルコアバージョンのPower
PC 980 (970はPower 4)がMacに搭載されるのは1年先で、現在のPowerPC 970
は2.6GHz〜2.8GHzまでに達した後、Steve Jobs氏が予告した12ヶ月以内に発表する
G5/3GHzは来年の末にPowerPC 980/2.6GHz〜3GHzで実現
　　(Geek.comは2004年の第三四半期と予想していた)され、
　　その後PowerPC 980は4.5GHz〜5GHzまで性能アップするようです。

そして、2005/2006には、0.065μメートルのPowerPC 990が6GHz〜10GHz、
2007/2008には0.045μメートルのPowerPC 9900が20GHz〜25GHzで発表
される予定のようです。(プレイステーション3の「CELL」は0.050μメートルなので、
IBMの設備的には問題無し)また、PowerMac以外の次期製品にPowerPC G5が搭載されるのは、
Xserveは今年の末頃、PowerBookは2004年の1月/2月、iMacは1年以上先になるらしい
と伝えていました。

とりあえずposixだけでも64bit化しないかなぁ。

DarwinてOpenでなかったっけ？　posixをハックれるんじゃ？
　

mach + BSD レイヤーまではオープンなので、ハックれます。

結局、今のMacOSってさ
MacOSって言ってるけど、
それはただの見た目だけで
じっさいは、NEｘTに乗っ取られただけだよね
基本になってるのはNEXT。
見た目いがいどこもMACOSじゃない。

このニュースで確信した
http://www.zdnet.co.jp/products/0307/09/ne00_avie.html

ずっとMacOSに携わってきたやつが指揮とってるならわかるが、
アップルでいま、NEXT作ってたやつがOSの製作の指揮とってるんだもん。
どうやったってMACOSにはならんな

クラシックOSにかかわってた開発者なんて
ほとんどアップルにのこってないんじゃないの？
おまいらが思っているMACOSの目指すところや理想なんて
アップルにはもうない。
おまいらそれでもいいの？

ド素人ｷﾀｰ!!

マコス

NICOSなら聞いたことあるよ。

「おまいらそれでもいいの？」じゃなくって「ぼくはそれじゃいや〜ん」だろ？

>>118-119
自前でやるには規模が大きすぎ。その辺はDeveloperであるAppleが率先して
やってくれないことには。

>>122
お前思ってるだけだろ。

>>127
そうだよねぇ。早めにロードマップぐらいは示して欲すぃ…

>>127
当然、一人では無理だが、Darwinのコミュニティー（よくしらんが）でそういう方向へ
当然にも進むように思うのだが．．．。技術情報等も含めて、Appleの協力無くしては、
やはり難しいだろうけど、Appleが将来的64bit化を想定していれば、Apple からも協力
はあると思うが。（OSXの最適化に忙しい）今のAppleがどこまでやる気があるかは???
http://developer.apple.com/darwin/

>>129
64bit化はどういうモデルにするのか (LP64 ILP64 LLP64 など) という
Appleにしか決めようがないことがあるから、Appleからの方針が発表されない
限りはどうにも動きようがない。

64bit期待age

64bitﾏﾀﾞｧ

http://ime.nu/developer.apple.com/darwin/
にあるML（darwin-development Mailing List ）で、64bitに関する議論があります。

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

あげぃ

age

（＾＾）

あぼーん

カーネルだけじゃなくて、OSのうわものや開発ツールなんかを
全て64bit環境にも対応させるとなると、膨大な作業量が発生するだろね。
当分(1年から2年ぐらい)は32bitアプリケーションオンリーの状態だと思うなあ。
先にlibcなどの基本的なライブラリを64bit化として出して、
GNUなどのツールを64対応させるのが先かな。64bit環境(8byteポインタの世界)
を満喫するためには、G5でLinuxを使うしかないね。

っていうかAPIが64bit対応じゃないと話に
ならんでしょ。

>>141

140 の書いていることがわかってるのか？

>>142
141はなにもわかっていないに100カノソ。
にしても、LinuxやSolarisですでに実現しているPOSIX APIの64bit化だけなら
ともかく、Cocoaレベルまで64bit化なんて気が遠くなるね。

オブジェクトハンドル!=アドレスってことにすれば、APIの大部分は
そのままでいけそうな気はするな。
オーバーヘッドはでかそうだけど、Cocoaはもともとそういうもんだし。

となると、Carbonはますますきつそうだな

G5にのっかってるプロセッサのマニュアルってどこにあるの？
IBMのサイトみてもないんだけど。

( ﾟ∀ﾟ )/ココジャダメカナー？シタノホウノPDFファイルナンダケド.....
http://www.apple.co.jp/powermac/index.html

Carbonは現状のまま凍結すればいいじゃん。

>>147
リファレンスマニュアルみたいなのがいいです....

これもな

64bit Mac OS=Mac OS XI
Xは32bitで終わりだったりして

面白いこというね。
10.5は64bitだというのに....
10.4は来年後半
PBG5も同時期
その後2005年に iMacG5＆ibookG5
低消費電力版G5が出るので心配なし
10.5はその時に出ます。

妄想ご苦労さん

まぁ、自分が経営陣だったら、たとえ不必要だと言われても、64bit化はするだろうな。
少なくともWindowsは32bitだし（64bit版はあるけど、少なくとも個人向けじゃないし）。
その点で誇大広告しやすいじゃん。技術的なデメリットについては全然詳しくないが（ｗ

>>154
64bit化もしてないのにアップルは64bitコンプータと連呼してますが、何か?

いやハードウエアは64bitやし。

PS2は128bit

>>156
「ハードウェア」が「64bit」?
面妖な…。

>>158
cpuはソフトウエアだったのか…

>>159
「ハードウェア」==「CPU」?
面妖な…。

>>160
cpuはソフトウエアだったのか…

>>160
cpuはソフトウエアだったのか…

ソフトウェアはハードウェアってことでここは一つ・・

保守

CPUはインタプリタ

ﾁｿﾎﾟユニット

( ﾟдﾟ)ﾎﾟｶｰﾝ

とりあえず64bit化するまで生き残っていてもらおう

祝！OS9没後６０１日！(w
9erは６０１日も経過してる古い環境よく使っていられるな(w
つーかMac OS捨て。NeXTのMac OS Xという皮被って復活ハァハァ♪
Carbonすら不要。64bitの恩恵受けるにはCocoaに汁！

何言ってるんですか、私のマシンは今だにOS7.5ですよ。

とりあえず　MacIIは6.0.7に戻した方が良いですか？

Carbonの64bit化がムリだとすると、MayaがCarbonで移植しちゃったのは失敗だったの？

いや、別に無理じゃないと思う。

LightWave 3DがXcodeで開発しなおされるようだけど、
これって64bit化と関係があるんじゃないの？
ttp://www.newtek.com/news/releases/01-06-04b.html

>174
俺には
「CodeWarrior+CarbonでだらだらやってるよりXcode+Cocoa使った方が性能良いから乗り換えます」
に見えるな。

従来はCodeWarriorを使ってたのですか。
すると、G5に最適化するためにXcodeを使いたい、
CodeWarriorのプロジェクトをXcodeに持ってくるのは結構手間がかかる、
折角だからこの機会にCocoaに書き直しちゃえ、その方がさっぱりするし
将来的にも開発管理コスト削減につながるだろう、
みたいな感じかも。

いっそ64bitはサクッと通り越して128bitOSに・・・
というわけにはいかないのかと。素人妄想

そんなにbit幅が必要なんて、きっと人知を越えた作業をしてるんでしょうね。

128bitといえばIPv6のアドレス長なので需要がいちおうあるし、
数値計算屋さんも使う可能性は高いだろうけど、一般的じゃないよなぁ。

たった２０年で8bit→16bit→32bit→64bitときているのだから
5年以内くらいには128bitも一般的になるかもと

HDDテラバイトだよーバックアップできないよーとか言ってるなきっと

脳内スマソ

その前に電子計算機と量子計算機の複合機が一般的になってるだろうな

２２世紀を見越したら最低でも１０２４ビットでないと・・・

具体的に64bit化のメリットを言えるシトわ何人いますか？

1byteCPUキボンヌ

>>183
馬鹿が買い換える

時代は64ビット！
32ビット以下のMacは糞！

>>186
とりあえず、藻前が64bitパソ＆64bit版XP買ってから言え。

いや。１ビットＣＰＵが未来的。

32bit以下って...

ハードとソフトの区別もできない荒らしタンですか？

>>188
どんだけ量子の重ね合わせ利用しても1bit（この場合ｷｭｰﾋﾞｯﾄか）じゃちとあれだ

libcの64bit化っていつになったら終るの？
実は全然やるきないでしょ？

Macオタは素人相手に偉そうだな。死ね。

>>192
素人以外を相手にすると、ぢつはただのスカラー電波にもとづくなんちゃって
科学者である本性がばれてしまうじゃないですか！！

以前にも、ちょっと物を知っている人に真実を突っ込まれて本性がばれてしま
い、心を病んだMACヲタはお家に引きこもって2chに出てこれなくなってしまっ
たんだよ！！

その後持ち前の厚顔無恥を発揮して、平然と2chに姿をあらわしたものの、
また本性が暴露されるのが怖くて、素人相手にしか偉そうにしなくなったのさ。

保守

NeXT STEPがベースだとはいえ、比較的最近作ったAPIなんだから
Appleは、APIの64bit化を想定していなかったのかな？

Microsoft、欧州委員会との和解交渉決裂
http://pc.watch.impress.co.jp/docs/2004/0319/ms.htm

マイクロソフト、EUとの土壇場の交渉が決裂--独禁法訴訟で和解不成立
http://japan.cnet.com/news/biz/story/0,2000050156,20064966,00.htm

ミネソタ州の対マイクロソフト集団訴訟で、証拠の公開はじまる
http://japan.cnet.com/news/biz/story/0,2000050156,20064985,00.htm

HotmailとMSN Messengerサービスにまたもや不具合--1週間で2度め
http://japan.cnet.com/news/media/story/0,2000047715,20064968,00.htm

罰金にWMPバンドル制限――EU、和解交渉決裂でMSに制裁へ
http://www.itmedia.co.jp/news/articles/0403/19/news020.html