Leopardが実は32bit O ..
2:名称未設定
07/11/14 21:38:30 jAWzhafe0
↑ブラクラ注意
3:名称未設定
07/11/14 21:40:11 8wVvTz1W0
いや別に普通のサイトだけど
4:名称未設定
07/11/14 21:41:11 aH/5ydbm0
ブラクラってwwwww
5:名称未設定
07/11/14 21:41:51 y1copFlt0
単発質問スレが乱立する方が由々しき問題
↓再利用法
6:名称未設定
07/11/14 21:45:19 Di3AIZ8X0
この内容でなんでこんなスレが立てられるか説明してくれw
7:名称未設定
07/11/14 21:45:34 HNco0OfL0
無知のくせに「64bit＝スゴイ」とか思ってる短絡思考のバカはもうウンザリ
8:名称未設定
07/11/14 21:45:56 1TzKH+Eg0
URLﾘﾝｸ(hosted.met-art.com)
9:名称未設定
07/11/14 21:48:55 I40C5tN+0
elleさま(;´Д`)ﾊｧﾊｧ
10:名称未設定
07/11/14 21:54:52 Di3AIZ8X0
海の向こうの噂サイトの「ググったけどよくわかんねぇから教えて」程度の質問スレッドで
噂だなんだと言ってこんなスレを立てれる根性は尊敬しなくもないw
11:名称未設定
07/11/14 22:04:16 a6rvjfYS0
ドザチョンのバカは底なしですから
12:名称未設定
07/11/14 22:18:13 yavRRonl0
俺のPowerBook G4で動いてるから32bit OSで間違いないな。
13:名称未設定
07/11/14 22:37:15 6Ab3p0ug0
G4のデュアルは32bitx2で64bit !?
14:名称未設定
07/11/14 22:47:55 qQepEI290
一応G4でも64bit処理は出来るがわざわざそんな事はしねーよな
15:名称未設定
07/11/14 23:21:12 LtvWaKQ+0
>>13
正確には64bit「級」かな
16:名称未設定
07/11/14 23:48:45 9th3ZRFG0
33bit
17:名称未設定
07/11/14 23:58:40 wBnF+uOO0
脳天直撃
18:名称未設定
07/11/15 00:09:22 0OuJa4Xx0
好きにしてくださいwwwwwwwww
32/64bit問題なんていう恥ずかしいバグはありませんwwwwwww
19:名称未設定
07/11/15 00:26:42 gZ75je9D0
bitたけし
20:名称未設定
07/11/15 00:28:55 Wui+tUNt0
>>7
x86 の長年のネックだった GPR が増えるんだから凄いべよ。
21:名称未設定
07/11/15 02:01:16 EeMrHmUo0
まあカーネル自体が32bitプロセスなのは間違いない
% file /mach_kernel
してみりゃ分かるが
Leopardは64bitに対応したAPIが増えただけで、別にTigerから特別大きく変わった訳じゃない。
4GB以上のメモリ空間が使えて64bitモードでCPUを動かせる以上
一般ユーザや開発者にとってカーネルが32bitだろうが64bitだろうがどうでも良い話ではある
22:名称未設定
07/11/15 04:57:45 Y44Cgnwf0
その昔Win32Sという16bit Windowsで32bitAPIが動かせるしくみがあったんだよね。
それと同じだと思えばまあいいんじゃないの。
AppleのLeopardの宣伝文句はやりすぎだと思うけど。
23:名称未設定
07/11/15 07:45:56 T2FrZuve0
使えるメモリが増えただけでもイイ。
32bitアプリが殆どの現代、孤高の完全なる64bitは無用では？
24:名称未設定
07/11/15 08:27:21 3jRr32UQ0
windowsは遅れてますね
25:名称未設定
07/11/15 09:47:25 Y44Cgnwf0
>>24
具体てきにはなにが？
26:名称未設定
07/11/15 09:50:31 ybOHEjph0
Win32Sものすごい虎馬
これからはWin32の時代だぜ！という宣伝文句に踊らされて
アプリ全部32Sで作り直したらバグ地獄
27:名称未設定
07/11/15 10:29:37 C6Iu9C680
kernelが32bitなのはars technicaのレビューが出た時点で分かってたと思うが
28:名称未設定
07/11/15 12:43:53 LOy5WNgj0
>>19不覚にもワラタ
29:名称未設定
07/11/15 20:48:39 hXCIGa1t0
やっぱり真の64bitOSじゃないのね。
Windows9xがカーネルのほとんど32bitなのに、ごく一部に16bitコードが
含まれただけで16bit OSだと言うやつがいたが、そいつに言わせれば
カーネルが32bitのLeopardは完全な32bit OSなのだろうね。
30:名称未設定
07/11/15 21:08:29 DiLVRWoB0
まあ64bitカーネルになってたら今頃はドライバが全く無くて大変だっただろうな。
広告の文言以外は堅実な選択だな。
31:名称未設定
07/11/15 21:16:06 TMHoKTA70
よく分からんのは、未だ32bitカーネルである事と、
URLﾘﾝｸ(developer.apple.com)
"Mac OS X supports both 32-bit and 64-bit drivers."
とか
URLﾘﾝｸ(www.apple.com)
＞さらに嬉しいことに、新しい64ビット対応ドライバにアップグレードすると、32ビットアプリ
＞ケーションのスループットも向上します。
とかの記述との関連性。
この「64ビット対応ドライバ」って、
URLﾘﾝｸ(developer.apple.com)
の記述にある「DMA関係をupdate」したドライバってことなのか？
32:名称未設定
07/11/16 11:06:32 z0DH8S830
>>31
ドライバーにはカーネルドライバーとユーザーランドドライバーがあるよ。
33:名称未設定
07/11/16 20:08:08 DcLlPhOB0
無知どうし罵り合うスレはここですかw
34:名称未設定
07/11/16 20:25:19 lrie6kYE0
安い煽りは要らないから、貴方の溢れんばかりの知識をここで
存分に披露して下さいな
35:名称未設定
07/11/16 22:56:12 9jrKGH8Y0
はい。結論。
Leopardは真の32bit OSでした。
36:名称未設定
07/11/17 00:39:35 boskS6O+0
まあ、上層レイヤは64bitだからどっちでもいんじゃね？
それより32bitマシンが32/64bit Universalアプリの64bitバイナリを開こうとして華麗に落ちる方が問題だよなあ
37:名称未設定
07/11/17 09:57:13 4a9IpoNr0
>>36
そんなこと起こる？うちの CoreDuo マシンで XCode 開いてもだい丈夫だけど。
38:名称未設定
07/11/17 17:44:42 boskS6O+0
Finderから開くと大丈夫だけど、ターミナルから開くと落ちる。
それとも俺がなにかミスってるのかなあ
39:名称未設定
07/11/17 22:12:53 tBkOtQNH0
やっぱり32bitなんだね。
40:名称未設定
07/11/17 22:34:15 FOdztiNd0
32bit級。
41:名称未設定
07/11/17 22:47:02 RX38yaFG0
Kernel processes will still run in 32-bit memory space.
42:名称未設定
07/11/17 23:33:04 GZnrhasK0
iMacもWindowsみたいに認識してるメモリーは3GBだけなの？
43:名称未設定
07/11/17 23:47:17 J88eC3sZ0
OSごと落ちるのはドザのお家芸
44:名称未設定
07/11/18 00:04:35 i3s2PxJ10
>>42
旧機種はintelのチップセットの制約で3GB
OS Xの制約ではない
45:名称未設定
07/11/18 00:46:45 zIdZozCC0
カーネルが32bitだと他の部分で足引っ張るってことやっぱりあるの？
46:名称未設定
07/11/18 01:13:20 Av1EOJmJ0
>>38
それ、ちゃんとFeedbackしといて。
URLﾘﾝｸ(regist.apple.co.jp)
俺が10.5.3くらいになってからLeopardを導入する時までに、そういう地味な問題は
Fixしておいて欲しいw
47:名称未設定
07/11/18 01:30:31 HhFI8v3k0
ドザって1bitらしいね
48:名称未設定
07/11/18 03:35:16 xvKPV8GY0
またSHARPのミニコンポみたいな事言って…
49:名称未設定
07/11/18 03:40:54 N4fjTTux0
NINTENDO64でLeopardは動きますか?
50:名称未設定
07/11/18 06:37:33 LxsxGvmb0
>>43
kernerlモジュールに不具合があればOSごと落ちる可能性はWindowsでもOSXでもFeeBSDでもLinuxでもSolarisでもなんでも同じようなもの。
51:名称未設定
07/11/18 07:51:15 9M4JqGBn0
>>47
ポーク…じゃねえか？
52:名称未設定
07/11/18 12:20:07 62d1X69g0
今はいいけど
来年以降Nehalemが出てから完全64bitOSにして欲しいな
この調子なら68kからPPCに移行期みたくいつまでたっても32bitのコードが残りそうで
足かせになるぞ
53:名称未設定
07/11/18 12:46:11 PxWpUj+40
64bitのコードしかネイティブに実行できないCPUが出ない限り別に足枷にならないから。
32bit環境の問題はプロセス当たりのメモリ空間のみで、
16bit->32bitや68k->PPCの移行の時とは違って速度の問題は無い。
まあx86の場合論理レジスタが増えると言うおまけはあるけど。
54:名称未設定
07/11/18 12:47:58 YFIOeH3f0
gdgd言う奴は、カーネルが64bitじゃないと何が困るか書いてみろ。
55:名称未設定
07/11/18 13:49:13 2ZjCCQ2T0
>>54
仮想メモリが 32bit で動いているならアドレス変換のオーバーヘッドがあるね
ページサイズも 4KB なんでしょ
56:名称未設定
07/11/18 13:53:59 2ZjCCQ2T0
>>54
あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
当然速度が速くなる
57:名称未設定
07/11/18 14:11:13 IxLochVz0
まあ、レジスタ増えてもそれを使ってなきゃ意味がないから、
64bit用に再コンパイルが必要だけどね。
ソース手に入れられないメーカー品は対応してくれるまで待て。
既存のソフトが早くなるわけじゃない。
58:名称未設定
07/11/18 14:19:17 2ZjCCQ2T0
kernel の話ですよ?
59:名称未設定
07/11/18 14:32:54 IxLochVz0
あと、命令を64bitにすると長さが2倍になるから、
その分メモリの使用量が増えてしまうね。
60:名称未設定
07/11/18 14:33:23 thinLfml0
PPCG5がでたときに
「CPUは64bitでOSは32bitだけどスピードのロスはないよ」
って言ってたよな。あれも妄想ベンチ？
61:名称未設定
07/11/18 14:38:15 X4aNm9TT0
まぁ、32bitでも64bitでも、普通に使うぶんには何ら問題ないわけだし
Leopardが便利きわまりないものであることも、何ら変わりはない、、と。
62:名称未設定
07/11/18 14:46:07 xb1Ii9wH0
>>60
PPC は x86 とちがってそういうものらしい
63:名称未設定
07/11/18 16:15:14 2ZjCCQ2T0
>>61
痘痕もえくぼって奴だな。
64:名称未設定
07/11/18 16:40:50 2ZjCCQ2T0
>>59
Instruction の長さなんて誤差の範囲じゃないの。
バイナリのサイズなんて頑張っても数十 MB だからね。
一方で long とポインタの長さが増えるのは確かに
メモリを消費するけど、物理メモリ搭載量も以前とは
比較にならない程増えているし、アドレス空間も広大。
メモリ帯域の事を考えても、引数をレジスタ渡し出来る
メリットに比べたら微々たるもの。
65:名称未設定
07/11/18 17:00:42 Mcgcg9Gf0
>>64
でもヒープなどは64bitにすると、オーバーヘッドは無視できないよ。
もちろん使用メモリが倍になっても、最近は乗り切れちゃうけど
個人的には、userlandは32bitで十分と思う。64bitが必要なのはごく一部
ただ、32bitのメモリ食いアプリを複数動かせる64bitOSは歓迎。
なんとまあ、普通の結論ですなｗ
66:名称未設定
07/11/18 17:01:23 a3QfhndJ0
ID: 2ZjCCQ2T0 はさっきから何を頑張ってるだろう
67:名称未設定
07/11/18 17:23:21 qtuNFTC60
>>66
>何を頑張ってる
Vistaを64bitでインストールしてしまい後悔を隠したい、とかでないことを期待。
68:名称未設定
07/11/18 17:58:25 2ZjCCQ2T0
>>66
おかしなレスが飛び交ってるから、突っついてるの。
例えばさ、『ヒープを 64bit にする』って表現として意味不明じゃん。
普通はそういう風には言わない。64bit ってデータ長かアドレス空間の
大きさを指すのが普通じゃん。LP64 にしても使用メモリは倍になんか
ならないし、ちゃんと分かって書いてるのか心配だったのね。
まあこの板で似非技術用語を指摘しても意味ないかもしらんけど。
69:名称未設定
07/11/18 18:02:14 ndzXdl+y0
正直なところ、Intelの64bit実装はAMD64の劣化版なので、フル64bitにしなかったのは
懸命な措置だと思うよ。
>>56
>あと x86 に限った話だけど、64bit にするとレジスタ数が一気に増えるから
>当然速度が速くなる
これは嘘。確かにレジスタの数は多いが、現在のIntel版64bit実装だと、5個
ぐらいの汎用レジスタを同時使用するとストールするよ。AMDなら全然問題なし。
70:名称未設定
07/11/18 18:09:40 zIyuf+DC0
お前ら今ごろ何言い合ってるんだよ。圧倒的に64bitの方が高速だろ。
もっともLeopardは32bit OSだから恩恵も無いがな。ｗ
URLﾘﾝｸ(jndb.pc.mycom.co.jp)
71:名称未設定
07/11/18 18:17:38 2ZjCCQ2T0
>>69
>現在のIntel版64bit実装だと、5個
>ぐらいの汎用レジスタを同時使用するとストールするよ。
済まん。それは知らなかった。
gcc で 64bit でコンパイルすると普通に引数を
レジスタに積んでるけど、そんな罠があるのか。
Xeon でもそうなの?
72:名称未設定
07/11/18 18:17:52 Z6CfSPdaO
64ビットOSという表現をやめて64ビット級OSという表現を使うべき。
73:名称未設定
07/11/18 18:28:52 TP8f/+qM0
>>68
Xcodeを32bitモードと64bitモードで動かしてRSIZE比べると約倍になってるよ。
オーバーヘッドの分速度もやや遅くなる。
>>69
増えるのは「見かけの」レジスタ数だからね。ハードウエア上のレジスタ数は変わらない。
64bitモードになると死んでたレジスタに火が入るわけではない。
「見かけの」レジスタ数が増える事によって生成コードが改善される分有利になる。
74:名称未設定
07/11/18 18:30:06 fjyNnsFv0
2コアだと、64bit級のCPUが二つで、128bit級だな(`･ω･´)
75:名称未設定
07/11/18 18:30:06 PxWpUj+40
そもそもレジスタ数が云々、使用メモリサイズが云々なんて話は
カーネルが32bitか64bitかとは関係ない話。動かすアプリケーション次第。
汎用レジスタが増えると言ってもソフトウェアから見えるレジスタが増えてるだけだから
実際に効くかはフロントエンドのリネームのロジック次第で何とも言えん
76:名称未設定
07/11/18 18:33:30 PxWpUj+40
まあ遅くなる要素はコンテクストスイッチのオーバーヘッドぐらいで
速くなる可能性の方が高いけど。
77:名称未設定
07/11/18 18:46:01 ndzXdl+y0
>>71
Xeonでも同じ。
MSがAMD64実装のほうをWindowsでサポートすると発表したためにIntelがあわてて
自社の32bitCPUにAMD64の64bit命令を「解釈できる」機構を無理やり導入したのが
混乱の発端。
だもんで、例のサプライズはAMD搭載機の発表だと思ってたんだよね。Core2で
64bitOSなんて悪い冗談みたいだから。
78:名称未設定
07/11/18 18:50:48 PxWpUj+40
現状でAMDの採用とかあり得ないでしょ。
いくらCore MAの64bitモードに不備があるとはいえ、絶対的に遅いものを採用する意味は無い。
79:名称未設定
07/11/18 18:54:33 HTIbu+LF0
>>49
メモリを512MB積むため、メモリー拡張パックを買い占めろ。
インストールメディアは64DDな。
80:名称未設定
07/11/18 19:03:20 2ZjCCQ2T0
>>73
>RSIZE比べると約倍になってるよ。
Xcode じゃないけど、手元のコードではそうはならなかったよ。
ヒープのデータが全て long か pointer なプログラムなんて
そう無いと思うけど。
>>77
さんきゅ。今度 Xeon マシンを借りられるので、実際に試してみます。
確かに悪い冗談というか悪夢だね。
81:名称未設定
07/11/18 20:38:44 4uoHkZ4y0
>>78
64bitモードの不備は来年発表のNehalemで解消されるらしい。
82:名称未設定
07/11/18 21:18:39 Mcgcg9Gf0
>>80
じゃなくて、ヒープなどは管理そのものにポインタ使ってるでしょ
小さいサイズでアロケートの回数が多いアプリは、もろに64bitで重くなるよ？
83:名称未設定
07/11/18 21:31:34 2ZjCCQ2T0
>>82
>じゃなくて
何じゃないんだよ。省略せずにきちんと書くようにしなよ。
俺は重くならないなんて書いてないよ。
1. 他人のレスをちゃんと読む
2. 投稿する前に自分のレスを読み直す
これだけで他人との会話がだいぶ変わってくると思うぞ。
84:名称未設定
07/11/18 21:36:35 48JPa0p10
2chで何を言ってるんだ？
85:名称未設定
07/11/18 22:38:40 Mcgcg9Gf0
>>83
言葉足らずでｽﾏﾝね
>>ヒープのデータが全て long か pointer なプログラムなんて
>>そう無いと思うけど。
に対する、「じゃなくて」って意味。
現実にはヒープのデータだけではなく、
アロケート回数に標準ポインタサイズがかなり影響するという話。
86:名称未設定
07/11/18 23:00:23 2ZjCCQ2T0
>>85
それを俺にレスして何が言いたいのか分からないよ。
1. アロケータ内の pointer 変数とプログラム用の pointer 変数を区別しようが
しまいが、元レス (>>80) の趣旨には影響しない（int も char も絶対使わねえよ
というのなら話は違うけど）
2. Resident の SIZE にはアロケータ用の pointer も含まれるから、元々ヒープの
データだけを見ているわけではない（RSIZE って break した領域のサイズだよね?）
3. それがそんなに気になるなら Hoard とか別のアロケータを試してみたら
良いんじゃないかな（メモリの利用効率について比較したペーパーがどっかに
あったと思う）
87:名称未設定
07/11/18 23:14:36 Mcgcg9Gf0
>>86
>>85だけど、俺は>>73とは別人だよ
>1. アロケータ内…
それは当たり前の話。
>2. Resident…
これも当たり前の話。
>>80の、
>Xcode じゃないけど、手元のコードではそうはならなかったよ。
という、ひとつのサンプルは、
>>73の
>RSIZE比べると約倍になってるよ。
という別のサンプルを否定できない。
なのに、
>ヒープのデータが全て long か pointer なプログラムなんて
>そう無いと思うけど。
「そう無い」って結論は強引かな。
>3. それがそんなに気になるなら Hoard とか…
これはまた別の話だな。
俺自身は、フル64bit化って、結構メモリの経済感覚が変わるって言いたかっただけだけど…
88:名称未設定
07/11/18 23:19:15 ndzXdl+y0
>>78
残念ながらピュアな64bitコード（汎用レジスタ使いまくり）の土俵では、桁違い
とまではいわないがAMDの圧勝になる。AMDは64bitモードで処理効率が上昇することは
あっても低下する要因がゼロだから。Intelが1だとするとAMDが1.5〜2.5ぐらい
じゃないかな。
逆に32bit環境だとIntelが強くなる。だから32bitOSのままにとどめたLeopardは
英断だと思うんだよ。
89:名称未設定
07/11/18 23:43:48 AZLk7ltv0
あむむし
90:名称未設定
07/11/18 23:50:19 f85CVL+w0
>>88
書いてて恥ずかしくないか？
>Loepardは、64ビットのパワーを発揮する万能オペレーティングシステム。
URLﾘﾝｸ(www.apple.com)
91:名称未設定
07/11/19 00:55:38 3VfMUqmK0
>>88
ただどっかで完全ピュア64bitOSになる時がこなきゃ
その時はMac OS X10.×じゃなくMac OS11になると思うけど
92:名称未設定
07/11/19 01:31:58 eFDg/yWT0
>>91
いずれは確実にそうなるだろうけど、
将来OSXのインストール対象リストから32bitマシンが完全に消えるまで、
なんだかんだでゆっくりやりそうな悪寒
これまでも徐々に段階的に、って進め方だったし
今回の拡張で当面の状況は凌げそうな感じでもあるし
そのときにはまだOSX10.xを名乗ってると思う
93:名称未設定
07/11/19 01:48:03 CzeF477W0
そういえば URLﾘﾝｸ(www.apple.com) に書いてあることが
ちょっと気になった。
>仮想メモリで最大16エクサバイト
単に64ビットだからということか。Mac OS Xで実際にアドレス可能なユーザ空間は
もっと小さいのだが。
>物理メモリで4テラバイトの64ビットアドレス指定
4テラって何? 42ビットだねえ。ということは単にG5でアドレス可能な範囲のことを書いてる?
今使われてるCore 2って確か36ビットじゃなかったっけ?
94:名称未設定
07/11/19 02:10:28 gsvQhkNs0
>>88
適当なことを言わないように。
つーかDPレベルだとIntelが圧勝しないベンチを見つける方が難しい
64bit環境での比較 (Harpertown vs Barcelona)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
URLﾘﾝｸ(techreport.com)
95:名称未設定
07/11/19 02:19:26 gsvQhkNs0
というかピュアな64bitコードって何だよw
64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは
LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが
64bit Windowsのように64bit only(除ブリッジ)の環境だろうが
全部64bitのコードだから。
96:名称未設定
07/11/19 03:01:37 yC6wO/it0
>>95
＞LinuxやMacOSのように32bitと64bitが混在する(できる)環境だろうが
URLﾘﾝｸ(arstechnica.com)
>There is no "mixed mode" in Leopard. Every process is either 32-bit or 64-bit.
>Since a 64-bit process cannot load 32-bit plug-ins (and vice versa)
>there will be a significant transition period for applications that rely heavily on plug-ins.
>(I don't envy Adobe's developers... and it gets even worse for them, as you'll soon see.)
97:名称未設定
07/11/19 03:21:44 gsvQhkNs0
???
そこに書いてある通りだけど。
つーかコードレベルでは混在してないって95に書いたのを読んでないのか?
Tigerも64bit APIがLeopardより少ないだけで同じ。
98:名称未設定
07/11/19 03:32:47 gsvQhkNs0
そもそもこんな当たり前のような話を説明しなければならんのは
68kからPPCの過渡期に68kのToolbox APIがネイティブのPPCバイナリから
MixedModeManagerを介して呼び出されていたという過去があるからかね?
だから当時はシステムの一部に68kコードが残ってPPCの最適化が...という話になった訳だが。
現在の32bit環境と64bit環境の混在は、MixedModeManagerのような仕組みを使った物ではなく
完全な「並立」。だから64bitでアプリケーションを作った時点で
現行のOSXに32bitのシステムが存在する事によるオーバーヘッドを気にする必要はない。
99:名称未設定
07/11/19 04:34:01 CzeF477W0
強いて言えば、IPCでオーバーヘッドがある場合はあるかも。
100:名称未設定
07/11/19 09:32:30 yC6wO/it0
>>97
「64bitアプリケーションに含まれる(dynamic linkされる物を含む)コードは全部64bitのコードだから。」
はどうでもよくて、
「LinuxやMacOSのように32bitと64bitが混在する(できる)環境」
「64bit Windowsのように64bit only(除ブリッジ)の環境」
の意味がよく分からんかった。
アプリの話をふりつつここはカーネルの話をしてないかい？
そんだけ。
101:名称未設定
07/11/19 09:48:54 NCC56ZWi0
苦しくなると話をそらすのはドザチョンズによくあること
102:名称未設定
07/11/19 09:58:50 zzJdaFGe0
>>100
いや、どっちもアプリケーション(提供されているAPIレベル)の話だけど。
103:名称未設定
07/11/19 10:05:44 yC6wO/it0
>>102
もしかして「(除ブリッジ)」ってWindows on Windows64を除くって意味？
Wikipedia項目ﾘﾝｸ
104:名称未設定
07/11/19 10:18:06 li5anQAb0
そんなもん、Windowsno設計が悪いだけの話じゃない
アホだ
105:名称未設定
07/11/19 11:17:10 VUl/Ctdi0
どう考えてもOSが32bitで、アプリが32bitと64bit混在のMac OS Xの方が過渡期の状態だろ。
Win64のWOW64は完全64bit環境で32bitアプリを動作させるエミュレータなんだから。
106:名称未設定
07/11/19 12:09:54 ufCkEcHm0
64bitと32bitの違いって、シングルCPUとマルチCPUの違いと実質的に
つながる所があると感じるけど、このあたり詳しい人いますかね。
つまり32bit-CPUを2セット「並列処理」できる状態と64bit-CPUひとつと
同じ機能ではないのかと。時代が次第にマルチコアCPUの方向にシフトしてきている今、
スレッド処理をいかに無理なくスムーズに処理できるかに重点が移ってきてると思う。
107:名称未設定
07/11/19 12:11:38 VUl/Ctdi0
>>106
完全に勘違いというより抜本的な理解不足。小学校からやり直せ。
108:名称未設定
07/11/19 12:26:14 ufCkEcHm0
>>107
32bitとか64bitとかの本質的な違いを説明したサイトがうまく見つけられんのよ。
どこもかしこも「64bitであるか32bitであるか」の言い合いばかりでね。
CPUの処理の幅が64bitか32bitかの違いであるのなら、マルチCPUでこれらの
違いは一挙に意味を失うのではないのかと感じる。
それともメモリ空間のアドレスの大きさを言ってるのかしらね。
109:名称未設定
07/11/19 12:37:35 li5anQAb0
なにいっってやがるんだよw
64bitになったら、64bitマンセーしてるよwwwwwwwwwwwwwwwwwwwwww
110:名称未設定
07/11/19 12:39:14 hjfNPILj0
こうなると、何を持って「xxxビットのOS」と言うのか...。
そうゆうのはだんだん意味を持たなくなるのかな。
111:名称未設定
07/11/19 12:52:34 ufCkEcHm0
やっとそれっぽい記事を見つけた
これのことかねぇ
URLﾘﾝｸ(journal.mycom.co.jp)
どうやらCPUの一括処理の単位およびメモリ空間のアドレス空間の大きさ
双方を指し示しているみたいですね。
112:名称未設定
07/11/19 13:58:52 zzJdaFGe0
>>103
そうです。
113:名称未設定
07/11/19 14:07:41 DxnjZeNd0
まあそういう意味で64bitへの移行手段はLeopardで着々と進んでる。
ライブラリは全て64bit対応だし、
Input MethodもアプリがどちらでもOKな様に独立プロセスになった。
kernel driverも32/64bitのUniversalに対応してる。
QuickTimeのCodecは、32bit QT serverで64bitアプリに対応。
問題は3rd partyの対応だが、
Printer driverのPDEもOSバンドル品は64bitになってるのが多い。
物理的に8G以上積めるのは現状MacProだけだから、
メリットが出てくればマイナーアップデートで64bit kernelのせる鴨ね。
114:名称未設定
07/11/19 15:06:07 r8sanitS0
おまいらそういう知識どこから仕入れるの？
エロサイト？
115:名称未設定
07/11/19 16:08:08 Qri/s4Wv0
>>114
まぁ大半の人はエロサイトだろうな
116:名称未設定
07/11/19 16:32:17 uz5lWwIe0
32bitよりも64bitのほうがモザイクが薄くなるんだ。
117:名称未設定
07/11/19 16:40:45 DxnjZeNd0
WWDC
118:名称未設定
07/11/19 16:47:56 PeaucL070
Leopardは64bit APIを備えたOS。
以上。
119:名称未設定
07/11/19 17:02:45 ufCkEcHm0
実際、64bitでの一括演算というのは1.8x10^19程度を上限とする
整数の四則演算が一挙にできるか、というレベルの話なんですかねぇ。
いろいろ巡ってみても、まだよくわからん。
120:名称未設定
07/11/19 17:16:22 zzJdaFGe0
演算器の幅に関して言えば、32bitでいうlong long型を使う必要があるような場面で
少ないクロックサイクルで終えられるという程度の利点。
そもそもそんな場面はほとんど無いし、SSE2があれば32bitCPUでもできるし。
AltiVecではできないけど。
そもそもこれに関してはOSの64bit化とはほとんど関係ない。
121:名称未設定
07/11/19 17:23:58 ufCkEcHm0
>>120
そうでしたか、ですとOSの64bit化というのは具体的にはメモリ空間が
64bitで管理できるかどうか、あたりの話になるんでしょうかね
122:名称未設定
07/11/19 17:29:36 In4q82oq0
URLﾘﾝｸ(developer.apple.com)
123:名称未設定
07/11/19 21:24:02 DxnjZeNd0
URLﾘﾝｸ(developer.apple.com)
Myth: The kernel needs to be 64-bit in order to be fully optimized for 64-bit processors.
Fact: The kernel does not generally need to directly address more than 4 GB of RAM at once.
The kernel is able to make larger amounts of memory available to applications by using long
long data types to keep track of mappings internally.
124:名称未設定
07/11/19 21:27:22 gCnjvcXf0
なんか微妙な言い方だけど、
要するに64bitじゃないことの言い訳かな？
125:名称未設定
07/11/19 21:28:42 Gom9RQoZ0
なんかもの悲しいスレだな。
126:名称未設定
07/11/19 23:01:37 NZGjvECs0
>>123
これはあと数年は 64bit 化しないよという宣言なのかな
ちゃんと Myth #5 で Intel では 64bit 化した方が速くなる事を
認めているのに何で Myth #2 で余計な事を書いてしまうんだろうか
分かってて手を抜いたんだから、言い訳する必要なんか無いのに
127:名称未設定
07/11/19 23:15:29 uz5lWwIe0
でも、Tigerではカーネル部分が64bit対応だって言っていたよね。
だからTigerでは64bitのアドレス空間がサポートされたと聞いたが。
そしてLeopardではCocoaなどが64bit対応になったって話なのだろう。
128:名称未設定
07/11/19 23:33:50 gsvQhkNs0
>>126
いやだからアプリケーションレベルで64bit化してればいいわけで
カーネル自体が64bitプロセスになっても個々のアプリケーションのパフォーマンスは変わらんよ
いい加減理解しないかね。
129:名称未設定
07/11/19 23:36:52 NZGjvECs0
>>127
仮想メモリが 64bit アドレス空間を扱える様になるのと
カーネルが 64bit で動く様になるのとは、天と地ほどの
差があるよ。今の Mac OS X は前者のみ。現代において
後者が出来ないのは純粋技術的にはかなりダサイと言って
差し支えない。まあサーバ用途で使う OS じゃないから
実質的な問題は無いと判断したのでしょうね。1,2 割の
性能ロスくらい構わない、と。
130:名称未設定
07/11/19 23:41:02 NZGjvECs0
>>128
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
理屈で考えたら分かると思うけど、カーネルのレスポンスが
速くなれば当然アプリも速くなるよ。sys が全く発生しない
ページングも絶対しない、スケジューラの影響も受けない様な
アプリなら君の言う通りかもしれないけどね。
131:名称未設定
07/11/19 23:59:30 gsvQhkNs0
>>130
それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
クリティカルに影響してるようなケースの場合。さもなきゃ体感は不可能でしょう。
それも、カーネル自体が64bitで動いてるかどうかよりは、実装に依存する話。
あまり変な幻想を抱いてると、本当に64bitカーネルになった時に落胆するよ。
132:名称未設定
07/11/20 00:07:21 eG/Kxnw50
>>131
俺は↓これが間違いだって論理的に理解して貰えれば
何でも良いよ。
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
それに 64bit で動いているかどうかも実装の問題だよね。
普段は純然たる 64bit Kernel な OS を使ってるので、
ページスキャナが long long でメモリを舐めていると
考えると悲しくなるよ。
133:名称未設定
07/11/20 00:11:59 eG/Kxnw50
つうか気付いてなかったけど、俺ずっと age てたね。スマソ。
134:名称未設定
07/11/20 00:12:07 rYXJ+HDw0
ところで
x64で64/32の混在だと、CPUはMixed Modeで動作することになるんだよね？
それによる速度低下はどの程度？
135:名称未設定
07/11/20 00:27:50 eG/Kxnw50
>>131
>それは99の言うIPCとかコンテクストスイッチのようなプロセス間の相互干渉が
>クリティカルに影響してるようなケースの場合。
一応書いておくけど、プロセス間やスレッド間でリソースの取り合いが
発生しているかはこの場合全く関係無いよ。何でそう思ったのか知らんけど。
そもそも Myth #5 で書かれている、関数呼び出しの際に引数がレジスタに
積まれて渡されるから速くなるという所から俺の話は始まっているんだけど、
カーネル内の関数コールが速くなれば、カーネルサービスに依存している
アプリの処理性能も結果的に上がるという話だからね。
Do you understand?
136:名称未設定
07/11/20 00:43:05 ymuEzXkQ0
>>135
いや...だから何でシステムコールがアプリケーションの速度を律速するようなケースが前提になってるの?
137:名称未設定
07/11/20 00:49:10 OSW4g0lD0
forkとかmallocで飯を食ってる人だから
138:名称未設定
07/11/20 00:51:10 eG/Kxnw50
>>136
律速するかどうかは関係無い。全体のフローの中で時間を短縮
可能な箇所があれば、全体に掛かる時間も短くなるというだけ。
例えば家から会社までの道のりで考えると、家から駅まではバス、
駅から会社の最寄り駅までは電車、そこから事務所までは徒歩で
行くとするよね。今まで各駅停車に乗っていたのが、新しく
急行電車が並走する様になりました。急行に乗ったら通勤時間が
短くなりました。
この電車が I/O だったりメモリ要求だったりのカーネルサービスね。
各駅停車は 32bit Kernel, 急行は 64bit Kernel だと考えてみ。
勿論、通勤時間はアプリの処理時間に相当するよ。
139:名称未設定
07/11/20 00:53:57 2o0+XUTp0
まあ本当にどうでもいい事だと考えているのなら今後appleが64bit kernelを採用する事は全く無いだろうね。
俺は採用すると思うけど。
140:名称未設定
07/11/20 01:03:38 ymuEzXkQ0
>>138
自分で1割2割ロスしてると言ってるでしょ。
そんだけパフォーマンスを上げるには、明らかにシステムコールが処理時間の相当量を占めてなきゃ不可能。
超多めに見積もってカーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても
処理時間に占める割合は1割ロスで1/8、2割だと1/3だよ。
どう考えても律速してるし、現実にそんなケースは無いよ。
141:名称未設定
07/11/20 01:07:20 ymuEzXkQ0
ごめん1/8、1/3じゃなくて1/9、1/4だった
142:名称未設定
07/11/20 01:13:44 eG/Kxnw50
>>140
割とどうでも良いところに噛み付いたね。
>どう考えても律速してるし
俺は律速していないと言ってるんじゃなくて、
「律速するかどうかは関係無い」って書いたと
思ったけど。
あと、1,2 割は sys の 1,2 割と読んでくれ。
これはスマソ。sys の割合は俺の経験上は
10-50% くらいが一般的かな。10% 以下なら
かなり優秀なアプリだと思う。
で、結論としては処理速度は上がるで良いかな?
143:名称未設定
07/11/20 01:26:10 ymuEzXkQ0
>>142
50%が一般的てどんな状況だよw
144:名称未設定
07/11/20 01:31:10 mCYTBfd80
まあ Vista あたりが 64bit 化にあたって糞みたいな実装をしてきたのに対し
アプルは随分クールで現実的な解決策を持ってきたと思うよ。
>>139 とか >>138 は >>140 の書いてあることをちゃんと理解してから
反論してくれよな。ymuEzXkQ0 は、
>カーネルの64bit化でカーネルサービスに費やす時間が半分になるとしても
という相当な無理がある仮定をしても、結果的にプロセス全体への影響は
少ないということを言っている。eG/Kxnw50 はカーネルの 64bit 化で
OSサービスが現実的にどの程度早くなると見込んでいるのだろう？
145:名称未設定
07/11/20 01:34:59 mCYTBfd80
>>143
やぱり fork と malloc で飯を食ってる人なのかもw
146:名称未設定
07/11/20 01:37:02 cszpg1Al0
処理速度を気にしない処理ほど改善が大きくなりそう。
ベンチマークで比較されるような処理は普通%sysが非常に小さくなるから
一般ユーザが実際に恩恵を受けるような場合はあまりないだろうね。
それをふまえてAppleはあんな風に書いたんでしょう。
147:名称未設定
07/11/20 01:38:25 eG/Kxnw50
>>143
もう、どうでも良いところにしか突っ込めないのね…
I/O とか Network に依存するアプリは結構 sys 出るよ。
細かいパケットを送受信したりする作りだとね。
>>144
君がスレの流れを読んでくれ。64bit 化しただけで
倍速くなるくらいなら何年も前に皆そうしてるよ…
どれだけ速くなるかではなく、確実に速くなるという
話をしているんだよ。
148:名称未設定
07/11/20 01:40:55 mCYTBfd80
>>146
それにしても「一般的なアプリ」で見込まれる%sysも大きいし、
eG/Kxnw50 がカーネルの64bit化で見込んでいる速度向上率について興味ある。
149:名称未設定
07/11/20 01:41:19 eG/Kxnw50
話を元に戻すけど、俺の話は↓これが間違っているという事。
>カーネル自体が64bitプロセスになっても個々のアプリケーションの
>パフォーマンスは変わらんよ
それだけの事を理解させるのにこんなに説明が必要とは思わなかったよ…
150:名称未設定
07/11/20 01:46:27 mCYTBfd80
>>147
>I/O とか Network に依存するアプリは結構 sys 出るよ。
何で%sysが大きくなるか考えてくれないと…
これらが 64bit化でどの程度高速化できると思う？
これと引き換えに失うものを考えたら、アプルの実装はかなり理に適っている
と思うけどね。
151:名称未設定
07/11/20 01:50:36 eG/Kxnw50
>>150
>>149 を読んでくれ
1. Apple の実装が間違ってるとは言っていない
2. どの程度高速化するかはまた別の話
2 については君は不満なんだろうが、>>149 に決着が付いたら
そっちも相手してあげるよ。ホントはもう寝たいんだけどね。
152:名称未設定
07/11/20 01:53:17 mCYTBfd80
>>149
>>話を元に戻すけど、俺の話は↓これが間違っているという事。
いや、だから ymuEzXkQ0 が言いたいのは、カーネルの 64bit 化は、
アプリの処理速度への現実的な影響は殆どないということでしょ。
（オレはymuEzXkQ0じゃないから推測だが）
現実的に見て間違っているとは言いがたいなぁ。
アプリの%sysと、64bit カーネルの速度向上（ホントにあるの？）
をどの程度見込んでいるかによるけどね。
殆どあり得ない数字を前提にするなら、それはまた別の話。
153:名称未設定
07/11/20 01:54:16 ymuEzXkQ0
>>151
いくら言ってもコーナーケースの話をされて終わるということは分かったので
もう寝てくださって結構ですw
154:名称未設定
07/11/20 01:59:22 OSW4g0lD0
I/OとかNetworkなんてそもそもCPU時間を使わん処理は
%sysが改善したところで処理時間に差はでない
155:名称未設定
07/11/20 02:05:47 eG/Kxnw50
>>152
俺は fork とか malloc で飯食ってるから、君の現実感とは違うんだろうな。
1 sec でも速くなれば、それは処理速度が向上しているという事だよ。
実際 32bit の VM で 64bit のアドレス空間を捌くオーバーヘッドはかなり
大きいと思うよ。まあ 1 割速くなる程度じゃ現実的じゃないと言われるかも
しらんけどね。
156:名称未設定
07/11/20 02:08:11 eG/Kxnw50
>>153
カーネル内関数コールがコーナーケースな人には
カーネルの話は無理じゃないかな。
157:名称未設定
07/11/20 02:09:17 OSW4g0lD0
やべえ適当に言ったら当たった
そういう玄人さんはここに来て素人に講釈垂れるだけ無駄だと思うよ
感覚からして合わないだろうし
158:名称未設定
07/11/20 02:10:53 eG/Kxnw50
>>154
>NetworkなんてそもそもCPU時間を使わん処理は
Ethernet から Socket Buffer まで、ずっと CPU 処理ですよ
良い加減まんどくさくなってきた...
159:名称未設定
07/11/20 07:29:28 6LXH3Xpx0
>>144
Vistaの64bit実装のどの辺が糞なんだろう？
Solaris8やLeopardあたりと比べるとまだましな部類に入ると思うんだが。
160:名称未設定
07/11/20 07:37:15 vgrsNHYQ0
それで、カーネルが64bitになれば、
iPhotoとかのアプリが1割速くなったりするのかな？
そこが重要だとおもうんだけど。
161:名称未設定
07/11/20 07:38:30 l5H4qjyT0
>>159
既に感情論の領域に入っていますので、まともな反論は難しいものと思われます。ｗ
162:名称未設定
07/11/20 08:21:13 6LXH3Xpx0
>>161
なるほど。要はなんでもいいからLeopard以外は糞と言いたかっただけなのね。了解です。
163:名称未設定
07/11/20 08:27:15 OdT0j6ekO
APIが64bitってどうゆう意味ですか？
164:名称未設定
07/11/20 09:11:33 eG/Kxnw50
>>159
>Solaris8
Sol 8 って何か問題あったのけ?
だいぶ昔だから、どんなだったかもう忘れちゃったけど。
165:名称未設定
07/11/20 10:06:39 /pt+6y3e0
カーネルの内部関数あたりの話そのものを述べると少しかじったくらいの
人では少し追いつけない話になりますわね…。
なかなか64bitというものを具体的に解説した書物がなさそうな状態で、
なんとなく64bitはすごいというイメージが一人歩きしてるのではないかと
自分的には思うけれどどうなんだろう。
倍以上の性能になるといえばそういうわけでもなさそうですよね。
166:名称未設定
07/11/20 11:55:48 J+zz8lwJ0
>>164
正確に言うとSol7からだな。Sol7は2000年問題の対応時期と重なった関係で特に企業でスキップしたとこが多いから8で
問題が顕在化したところが多いんじゃないだろうか。
OBPアップデート、/proc問題、Largefile問題etc...導入規模が大きな所ほど影響が大きかったような気がする。特に
ドライバの揃わなっぷりはx64Windowsの比じゃなかった。
167:名称未設定
07/11/20 12:10:44 bpcPpSPZ0
そもそもｘ64で32ビットカーネルで64ビットアプリって動くの？
64Bitのロングモード使う場合は64Bitカーネルが必要では？
PowerPCは知らんけど
168:名称未設定
07/11/20 12:29:47 xK/rJZ3Z0
話をぶったぎってすまんけど、自分で Darwin のソースをとってきて、
64bit モードでコンパイルしててもとのカーネルと置き換えてウハウハ、とか
できるの？
169:名称未設定
07/11/20 12:34:06 2bCls0W80
URLﾘﾝｸ(journal.mycom.co.jp)
170:名称未設定
07/11/20 12:52:11 DVkEcb000
URLﾘﾝｸ(journal.mycom.co.jp)
どうせならこの方がいいだろう。
171:名称未設定
07/11/20 16:29:56 ud5nBSO60
Machカーネルも32bitと64bitの両方のモードで動作するってことだろ。
あと、32bitのWindows95でも16bitアプリが動作したから。って言ってるけど、
それって今回の場合と違うだろ？ 32bitWinで64bitアプリが動作するか？
16bitWinで32bitアプリが動作したのか？
172:名称未設定
07/11/20 16:38:49 l5H4qjyT0
>>167
動く。
そういえば、Leopardは完全64bitだが、32bitドライバも問題なくシームレスに動作が保証されて
いるから、下位互換性に関しても全く問題無いなんて主張している奴もいたな。全てが空しい。ｗ
173:名称未設定
07/11/20 16:41:30 l5H4qjyT0
>>171
違うだろ、UniversalBinaryの仕組みで、32bitと64bit両方のアプリが環境に応じて自動で
選択起動されるってこと。
174:名称未設定
07/11/20 16:47:35 /pt+6y3e0
要するに64bitのメモリアドレスをネイティブで取り扱えるかどうかという話？
175:名称未設定
07/11/20 16:56:48 wFbxk/Fu0
ロングモードの場合、割り込みハンドラとかは64 bitモードで動かす必要があったはず。
まあそれ以外のMachカーネルはほとんど互換モードで動いてそうだけど。
176:名称未設定
07/11/20 17:04:05 ud5nBSO60
>173
環境に応じてそれぞれのモードで起動する、
だから違うという話に何故なるんだ。
177:名称未設定
07/11/20 17:37:13 rYXJ+HDw0
>>167
俺もそこが分からん。
x64の3つの動作モードを知る (1/2)
URLﾘﾝｸ(www.itmedia.co.jp)
32bitカーネル＋64bitAPIのLeoの仕組みは、
上記のTable2のどれにも該当していないように思える。
178:名称未設定
07/11/20 17:53:02 ud5nBSO60
>177
>32bitカーネル＋64bitAPIのLeoの仕組みは、
そもそもこれから違うのだと考えつかないのかよ。
179:名称未設定
07/11/20 18:01:56 ud5nBSO60
>172
動かないよ。
なんで間違ったこと断言できるのか不思議なんだが。
x64の互換モードは、64bitカーネルと互換モードで32bitが動く。
32bitカーネルから互換モードで64bitは出来ない。
180:名称未設定
07/11/20 18:45:46 xK/rJZ3Z0
URLﾘﾝｸ(episteme.arstechnica.com)
URLﾘﾝｸ(episteme.arstechnica.com)
181:名称未設定
07/11/20 18:50:00 xK/rJZ3Z0
ふたつめで LordHunter さんが明快に答えているようだ。
彼の情報の出所がわからんけど。Oct 20 って発売前だから、NDA やぶってるんだろうね。まあいまや Darwin のソース公開されてるので。
182:名称未設定
07/11/20 18:50:46 ud5nBSO60
>>1のチェスしか64bit化されてないという指摘だけど、以下の
Apache 2、MySQL 5、Postfix、Podcast Producer、QuickTime Streaming Server、Java VM on Intel
これらは、サーバー版では64bit版が採用されてる。サーバー版も基盤は同じだよ。
183:名称未設定
07/11/20 19:19:19 ud5nBSO60
同時に処理なんて無理だろという人も結構いるみたいだから、
参考になる記事を探してみたけど、こういう例があるよ。
着実に成長を重ねる64ビットLinuxとBSD
URLﾘﾝｸ(opentechpress.jp)
>AMD64のワークステーションやサーバシステムを販売するようになった。
>だがおかしなことに、その大半は32ビットOSをデフォルトでインストール
>して出荷している。AMD64アーキテクチャは64ビットと32ビットの両方の
>ソフトウェアを快適に（しかも同時に）処理できるにもかかわらずだ。
この記事の続きは、主にAMD64（まあx64)とUNIXの記事だけど、
OSXの対応を考える上でも参考になるかな。
184:名称未設定
07/11/20 19:48:47 ud5nBSO60
因みにTigerの時の文書だけど、LinuxやBSDのカーネルと同じLP64モデルを採用してる。
URLﾘﾝｸ(developer.apple.com)
ドライバの問題をどう解決したのか（iokitがクッションになってる？）、
それは個人的にも興味あるけど、32bitカーネルでx64を利用して64bitアプリを
動かしてるという理屈がこのスレで成り立ってるのは驚いた。
185:名称未設定
07/11/20 20:04:04 Hd7AquSE0
>>182
サーバー版では64bit版が採用されているということは、
つまり、クライアント版では32bit版ということかね。
基盤は同じだというが、きっとアプリに互換性問題が発生して
カーネルを32bitで動かし、その為にそのほかのソフトも
32bitとして動かしているのだろうね。
チェスだけはうまく動いたのかな？
186:名称未設定
07/11/20 20:08:30 bekKr84S0
Chessに64bitバイナリを用意したのはサンプル的な意味合いが強いでしょ。
187:名称未設定
07/11/20 21:56:59 kRVXOBCK0
未だにCarbonで動いてる中核アプリが多いんだから少しずつ移植していくしか無いと思うけどね
チェスしか無いのはとりあえず組みやすい小さいアプリで実証しただけの事でしょ
188:名称未設定
07/11/20 22:24:16 wFbxk/Fu0
>>184
32 bitカーネルの定義の問題なんじゃねーの？
URLﾘﾝｸ(developer.apple.com)
この文章はLast updated: 2007-05-10だけど明らかにLeopardについて言及している。
んで、こうある。
Because 64-bit applications will be supported using a 32-bit kernel,
this 64-bit support will have minimal impact on most writers of device drivers or kernel extensions.
However, there are exceptions, as explained in “Device Driver Changes.”
もちろんAMD64のlongモード使うわけで、
割り込みハンドラは64 bitモードで実装しないといけないし
メモリ管理のページエントリだって64 bitに拡張しないといけない。
DMAだって物理アドレス4 GB以上の領域まで自由に使いたい。
これらについては64 bit “対応” が必要だ。
一方で、AMD64のlongモードの互換サブモードによって、Leopardでは
32 bit環境で動くmach_kernelが64 bit環境でも再利用できている。
ドライバも同じで、32 bit/64 bitの違いはI/O Kitが吸収してくれるので
作法に従って書いていれば、32 bit用のドライバでも64 bitの物理メモリと連携できる。
この状況を「32 bitカーネル」と書いて伝わると思っている奴もいれば(他ならぬAppleがそうだ)
「64 bitカーネル」と書かないと気がすまないという人間(例えば>>184)もいるというだけじゃなかろうか。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5395日前に更新/290 KB
担当:undef