TL; DR;
「FS」/「GS」レジスタの目的は何ですか?
デフォルトのデータセグメント(DS)を超えてデータにアクセスするだけです。ESとまったく同じです。
ロングリード:
だから私は次のレジスタとその使用法が何であるかを知っています:
[...]
まあ、ほとんどですが、DSは「一部の」データセグメントではなく、デフォルトのデータセグメントです。デフォルトですべての操作が行われる場所(* 1)。これは、すべてのデフォルト変数が配置されている場所です-基本的data
にとbss
。これは、x86コードがかなりコンパクトである理由の一部です。最も頻繁にアクセスされるすべての重要なデータ(およびコードとスタック)は、16ビットの短縮距離内にあります。
ESは、DSの64 KiBを超えるすべて(* 2)にアクセスするために使用されます。ワードプロセッサのテキスト、スプレッドシートのセル、グラフィックプログラムの画像データなどのように。よく想定されるのとは異なり、このデータはあまりアクセスされないため、プレフィックスが必要な場合は、長いアドレスフィールドを使用する場合よりも害が少なくなります。
同様に、文字列操作を実行するときにDSとESをロード(およびリロード)する必要があるのは、ほんのわずかな煩わしさです。これは、少なくとも当時の最高の文字処理命令セットの1つによって相殺されます。
本当に痛いのは、ユーザーデータが64 KiBを超え、操作を開始する必要がある場合です。一部の操作は一度に1つのデータ項目に対して単純に実行されますが(think A=A*2
)、ほとんどの操作には2つ(A=A*B
)または3つのデータ項目(A=B*C
)が必要です。これらのアイテムが異なるセグメントにある場合、ESは操作ごとに数回リロードされ、かなりのオーバーヘッドが追加されます。
当初、8ビットの世界(* 3)の小さなプログラムと同様に小さなデータセットでは、それは大したことではありませんでしたが、すぐに大きなパフォーマンスのボトルネックになりました。 (およびコンパイラー)。386 Intelは、さらに2つのセグメントを追加することで最終的に救済を提供しました。そのため、要素がメモリに分散された一連の単項、バイナリ、または三項演算は、ESを常にリロードせずに実行できます。
プログラミング(少なくともアセンブリーでは)とコンパイラーの設計にとって、これはかなりの利益でした。もちろん、もっと多くのことがあったかもしれませんが、3つでボトルネックは基本的になくなったので、やりすぎる必要はありません。
F / Gという文字の名前は、Eの後のアルファベットの続きです。少なくともCPU設計の観点からは、何も関連付けられていません。
* 1-文字列の宛先にESを使用することは例外であり、2つのセグメントレジスタが必要です。それらがなければ、あまり役に立ちません-または常にセグメントプレフィックスが必要です。これは、驚くべき機能の1つである、(反復しない)文字列命令を使用すると、シングルバイトエンコーディングのために極端なパフォーマンスが発生する可能性があります。
* 2-後から考えると、「その他すべてのセグメント」は「追加セグメント」よりもはるかに優れた命名でした。
* 3-8086は、 8800が完成するまでのストップギャップ対策としてのみ意図されており、主に組み込みの世界が8080/85の顧客を維持することを目的としていたことを常に覚えておくことが重要です。