アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
もしかして (スコア:1)
OS/400とかPalmOSとかと同じかんじだと思っていい?
Re:もしかして (スコア:0)
OS/400とPalmはまったく稼働環境が違うのれすが
なにをいいたいのかよくわかりません。
Re:もしかして (スコア:0)
Re:もしかして (スコア:0)
単一レベル記憶では?
Apollo Domain も UNIX 系 OS に含めるなら、1980年代中盤からあり
ますね。
Re:もしかして (スコア:0)
Re:単一レベル記憶 (スコア:0)
固定長アドレ
Re:単一レベル記憶 (スコア:0)
Re:単一レベル記憶 (スコア:0)
あれ、それでは Domain OS は SLS ではないというご意見なんでしょうか?
SLSという概念は、Multics発祥なわけですが、Multics の人々は [stratus.com]
Domain OS が single level storage を実現していると言っている
わけです
Re:単一レベル記憶 (スコア:0)
「マップする」という時点でシングルじゃねーの。
Re:単一レベル記憶 (スコア:0)
それは AS/400 的な誤解でしょう。
Apollo Domain が single level storage を実装したシステムであるという定評と矛盾しますから。
Re:単一レベル記憶 (スコア:0)
Aegisは知らないが、MulticsにおいてはメモリはSLSのキャッシュにすぎないので「ある空間から別の空間にマップする」という概念はないの。
Re:単一レベル記憶 (スコア:0)
> ので「ある空間から別の空間にマップする」という概念はないの。
Multicsのことは知っています。
問題は、「ある空間から別の空間にマップする」という操作を要する
ことが、SLS であるかどうかの判断基準になるかどうかという点ですが、
Apollo の Aegis がその操作を要すにも関わらず、SLS であると
Multics の人々から認められている以上、判断基準になると考えるのは
誤りだと思います。
> Aegisは知らないが
Re:単一レベル記憶 (スコア:0)
Multicsは同一のファイルは同一のセグメントに対応しているから単一レベルと言えるんだけど。
>なお、
Re:単一レベル記憶 (スコア:0)
> 空間と別の空間の二つがあるわけで、それはSLSとは言わないんだよ。
話がループしてますが、もう一度引用しておきます。
「ある空間から別の空間にマップする」操作を必要とするOS である [multicians.org]
Apollo Domain の OS (Aegis) を、当の Multics の人々自身
Re:単一レベル記憶 (スコア:0)
あんたの勘違いじゃねーの。
Re:単一レベル記憶 (スコア:1, 参考になる)
既に #685344 [srad.jp] で説明してます。
Aegis はアドレスレジスタが 32ビットしかない MC68020 上で動作する OS でしたから、マッピング操作なしに 128bit のアドレス空間にアクセスすることは、ハードウェア的に不可能です。
ms_$mapl() という関数名で検索すれば、Aegis で file mapping を行っているソースコードを今でも見つけられるようですよ。
例えば ここ [sourceforge.net]とか、ここ [gnome.org]とか、ここ [koders.com]とか、ここ [netlib.org]とか。
Re:単一レベル記憶 (スコア:0)
> Aegis ではオブジェクトアドレス空間が 128bit ある
ここが重要ではないですか。
単一レベル記憶では一つのリニアな抽象アドレス空間があって
それを実CPUのアドレス空間にマップしているのです。
実CPUのアドレス空間へのマップは単に実装の問題であって
OSアーキテクチャではない。
それに対してLinuxなど通常
Re:単一レベル記憶 (スコア:0)
128bit仮想空間を32bitのメモリアドレス空間でキャッシュするのだから、ハードなりソフトなりでなんらかの仕掛けは必要だよ。
イエスかノーで答
Re:単一レベル記憶 (スコア:0)
> 場合に、同じアドレスが帰ってくるか?」
いいえ、同じ仮想アドレスが返ってくるとは限りません。
オブジェクト・アドレス空間の方が仮想アドレス空間よりずっと広いわけです
から、もしも同じオブジェクトには同じ仮想アドレスが返ってくるとすると、
たまたま同じ仮想アドレスにマップされるような異なるオブジェクトを 2つ
同時にマッ
Re:単一レベル記憶 (スコア:0)
MulticsのSLSではこれはそもそもありえない。
あんたの言い分では、オブジェクトはメモリマップされる以前から割り付けられる仮想アドレスが一意に決まっていることになる。
システム38ではまさにその通りだ。
Multicsでは
Re:単一レベル記憶 (スコア:0)
> それを実CPUのアドレス空間にマップしているのです。
Multics は SLS ですが、アドレス空間は「リニア」じゃないです。
> それに対してLinuxなど通常のUNIX系OSではアーキテクチャで
> ファイルとファイル内オフセットという2次元のアドレス空間
> を扱います。
Multics のアドレス空間も、ファイルを表すセグメント番号と
そのセグメント内のオフセットの2次元で表します。
> したがってファイルはリニアなアドレス空間を
> 持つメモリとはモデルが異なり、そのアー
Re:単一レベル記憶 (スコア:0)
> MulticsのSLSではこれはそもそもありえない。
え?
私は、もし Apollo Domain が、「すでにメモリにマップされているファイルをもう一度マップした場合に、同じアドレスが返ってくる」とすると、どういう問題が生じるかを説明しているんですが。
この文章の対象は、Multics ではなくて、Apollo Domain です。
Multics の場合、こういう問題が生じないことは明らかです。説明するまでもありません。
> あんたの言い分では、オブジェクトはメモリマップされる以前から割り付け
> られる仮想アドレスが一意に決まっていることになる。
いいえ違います。一意に決まっ
Re:単一レベル記憶 (スコア:0)
ファイルAは一度アンマップされてるんだろ。質問の意味を取り違えるなよ。
ファイルAをアンマップせずに再度マップしようとした場合にどうなるかを聞いてるんだよ。
二度目のマップの試みで、最初のマップと異なるア
Re:単一レベル記憶 (スコア:0)
> 聞いてるんだよ。
なるほど、元の質問を誤解していました。申し訳ない。
答は同じく「いいえ」です。別々にマップされます。
Apollo Domain は、UNIX の mmap() と同様、マップ時に copy-on-write 属性をつけたり、あるいは、読み書き保護のモードを変えてマップしたりすることができます。このためには、当然、同一のファイルを別々のアドレスにマップする能力が必要になります。
このような機能は、ページング能力のあるハードウェアでは当たり前に実現できますが、もし AS/400 のように単一のアドレス
Re:単一レベル記憶 (スコア:0)
そうすると、メモリにマップされた時点でオブジェクトの同一性は
なくなるのか。
俺にはむしろこっちのほうが使いづらいと思う。
copy on writeはコピーなので同一オブジェ