assembly - 16 ビット リアル モードでの物理アドレス式: セグメントに 16 を掛けるのはなぜですか?

Question

physical address=16*selector+offset
しかし、セレクターで 16 を乗算する理由がわかりません。

Answer 1

Z80 と「プログラマ互換」でありながら、64 kiB を超えるメモリを使用できるようにするために、初期の Intel プロセッサではメモリ セグメンテーションが導入されました。16ビットセグメントは、16ビットオフセットに追加される前に4ビット左にシフトされ（質問が主張する64倍ではなく、16倍を意味します）、20ビットアドレスになります。

Z80 に慣れているプログラマーは、OS が提供するセグメントを使用するだけで、与えられた 64 キロバイトのオフセットを自由に使用できます。新しいプログラマーは、セグメントのより洗練された操作を行うことができ、1 MiB のアドレス空間にアクセスできます (IBM PC はそれを 640 kiB に削減しましたが、独自の理由で)。

Answer 2

8088/8086 の目標は、プログラマがアドレス空間を 64K チャンクに分割し、アドレスがそれらの間の境界を越えるかどうかを心配することなく、16 ビット プロセッサが 1 メガバイトのアドレス空間を持つことができる手段を提供することでした。これは悪意に満ちたものですが、実際には、レジスタ サイズを超えるアドレスを処理するために私が見た他のどのアプローチよりも優れています。データが 64K 以下の項目に自然に分割され、項目を 16 バイト境界で開始するようにパディングしても問題ない場合は、比較的簡単に機能することがよくあります。16 による乗算 (より大きなまたはより小さな数の代わりに) はおそらく恣意的なものでしたが、16 進表記で物事をリストするときに便利に機能します。

8088 のセグメンテーション設計の主な欠点は、次のとおりです。

1. 2 つの汎用セグメンテーション レジスタでは「まったく」十分ではありません。一般的なパターンは、「あるオブジェクトから別のオブジェクトにデータをコピーし、3 番目のオブジェクトを使用して変換する」です。そのパターンは、オブジェクトの 1 つがコード セグメントまたはスタックに存在する場合にのみ効率的に実装できます。残念なことに、これは 80386 まで修正されませんでした。一般的な慣行はセグメントを無視することでした。
2. セグメント レジスタで何らかの演算を行う良い方法はありませんでした。DS または ES (または FS または GS) に 0x1000 を加算または減算する命令は、キャリーが設定されているか無条件に (合計 8​​ (または 16) オペコード)、セグメント処理を大幅に容易にします。
3. 「mov seg,immediate」の指示​​があったはずです。

当時、プログラマーは 8088/8086 について不平を言うことがよくありましたが、当時またはそれ以降に見た他のどの 16 ビット プロセッサよりもはるかに優れていました (注意: 68000 は 32 ビット プロセッサだと思います)。

Answer 3

64? もちろん？ウィキペディアなどを読んでください。64 を乗算することは、左に 6 ビットシフトするようなものです (ウィキペディアでは 4、つまり *16 である必要があります)。つまり、セレクターが 22 ビット アドレスの最上位 16 ビットを表すと言っているようなものです (ウィキペディアは 20 を報告しています)。これは、ウィキペディアにも記載されているリアルモードです (私ができるよりも優れています)。

Answer 4

64 をセレクターで乗算する理由がわかりません。

16 ビット ポインターは、64 KB を簡単にアドレス指定できます。

CPU 設計者は、1 MB をアドレス指定できるようにしたいと考えていました。

そのため、単一の 16 ビット ポインターを使用する代わりに、ポインターが 2 つのレジスター、つまりセグメント プラス オフセットによって実装されることを指定しました。 1MB。

値 (16) は、目的のアドレス範囲 (1 MB) を 16 ビット レジスタ サイズ (64 KB) の自然なアドレス指定可能性で割った結果です。つまり、16 は 1 MB / 64 KB から得られます。