64bitのオペレーティングシステム

64bitに触れたこともありません。
誰か詳しい方､64bitと32bit双方のOSレベルでの根本的違いを説明して
下さい。

また､どこかのサイトで128bitのOSについても､ちょっとだけ触れてましたね。

Tru64 はやいよ。

Solaris2.7以降はHardwareが64bit対応していたら、カーネルが
64bitになるみたいですね。

ip_filterがgccでmake出来なくて癪だ。

Tru64は、5時間ぐらい使って、FreeBSD4.2Rに変えました。
Tru64はXの解像度どうやって変えるのだ？1024x768は狭い。

I/Oの幅とアドレス空間

以前、PCをオシロ代わりに使おうとしたが、
まったく帯域不足のオシロであまり役に立たなかった。
その時、これが64bit MPU/OSなら楽勝なのに…と思ったよ。

ゼミのCPUサーバをSolaris8 64bitsにしたら、
GbEカードのドライバが出て無くて、
仕方ないので100のありふれたカードをさして使ってる。

鬱だ。

データバスは128bitほどあっていいが
アドレスバスは64bitもあれば十分すぎるかと。

Z80設計者：アドレスバスは16bitもあれば十分すぎるかと。
i8086設計者：アドレスバスは20bitもあれば十分すぎるかと。
i80386設計者：アドレスバスは32bitもあれば十分すぎるかと。
>>7のドキュソ：アドレスバスは64bitもあれば十分すぎるかと。

歴史は繰り返す

>>4
I/O の幅は、変わらないのが多いよ。
今までの I/O を動かさなきゃイケないわけだし。
符号拡張するだけとかね。

>>1
例えば、PA-RISC の世界なんだけど。
IO_EIR (I/O Extertnal Interrupt Register っていう、
システム上のモジュール(CPU, メモリコントローラ, I/O ．．．)
それぞれに識別子をつけて、CPU に「どのモジュールからの割り込みか？」って
識別する機能があるのね。
これが 32 -> 64 bits のレジスタなら、単純に倍の(1モジュール/1bit の割り当て)
モジュール(I/O) を取り扱う事が出来る。
psw(Processor Status Word) の w-bit で 32/64 を切り替えるんだけど
良く間違えた。PA-RISC は左から 0, 1, ... 63 bit って並ぶんだけど
32 bitだと 0 bitめを表すのに、64 bitだと 32bitめだからね。

IA-64 の世界は、やっぱ >>4 が書いてるメモリ空間かな。
4GB と 16He リニアに使えるのとでは違うよね。

>>2
DEC アルファの 64bit って、
データ長は、64bit で、アドレッシングは Virtual Addressing で
実は 32bit っていう、インチキ 64bit じゃなかったっけ？

16Heって何の単位ですか

ヘリウム原子16個分

ところで4004ってアドレス空間どれくらいだったの

>>12
だかーら、DIGITAL -> Tru64 になったのだと思われ。

>>8
繰り返すっていっても
Z80とi8086はともかく
i80386はまだ足りてるじゃん。
64bitあれば18エクサbyteだぞ？

ネット上（この言葉が何を指すのかは知らんが）の
すべての情報ですらまだ1エクサ達してないのだろう？

十分すぎると思うのだが……

　　　　　　　　　　||￣￣￣￣￣￣￣￣￣￣||
　　　　　　　　　　||　 BSD馬鹿は 　 　 Λ_Λ　　いいですね。
　　　　　　　　　　||　　　放置！　　＼　(ﾟーﾟ*)
　　　　　　　　　　||＿＿＿＿＿＿＿＿⊂⊂ |
　　∧ ∧　　　 ∧ ∧　　　 ∧ ∧　　　 |￣￣￣￣|
　 (　　∧ ∧　(　　 ∧ ∧　(　　∧ ∧　|　　　　　　|
〜（＿(　　∧ ∧ __(　　∧ ∧__(　　 ∧ ∧￣￣￣
　　〜（＿(　　∧ ∧＿(　　∧ ∧＿(　　 ∧ ∧ 　は〜い、先生。
　　　　〜（＿(　 　,,)〜（＿(　 　,,)〜（＿(　 　,,)
　　　　　　〜（＿__ﾉ　　〜（＿__ﾉ 　　〜（＿__ﾉ

>>17
だから今の時点ではたりるさぁ

ま、増え方が段違いだから足りなくなるとは思えないけどね
でも、広大な無限の領域と思われた4GBが物によっては足りてないからなあ

>>19
一応先のことも考えてるつもり

>>20
まあ4GBは使い切れるだろうが
その42億倍を使いきれるか？

>>7のドキュソ
例えば、画像ファイルはどうだろう。テレビ局が20あるとして、
24時間分全てを録画していくとしよう。何年分記録できるのだろう。
誰か試算してー

>>22
仮に1局を1時間1GBだとしたら100年ぐらいかな。
RAMに記録する必要もないが。

ここはUNIX板だしRAMっていうよりコアっていったほうがいいのか？

へ？

わかっているとは思うが、
Pentium Pro 以降は 4G より大きい物理メモリを
扱えるようにはなってるぞ。PAE や PSE-63 を使えば 64G まで逝ける。
MMU 使ってリニアにアクセスできる仮想空間は 4G だが。

>>26
よく知らないんだけど、昔のセグメントやページングのような仕組み？

1

>>27
PAE はページテーブルを2段から3段にして
扱える物理アドレスを拡張する。Pentium Pro 以降。
PSE はページサイズを大きくして (4KB→4MB) 物理アドレスを拡張する。
こっちは Xeon 以降。

いずれにせよ、MMU を使うかぎりリニアに使える仮想空間は4G。
もちろん MS-DOS リアルモード時代みたいに手動で切り替えれば、
アクセスできる空間は増やすことはできるけど、
いまさらそんなことしたくないよな。

で、>>1 の話に戻ると、UNIXにおいて 64 ビットというと
やはりこの仮想アドレス空間が広大なる、
というのが一番大きいのではないか。月並みの結論だが。
それ以外では根本的な違いというのはあまりないような
気がする。

IPaddrだって 128bitになるのに、64bitじゃ...

>>30
アドレス空間が大きければいいってものでもないんだ。
今度はページテーブルが巨大になってメモリを圧迫する。

>>30
アドレス空間が大きければいいってものでもないんだ。
今度はページテーブルが巨大になってメモリを圧迫する。

TLB miss fault も頻繁に起きそうだしね。＜ページテーブル

>>3

/etc/dt/config/Xserversの最後の方を、

:0 Local local@console /usr/bin/X11/X :0 -screen 1280x1024 -vclass TrueColor

とかにする。

もし/etc/dt/config/
がなかったら、
/usr/dt/configをコピーしてつかう。

>>32
pagetableが巨大になってもいいようにGDT,LDTと2段階になっている
pagetableをswapoutできないOSは滅んでいい。いや滅ぶべきだ。

>>35
Linuxは滅ぶべきだと逝っているのか？
今時FreeBSDだってkernelをswapoutできる筈だがな

>>36
FreeBSDもLinuxもkernel、pagetable、ldtをswapoutできない。
よって滅んでよし。

>>35
今出来ない事は別にできる必要はないと強がりを言うUNIX厨房が
騒ぐから、この話題はやめやめ。誰だってkernelのその点では
Win2000に負けている事を素直に認めてあとを追いかけているし、
あえてそのモードを切り離したエディションもM$は出しているしさ。

滅ぶべきはUNIX厨房だけ

仮に 1KB / 1ns でアクセスできたとして、
64bit だと 200 日ぐらい？
メモリチェックするだけでも大変だ。

>>32

Thank you!。だがしかしもうTru64が無い。FreeBSDにしててファイル
サーバにしてしまった。今更OSは変えられない。

>>38
NTはスワップアウトできるんだ！初めて知ったよ。
だけど実際に外に出されるケースってあるのかな？
pagetableよりもアクセス頻度の高いデータってそんなにないような・・

>> 35

GDT, LDT ってのは page table じゃなくて descriptor table でしょ.
こいつは paging じゃなくて segmentation のための仕組みなので, ふつー,
UNIX/WinNT/Win2000 的には無用の長物に近いでしょ.
(x86 の場合仕方なしに使う必要があるけど)

>> 37, 38

WinNT も最初の設計時にはカーネルは non-pageable だったんだけど, Mach
の偉い人に指摘されてから直したんでしょ.
BSD 系の VM の場合, プロセスが swapout されている時には pagetable は
swapout されるんじゃなくて解放されるので, 当然実メモリ中には常駐しなく
なるっす. それどころか pagetable を swap に書き込む必要性さえないのだ.
とゆうわけで, それほど馬鹿にするもんでもないのでは?

普段これといって優位性を見出せないWindowsユーザーが
騒いでるだけだって。ちょっとかわいそう。

>43
煽りなんていりません

>>42
loadable moduleによってrebootの危機に晒されている

>>42
pagetable開放されるんだあ。でもなんかそれovercommitに弱そうな
気がするんだが気のせいかなあ。あとプロセスのメモリ空間が
全部Swapoutされないとpagetableは開放されないはずだよね、
となるとほとんど開放されることはないような気もするなあ。

> pagetable開放されるんだあ。でもなんかそれovercommitに弱そうな
> 気がするんだが気のせいかなあ。

それは完全に気のせい. 確かに現在の 4.4BSD 系 VM には overcommit 問題
があるけど, この page table 解放の仕組みは, overcommit とは全く関係ない.

> あとプロセスのメモリ空間が 全部Swapoutされないとpagetableは開放され
> ないはずだよね、

いやいや, それだけじゃなくて, ある page table が使われなくなっただけで
起きる. せっかくソースが公開されているんだから, pmap.c の中の
pmap_remove(9) を読んでみたり, また pmap_remove(9) が呼ばれるタイミング
を調べてみたりすれば確認できるよ.
この自分の目で調査できるって点が,ソースのある OS の嬉しいところだよね.
Windows 系の OS でこれができる人って相当限られている上に, 守秘義務の関
係でその結果をここで書くことも難しいんじゃないかな.

> となるとほとんど開放されることはないような気もするなあ。

"ps axl" で表示した結果, STAT フィールドに W フラグが表示されている
プロセスは swap out されているから, 全 page table が解放されてる.
少なくとも, うちの環境では, それなりの数が表示されてるよ.
しかも, それだけじゃないのは上に書いた通り.

Windows NT/2000/XP の場合も, swap out されている時だけじゃなくて,
通常の paging 時にも page table 自体が page out されるのかな?
38 の書き込みを見ると, paga table が pageable な製品と, そうでない製品
があるみたいだけど, ここら辺の情報ってどこを見れば分かるの?

まとめると
WinNT kernelも page out化
*BSD(区別しないでいいのか?) page tableは swap outされたら消える
Linux シラネーヨ
か?

でも page tableってそんなでかいのか?
所詮 working setに比例した大きさだと思うが。

32bitだとそんなに気にすることない大きさだけど
やっぱ64bitになると馬鹿にならない大きさだよね。
やっぱできないより、出来たほうがいいべ。

>>1
あまり詳しくないけど、偏見交じりの相違点となると

・ネイティブで扱える整数値の範囲が違う（32bit int と 64bit int）

これがすべての立脚点だと自分では思うす。

　バス幅、メモリ空間の大きさが異なるのは自明の話だけど、Epoch time をあらわ
すデータ長（32bit から 64bitへ）とかファイルオフセットの大きさ（2^64 - 1
バイトまで扱える）とかも広くなります。あたりまえだけど、mmap()した後のオフ
セット値もでかくとれますな。

　プロセッサや OS によっては 32bit OS でも Over 2GB とか扱えるけど、やっ
ぱりどっか無理はあります。つーか美しくない。