「FS」/「GS」レジスタの目的は何ですか?


102

だから私は次のレジスタとその使用法が何であることになっているのか知っています:

  • CS =コードセグメント(IPに使用)

  • DS =データセグメント(MOVに使用)

  • ES =宛先セグメント(MOVSなどに使用)

  • SS =スタックセグメント(SPに使用)

しかし、以下のレジスタが何のために使用されることを意図していますか?

  • FS = "ファイルセグメント"?

  • GS = ???

注:私は特定のオペレーティングシステムについて尋ねるのではなく、CPUが何のために使用することを意図していたかについて尋ねます。


24
私の知る限り、これら2つのFとGは何の意味もありません。CPU(および命令セット)に6つのユーザー指定可能なセグメントレジスタのためのスペースがあっただけで、誰かが「S」タックセグメントのほかに「C」と「D」(コードとデータ)の文字に気付いた「E」は「追加」セグメントであり、「F」と「G」はちょうど続いた。
torek

3
あなたがその時そこにいなかった場合(そして私がIntelの設計チームのどこにもいない他の海岸にいた)でない限り、他の誰かの頭で何が起こっているのかを知ることは常に困難でした。
torek

20
私たちがBSレジスターでどれほど楽しかったかを考えてみてください:-}
Ira Baxter

5
私はいつも「グラフィックセグメント」としてGSを使用していました。:-)
Brian Knoblauch、2012年

2
「G」エネルギー「S」セグメントはどうですか?
SSアン

回答:


109

それらが意図されていたものと、WindowsとLinuxで使用されているものがあります。

セグメントレジスタの背後にある本来の目的は、独立した永続的な仮想ストアの一部となることを目的とした、メモリのさまざまな(大きな)セグメントにプログラムがアクセスできるようにすることでした。このアイデアは、ファイルを単にアドレス可能なメモリセグメントとして扱う1966年のMulticsオペレーティングシステムから採用されました。BS「ファイルを開く、レコードを書き込む、ファイルを閉じる」ではなく、ダーティページフラッシュで「この値をその仮想データセグメントに保存する」だけです。

私たちの現在の2010オペレーティングシステムは大きな一歩後退です。そのため、それらは「Eunuchs」と呼ばれています。あなただけに対処することができますプロセススペースの単一セグメントいわゆる「フラット(IMHO鈍い)アドレススペース」を与える。x86-32マシンのセグメントレジスタは、実際のセグメントレジスタに引き続き使用できますが、誰も気にしていません(前のIntel社長であるAndy Groveは、前世紀にかなり有名なパブリックフィットでした。この機能を実装するための彼のお金、誰もそれを使うつもりはなかった。

AMDは64ビット版に移行する際、Multicsを選択肢から除外してもかまわないと判断しました(これは慈善の解釈です。非慈悲なのはMulticsについて無知だったためです)、64ビットモードのセグメントレジスタの一般的な機能を無効にしました。スレッドがスレッドローカルストアにアクセスする必要性が依然としてあり、各スレッドは、すぐにアクセス可能なスレッド状態(たとえば、レジ​​スター内)のどこかにポインタを必要としました...ローカルストアをスレッド化します。WindowsとLinuxの両方がこの目的で32ビットバージョンでFSとGS(Nickの説明に感謝)を使用したため、AMDは64ビットセグメントレジスタ(GSとFS)をこの目的でのみ使用することを決定しました(私はあなたができると思います)プロセススペース内の任意の場所を指すようにしてください(アプリケーションコードでロードできるかどうかはわかりません)。

各スレッドのメモリマップに、そのスレッドローカルストレージ([セグメント]レジスタポインターは不要)である絶対仮想アドレス(たとえば、0〜FFFなど)を持たせることは、アーキテクチャ上、見た目が良いでしょう。私は1970年代に8ビットOSでこれを行いましたが、レジスターの別の大きなスタックが動作するように、それは非常に便利でした。

したがって、セグメントレジスタは付録のようなものになりました。それらは痕跡の目的を果たします。私たちの集団的損失に。

歴史を知らない人はそれを繰り返す運命にありません。彼らは何かおかしなことをする運命にある。


10
@supercat:65536倍のストレージをアドレス指定できるようにする、よりシンプルでより優れたスキームは、セグメントレジスタを下位16ビットの完全な上位16ビット拡張として扱い、これは本質的に286、386そしてMulticsはしました。
Ira Baxter

3
@IraBaxter:このアプローチの問題は、80286スタイルのセグメントのオーバーヘッドが十分に高く、最終的に各セグメントに多くのオブジェクトを格納する必要があるため、すべてのポインターにセグメントとオフセットの両方を格納することです。対照的に、メモリ割り当てを16バイトの倍数に丸める場合は、8086スタイルのセグメンテーションにより、オブジェクトを識別する手段としてセグメントのみを使用できます。16バイトまでの割り当ての丸めは、1980年にはやや厄介であったかもしれませんが、各オブジェクト参照のサイズを8バイトから4に減らした場合、今日の勝利を表すでしょう。
スーパーキャット2013

3
これらのレジスタ、最新のオペレーティングシステムで使用されます。それらは主に、少なくとも現在x86チップで利用可能な2つの主要なOSでは、タスク制御ブロックに関する情報を参照することに専念しています。また、本来の目的でさえ「一般的な目的」ではなくなっているため、あまり使用できません。x86-64システムでは、スレッド制御ブロックでアクセスできる情報が必要になるまで、それらが存在しないように見せかけるのがよいでしょう。
Ira Baxter

5
付録のアナロジーは時代遅れの科学に基づいて本当に悪いです。それは免疫系に関連しているので、間違いなく「痕跡的」ではありません。実際の投稿を損ないます。それ以外は良い反応です。
code_dredd

5
セグメント化されたメモリとフラットメモリの面白くて保留のない扱いに感謝します:) 6809(ページメモリの有無にかかわらず)、6502、z80、68kおよび80 [123]?86にもコードを記述したので、私の見解はセグメント化されています思い出はホラーショーで、歴史のゴミ箱に預けられて良かったです。thread_localデータへの効率的なアクセスのためのFSおよびGSの使用は、履歴エラーの予期せぬ結果です。
Richard Hodges 2018年

44

レジスタFSGSはセグメントレジスタです。それらにはプロセッサーで定義された目的はありませんが、代わりにそれらを実行するOSによって目的が与えられます。Windows 64ビットでは、GSレジスターはオペレーティング・システム定義の構造を指すために使用されます。 FSまたGS、OSカーネルがスレッド固有のメモリにアクセスするために一般的に使用されます。ウィンドウでは、GSレジスタはスレッド固有のメモリを管理するために使用されます。LinuxカーネルはGS、CPU固有のメモリにアクセスするために使用します。


1
それらは、OS定義の目的で使用すること、または*dest++ = lookup[*src++];dest、lookup、およびsrcが3つの無関係な場所にある場合に不便であるようなことを行う必要があるコードを容易にすることを目的としていましたか?
スーパーキャット2013

8
Windowsでは、FSは確かにスレッド固有のストレージ用です。こちらのen.wikipedia.org/wiki/Win32_Thread_Information_Block
Nedkoの

2
Windowsだけではありません。GSは、OS X上のTLSにも使用されます。GSは、コンテキスト切り替え中にシステム構造を追跡するために64ビットカーネルでも使用されます。OSはそのためにSWAPGSを使用します。
2017

11

FSは、Windowsプロセスのスレッド情報ブロック(TIB)を指すために使用されます。

典型的な例の1つは(SEH)で、コールバック関数へのポインタを格納します FS:[0x00]

GSは一般に、スレッドローカルストレージ(TLS)へのポインターとして使用されます。そして、あなたが以前に見たかもしれない一例は、スタックカナリア保護(stackguard)であり、gccでは次のようなものを見るかもしれません:

mov    eax,gs:0x14
mov    DWORD PTR [ebp-0xc],eax

2
これは実際には質問の答えにはなりません。質問には、注記:特定のオペレーティングシステムについて尋ねるのではなく、CPUが何のために使用することを意図していたのかを尋ねています。
マイケルペッチ2018

9
@MichaelPetch ya so so this this q / s in this q / s in SO
zerocool

2

Intelマニュアルによると、64ビットモードでは、これらのレジスタは、いくつかの線形アドレス計算で追加のベースレジスタとして使用されることを目的としています。セクション3.7.4.1からこれを引き出しました(4巻セットの86ページ)。通常、CPUがこのモードの場合、このモードではセグメンテーションが使用されないことが多いため、リニアアドレスは実効アドレスと同じです。

したがって、このフラットアドレススペースでは、ローカルデータだけでなく特定のオペレーティングシステムデータ構造(ページ2793、セクション3.2.4)のアドレス指定にもFSおよびGSが役割を果たします決定。

32ビットモードと64ビットモードの両方でオーバーライドを使用する場合、いくつかの興味深いトリックがありますが、これには特権ソフトウェアが関係します。

「本来の意図」の観点からは、単なる追加のレジスターであるということ以外に、言うのは難しいです。CPUが実アドレスモードの場合、これはプロセッサが高速8086として実行されているようなもので、これらのレジスタはプログラムから明示的にアクセスする必要があります。真の8086エミュレーションのために、CPUを仮想8086モードで実行し、これらのレジスタは使用されません。


2

TL; DR;

「FS」/「GS」レジスタの目的は何ですか?

デフォルトのデータセグメント(DS)を超えてデータにアクセスするだけです。ESとまったく同じです。


長い読み:

だから私は次のレジスタとその使用法が何であることになっているのか知っています:

[...]

まあ、ほとんどですが、DSは「一部の」データセグメントではなく、デフォルトのセグメントです。すべての操作はデフォルトで行われました(* 1)。これは、すべてのデフォルト変数が配置されていた-本質的にdatabssです。これは、x86コードがかなりコンパクトである理由の一部です。最も頻繁にアクセスされるすべての重要なデータ(およびコードとスタック)は、16ビットの短距離内にあります。

ESは、その他すべて(* 2)、DSの64 KiBを超えるすべてにアクセスするために使用されます。ワードプロセッサのテキストのように、スプレッドシートのセル、またはグラフィックプログラムの画像データなど。想定されることが多いのとは異なり、このデータはあまりアクセスされないため、プレフィックスが必要な場合でも、より長いアドレスフィールドを使用するよりも害はありません。

同様に、文字列操作を実行するときにDSとESをロード(および再ロード)する必要があるのはわずかな煩わしさです-これは少なくとも、当時の最良の文字処理命令セットの1つによって相殺されます。

ユーザーデータが64 KiBを超え、運用を開始する必要がある場合、本当に痛いです。一部の操作は一度に1つのデータ項目に対して単純に行われますが(考えてくださいA=A*2)、ほとんどの場合、2つ(A=A*B)または3つのデータ項目(A=B*C)が必要です。これらのアイテムが異なるセグメントにある場合、ESは操作ごとに数回リロードされ、かなりのオーバーヘッドが追加されます。

当初、8ビットの世界からの小さなプログラム(* 3)と同じように小さなデータセットで、それは大した問題ではありませんでしたが、すぐに主要なパフォーマンスのボトルネックになりました。プログラマー(およびコンパイラー)。Intelは386で2つのセグメントを追加することでようやく安心を実現しました。そのため、メモリ内に要素が展開されている一連の単項二項、または三項演算は、ESを常にリロードしなくても実行できます。

プログラミング(少なくともアセンブリ)とコンパイラーの設計では、これはかなりの利益でした。もちろん、それ以上の数でもかまいませんが、3つでボトルネックは基本的になくなったので、無理する必要はありません。

名前の付け方は、F / Gという文字は、Eの後に続く単なるアルファベットの続きです。少なくとも、CPU設計の観点からは、何も関連付けられていません。


* 1-単純に2つのセグメントレジスタが必要なため、文字列の宛先にESを使用することは例外です。これらがなければ、あまり役に立ちません-または常にセグメント接頭辞が必要です。これにより、驚くべき機能の1つである(反復しない)文字列命令を使用すると、1バイトエンコーディングのために極端なパフォーマンスが発生する可能性があります。

* 2-後から考えると、「その他すべてのセグメント」の方が「追加のセグメント」よりも優れたネーミングだったでしょう。

* 3-8086 は8800が完成するまでのストップギャップ対策としてのみ意図されたものであり、主に組み込み世界が8080/85の顧客を維持することを目的としていたことを常に覚えておくことが重要です。


1
うわー、これを説明してくれてありがとう!これは多くのことを説明し、非常に理にかなっています!+1
user541686
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.