アカウント名:
パスワード:
工夫次第ではいろいろ出来るハズだが。
なんですが、 「セグメント管理なんて煩雑なことは嫌」といって その工夫をあえてしないフラットメモリモデルを 採用することにしたのが 今の世の中というかUNIXとWindowsの隆盛なわけです。
「セグメント管理なんて煩雑なことは嫌」っていうのは, おそらく8086がまき散らした害毒でしょうね. 本来はセグメント機能によって主記憶の用途管理がちゃんとできるはずだったのですが, 8086上のDOS環境では単純に足りないアドレスをゴマかすための機構に成り下がっちゃいましたからね. 8086の設計ってConcurrent-CP/Mみたいに数10kB単位のプログラムをセグメント管理で複数動かすというものだったんじゃないですかね? そんな時代じゃ, たかだか数MB程度フラットに使わせろってのも切実な願いだったわけで.
時は過ぎて32bitアーキテクチャが標準になったら, 今度はプログラム側が要求するアドレス空間が32bitぎりぎりになっちゃって, やはりセグメントを使う余裕が無くなったというのが現状だと思います.
そう考えると, 今IA64やamd64によって過去の頸木から(完全ではないとはいえ)抜け出せそうな状況というのは, セグメント管理が見直される絶好のタイミングになるのではないでしょうか.
あながち8086ばかりでもなくて、上から降りてくる方の動きとしてMulticsの失敗も強烈なトラウマになってるんじゃないかと思うんですよ。いやむしろそっちじゃないかと。
ほら、プログラマにモデルを受け入れさせるとともにOSを供給しなきゃいけないじゃないですか。
ややこしいものを作りたくない背景のもとでUNIXは流行ったし、UNIXが動けばいいやでRISCのアーキテクチャも殆どフラット一色。VAX/VMS辺りは知りませんが、RISCの流れがそうなったってことはミニコンも末期頃にはセグメントが廃れてたんじゃないかと想像したり。 それを見て、何だフラットでいいのか、でWindowsもバージョンが3になったらセグメントを捨てた。 POWER/PowerPCだけはメインフレーム由来のOSとソフトウエアを載せるためにセグメントを盛り込み続けてるみたいですね。
セグメントを使う余裕、に関しては、x86ではセグメントをめいっぱい使えば論理アドレス空間は64TBあるし、PentiumPro以降のPAEを使えば物理アドレス空間は64GBまで伸びた。ま、どうせ仮想記憶をかぶせて使うので、物理アドレスが少なければディスクへ出ていくだけのこと。 つまり、プログラムの要求するアドレス空間が大きくなったことは セグメントに関する態度への影響としてはむしろ、 セグメントを求める方向への圧力になりますよね。
そんな中、セグメントという道具があっても使わなかったのに、 IA64やAMD64でフラットモデルの広い空間を手にしてしまったら、 やっぱりセグメントには戻りたくない人が大勢を占めるんじゃないでしょうか。
再びセグメントを使うか、 えいやっと倍にして64bitフラットで行くか、に関しては、 随分昔にMIPS R4000やUltraSPARCやAlphaが出る頃に検討され、 64bitフラットが採用されたわけですよね。 やっぱりセグメントは求められてなかったって ことじゃないかしら。
そういう選択を見ていると、 アーキテクチャレベルの二次元アドレス的なセグメントが 大々的に復活してくることはもはやないんじゃないかしら。 IA64のリージョンや64bitなPOWERのセグメントは 64bitアドレスの上位ビットがセレクタになるので、 結局プログラムから見えるイメージは64bitフラットですよね。 一方で、フラットなメモリ空間上に配置された 論理的なセグメント(TEXTとかBSSとか)を ページテーブル上で適当に権限設定して 使い分ける枠組みでなら、UNIXとの親和性も悪くなさそうで、 結局そっちへ行くんじゃないかしら。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
要するに (スコア:1)
欠陥アーキテクチャのCPUを使ったシステム(Windowsに限らず)に
依存しているこの世の中って？？？？
スタックオーバーフローなんて、OS/コンパイラー以前に
システム設計時につぶせるものだと思うのですが...。
^-_^-_-~
救世主はきっといる。
Re:要するに (スコア:1, 参考になる)
まぁ、セグメント単位での実行権限制御はあるのに、なぜページ単位では無かったのかとか疑問はありますが。
あと、スタックあふれじゃなくてバッファあふれだと思う。
Re:要するに (スコア:0)
重なりがあるように設定するWindowsがタコなだけではないだろうか？
おまけに、x86はセグメントのベースアドレスだけではなく、
セグメントサイズも設定できるようになっているのだから、
工夫次第ではいろいろ出来るハズだが。
# セグメントオーバーライドプリフィックスを使ってもSSのコードは
# 実行出来ないよね？
Re:要するに (スコア:1)
なんですが、 「セグメント管理なんて煩雑なことは嫌」といって その工夫をあえてしないフラットメモリモデルを 採用することにしたのが 今の世の中というかUNIXとWindowsの隆盛なわけです。
Re:要するに (スコア:1)
「セグメント管理なんて煩雑なことは嫌」っていうのは, おそらく8086がまき散らした害毒でしょうね. 本来はセグメント機能によって主記憶の用途管理がちゃんとできるはずだったのですが, 8086上のDOS環境では単純に足りないアドレスをゴマかすための機構に成り下がっちゃいましたからね. 8086の設計ってConcurrent-CP/Mみたいに数10kB単位のプログラムをセグメント管理で複数動かすというものだったんじゃないですかね? そんな時代じゃ, たかだか数MB程度フラットに使わせろってのも切実な願いだったわけで.
時は過ぎて32bitアーキテクチャが標準になったら, 今度はプログラム側が要求するアドレス空間が32bitぎりぎりになっちゃって, やはりセグメントを使う余裕が無くなったというのが現状だと思います.
そう考えると, 今IA64やamd64によって過去の頸木から(完全ではないとはいえ)抜け出せそうな状況というのは, セグメント管理が見直される絶好のタイミングになるのではないでしょうか.
Re:要するに (スコア:1)
あながち8086ばかりでもなくて、上から降りてくる方の動きとしてMulticsの失敗も強烈なトラウマになってるんじゃないかと思うんですよ。いやむしろそっちじゃないかと。
ほら、プログラマにモデルを受け入れさせるとともにOSを供給しなきゃいけないじゃないですか。
ややこしいものを作りたくない背景のもとでUNIXは流行ったし、UNIXが動けばいいやでRISCのアーキテクチャも殆どフラット一色。VAX/VMS辺りは知りませんが、RISCの流れがそうなったってことはミニコンも末期頃にはセグメントが廃れてたんじゃないかと想像したり。 それを見て、何だフラットでいいのか、でWindowsもバージョンが3になったらセグメントを捨てた。 POWER/PowerPCだけはメインフレーム由来のOSとソフトウエアを載せるためにセグメントを盛り込み続けてるみたいですね。
セグメントを使う余裕、に関しては、x86ではセグメントをめいっぱい使えば論理アドレス空間は64TBあるし、PentiumPro以降のPAEを使えば物理アドレス空間は64GBまで伸びた。ま、どうせ仮想記憶をかぶせて使うので、物理アドレスが少なければディスクへ出ていくだけのこと。 つまり、プログラムの要求するアドレス空間が大きくなったことは セグメントに関する態度への影響としてはむしろ、 セグメントを求める方向への圧力になりますよね。
そんな中、セグメントという道具があっても使わなかったのに、 IA64やAMD64でフラットモデルの広い空間を手にしてしまったら、 やっぱりセグメントには戻りたくない人が大勢を占めるんじゃないでしょうか。
再びセグメントを使うか、 えいやっと倍にして64bitフラットで行くか、に関しては、 随分昔にMIPS R4000やUltraSPARCやAlphaが出る頃に検討され、 64bitフラットが採用されたわけですよね。 やっぱりセグメントは求められてなかったって ことじゃないかしら。
そういう選択を見ていると、 アーキテクチャレベルの二次元アドレス的なセグメントが 大々的に復活してくることはもはやないんじゃないかしら。 IA64のリージョンや64bitなPOWERのセグメントは 64bitアドレスの上位ビットがセレクタになるので、 結局プログラムから見えるイメージは64bitフラットですよね。 一方で、フラットなメモリ空間上に配置された 論理的なセグメント(TEXTとかBSSとか)を ページテーブル上で適当に権限設定して 使い分ける枠組みでなら、UNIXとの親和性も悪くなさそうで、 結局そっちへ行くんじゃないかしら。
Re:要するに (スコア:0)
・コードもデータも0番地から考えておけばいい。
片方の領域のサイズが変わってもオフセットの変化を気にする
必要がないから、コンパイラ（リンカの方か？）が楽を出来る。
・データ領域をプログラムと思ってしまうことがない。
プログラムがバグってコード領域以外にジャンプしても、
ハードで簡単に検出出来る。
というような利点があると思いますが、どうでしょうか？
> IA64やAMD6
Re:要するに (スコア:0)
セグメントの概念自体はx86とは関係なくUNIXでも普通に使っているんですよ。
普通、プログラムファイルは
コードセグメント (実行可、読み書き不可)
定数情報セグメント (読込み可、書込み不可)
初期化付きデータセグメント (読み書き可)
初期化なしデータセグメント (読み書き可) ファイル上はサイズ情報のみ
スタックセグメント (読み書き可) ファ
Re:要するに (スコア:0)
プロテクトモードで割り込みが受取れるくらいまでのブートアップコードを書いてみれば386セグメントのめんどくささが分かるでしょう。