アセンブラ…　（°Д°)ﾊｧ？

セグメトアドレスってページングの後に決定じゃなかった？

だから
セグメントベース=リニアアドレス≠物理アドレス

ページングoffならリニアアドレス=物理アドレス

>>942
ベースアドレスには物理アドレスをそのまま入れてやればいいですね。
その算出法というのが何を意図してるのかわからないのだが（ﾘｱﾙﾓｰﾄﾞと混同してる？）、
ベースアドレスの値のままでいいでつ

>>942
http://www.intel.com/jp/developer/download/

てかＣ++とか使いこなせる人がさらなるスピードアップのために使うものでないのか？

今時アセンブラで書くにはそれなりの理由があるので、
単にさらなるスピードアップと言うだけで使うわけじゃないから、
C, C++を使いこなせるかどうかはあまり関係がない(相関はあるだろうが)。

言語処理系なんかでCじゃ書けないことを実現するとか。
SSEなんかのSIMD命令の利用も、まあ更なるスピードアップでもあるけれども、
意味合いとしてはCじゃ書けないことの部類に入るかな。

>>942
セグメントベースには論理アドレスを入れるから>>943の言う通り。
ページングを利用する場合も0x0Eの割り込み処理（ページング機構といった方が早いか）がしっかり整っているなら、別に気にする必要ないと思う。

リアル／仮想8086モードでのセグメントとオフセットの話はその通り。

何してんのか知らないけど頑張ってね。

プロテクトモード移行だからreal to prtectedなんだろな
2つデスクリプタ作って、うぞうぞやってればその内できるよ

>>950
正直言って君の書いたプログラムを使いたいとは思わない。

286の設計段階で、セグメントベースもリミットと同じように
4Kごとにしてしまえばよかったのに。なんでだめなの？

あ、よく考えたらやっぱだめか。
286の段階ではディスクリプタ(8byte)の先頭から6バイト分しか
使われてなくて、リミットのオフセット4K(Gビット=1)ってのは
386から導入されたものだってことだね。286のOSは、64kの
セグメントを複数切り替えて動作する、純粋なリアルモード
のアプリケーションを複数走らせるものだったということなのね。。

皆さんどうもありがとうございます。
real to Protectのコードを書いているのですが。どうにも3rd exceptionが発生してだめなんです…
Monaの旧スレを見ながらやっているのですが…

　もうちょっとがんばってやってみます

286のOSだとプロセスごとにGDTを割り当てて、
タスク切り替え時にGDTRを、ちょうど386がCR3を
書き換えるみたいに、入れ替えるということなのね。
なるほど。。。

>>942
実際に手を動かした人にだけ技術力はつく！がんばれー
漏れも286のOS作ってみたくなってきたｗ

>>942
>1000h * 16 + 0000h

8086ではセグメントレジスタの値は自動的に16倍されるけど、
286/386のプロテクトモードにおけるセグメントディスクリプタ内の
ベースアドレスは16倍されないはず。セグメントの開始アドレスは
バイト単位で指定できるようになってる。

286ではベースアドレスに24ビット = 16MB
386ではベースアドレスに32ビット = 4GB
のリニアアドレスの領域指定できる。

http://www.google.co.jp/search?q=cache:Ns4C_6fcKCgJ:pc5.2ch.net/test/read.cgi/jisaku/1082357989/401-500+286+%E3%82%BB%E3%82%B0%E3%83%A1%E3%83%B3%E3%83%88%E3%80%80%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AB&hl=ja
このスレの470は大きな勘違いをしてるな。
>ただ、セグメントサイズそのままに16MBに広げた286はどうかと思うよ。

セグメントサイズはそのままって、これは当たり前。8086で動作していた16ビット
アプリケーションをプロテクトモードで同時に複数走らせることを目的としてるんだから。
ディスクリプタの7バイト目にDビットがあるが、これは286では有効ではなく、
32ビットオペランドや32ビットアドレスは386で初めて使えるようになったわけだし。

リニアアドレス空間が16MBというのを小さいと見るなら、確かにそうかもしれないけど。。

>>952だけど、やっぱりいろいろ考えると変だな。386のリミットの
4kオフセットはでかすぎにしても、ディスクリプタ内のベースとリミットは
8086のセグメントレジスタのように無条件に何倍かにしてもよさそうだ。
8086ですら、16バイトごとにセグメントっていうスコープを割り当てて
メモリ空間使ってたわけだし。286のOSの役割は16ビットアプリケーションに、
セグメントディスクリプタのPビットを386のページエントリのPビットと
同じようにして使って、連続した1MBの領域があるかのように見せるだけだしな。

そもそも286の段階でセグメントのリミットなんて必要だったのかな？8086の
アプリケーションは1MBの領域をアプリケーション内でセグメントレジスタ
という物差しを割り当てて使ってただけでしょ？リミットなんてない。
セグメント指定したら64kすっぽり読み書き可能。OS(特権モード)の
ために用意されたってことかいな。

そろそろ次スレか？

アセンブラ…　(´･ω･`)ｼｮﾎﾞ━━ﾝ!!!

でおながいします

キモい顔文字ｲﾗﾈ

　　　　　アセンブラとかいうジジイ言語　　　　　
http://pc5.2ch.net/test/read.cgi/tech/1101329594/

次スレ

アセンブラ…　（´･∀･`）ﾍｰ
http://pc5.2ch.net/test/read.cgi/tech/1101390110/

◎店名　女性専用出張風俗店「LilyMotion」
◎営業時間　２４時間　年中無休
◎利用できる場所　ホテルor貴女の自宅
◎利用できる方　女性のみ（カップルの方のコースも別にあります）
コースと料金（女性の方お１人でご利用の場合）
　６０分（１時間）　１００００円
１２０分（２時間）　２００００円
１８０分（３時間）　３００００円
２４０分（４時間）　４００００円
３００分（５時間）　５００００円
指名料　２０００円
◎お相手は全て当店の指導を受けた素敵な優しい女性ばかりです。
◎女性を満足させるためのテクニック＋αがあるのは当店だけです。
◎ピンクローター、ローション、双頭バイブ等のオプション料や追加料金は頂きません。
◎年会費無料の会員登録をされますと全コース２０００円オフになります。
◎会員様には男性を指名できる特別限定コースもご用意しております。
◎カップルでご利用の際は下記コースと料金になりますのでご注意下さい。
コースと料金（男性と女性もしくは女性と女性のカップルでご利用の場合）
１２０分（２時間）　２３０００円
１８０分（３時間）　３３０００円
２４０分（４時間）　４３０００円
３００分（５時間）　５３０００円
指名料　２０００円

>>957
それ書いたの俺だわ。
今読むと読点が変だ。恥ずかしい。

8086との互換性のことまでは考えてなかったです。
16MBもの広大な空間を64KBに細切れにしたら使いにくいよ、ということが言いたかった。

8086を作った人達は、8080の16ビット版を作る気だったんだと思うよ。
当時のプログラムは1プロセスあたり64KBで十分で、
それを複数個同時に動かすために1MBのメモリ空間を用意し、
バンク切り替えよりも気が利いている程度のものとして作られたのだと思う。
セグメントレジスタを複数個用意するのはOSに必要だからいいとしても、
それをユーザモード(んなものはないわけだが)に解放したのが間違いだと思う。

>>964
8085の16ビット版だろうね。
で、ユーザモードなんて概念がないんだから開放するしかないのだが。

>>964
8086にだってプロテクトモードを設けることはできたでしょう。
1MBの領域を細切れにし、2,3のプログラムで分ける。
でもそれなら、セグメントレジスタには16bitも必要ないでしょうね。
もっと目の粗いものでも十分だった気がします。8bitで、純粋に
GDTのインデックスを指定するためのものという扱いです。
ディスクリプタも4byteぐらいに抑えておけばGDTのサイズもそれ程
膨れ上がりません。

やはり8086のセグメントは単一のアプリケーションに64k以上のメモリ空間を、
バンクの切り替えにより、自由に操作可能とするためのものだと思います。
またUNIXのようにプロセスをバンバン起動するような利用形態は8086では
考えられていなかったのではないでしょうか、どうでしょう。
当時の様子を知らない、素人の推測ですのであてになりませんが。

どうなんでしょう、中の人じゃないので、本当のところはわかりません。

もし、セグメントレジスタを8ビットにして、4KB毎でしか区切れないようにしたら、
メモリがもったいない! と怒られていたと思う。
64KBや128KBしかRAMを積んでないマシンでの4KBは貴重ですから。

セグメントによる恩恵は、64KB越えのメモリアクセスは後からの話で、
まずは、メモリのどこにロードしても絶対アドレスへのジャンプを
書き換えなくてよい、というのが大きいです。

でも　ヒ　ュ　ー　ジ　モ　ー　ド　は　最　悪　に　遅　か　っ　た　な

huge mode？ なにそれ？

Cでセグメント境界を自動的に調節してくれるが、オーバーヘッドが大きい
諸刃の剣。
ってあれはhuge modelだな

age

>>966
重なっている部分は共有メモリとして使うつもりだったらしいよ

ume

もったいない

8086の段階でも、セグメントレジスタのビットシフト数を特殊レジスタに
設定しておくことにすれば、ソフトもハードもそう過大なオーバヘッドを招くことなく、
スケーラブルにできたんだよ。
それをしなかったのは、その時点で1MBは使い切れない程広大な
メモリ空間だと思われていたのが１つ。
さらに、次(々)世代ぐらいでは完全な新設計になるので未来のことを
考慮しておくのはナンセンスだと思われていたのがもう1つ。
ところが現実は・・・

いいじゃないか。386で対応できたんだから

>>975
8086なんて、プログラムが難しい以前に、調達が難しいだろ。

>>962
乙

>>975
集積度が足りなかったんだよ。それぐらい空気嫁。
それともお前は現在の基準で過去を裁く人間なのか？

>それともお前は現在の基準で過去を裁く人間なのか？
それ程深くもない知識で歴史を眺める以上、ある程度は避けられないですね。

というか8086が出たのが78年。286が出たのが82年。
'71 4004 4bit
'74 8080 8bit
'78 8086 16bit
'82 80286
'85 80386 32bit
この4年の間にどれぐらいの製造技術の変化があったのでしょうかね。
8086から286への変化はCPUの仮想化と見てもいいような変化だと思います。
また32ビット化も考慮されて(Pagingは想定外だったかも)設計されてる。
凄いですね。

>>967
>もし、セグメントレジスタを8ビットにして、4KB毎でしか区切れないようにしたら、
考えていたのは、8bitというのは単純にGDTのインデックス値であり、
ディスクリプタ内で16bitのベースアドレスと属性フィールドを持つような形です。
OSへ新規セグメント要求システムコールを呼び出し、GDTの8bitのインデックスを
割り振ってもらう、そんなものをイメージしてました。システム内ではGDTは
共有されるので、同一の特権モードの保護はなされません。
まあ、その当時にそんな重たいメモリ管理ユニットを乗せられるわけもないですねw

>>980
ものすごい勢いで集積度は上がりましたが。
ムーアの法則って聞いたことない?

>>それ程深くもない知識で歴史を眺める以上、ある程度は避けられないですね。
ならだまってろ。だれにでも発言権があるわけではない

>>982
何様のつもりだこの池沼。仕切り屋ふぜいが。

俺様のつもりだ。わかったらとっとと退場しろ

嫌だね。仕切るなら金払え。

CPUアーキの後だしジャンケン論争って、8ビットのころからちっとも
変わってないな

>8086の段階でも、セグメントレジスタのビットシフト数を特殊レジスタに
>設定しておくことにすれば、ソフトもハードもそう過大なオーバヘッドを招くことなく、

実際これのオーバーヘッドってどれぐらい？
アイディアとしては悪くなさそうだけど。

次スレは？

もう有るよ

>>989
本当だサンクス

今のエンジンは100馬力あるのに、昔のエンジンは10馬力しかないからクソ、
10倍大きくしてでも100馬力にするべきだったといってるような議論だな。

池沼を追い込むなよ。刺されるぞ