段寄存器的前世今生

今天在看反汇编代码的时候看到了许多段寄存器相关功能，就查了下FS和GS寄存器，结果发现了如下“八卦”……

文章出处：https://stackoverflow.com/questions/10810203/what-is-the-fs-gs-register-intended-for

FS和GS是段寄存器。他俩没有特定的CPU处理器作用，他俩的作用是由操作系统在运行时决定的。64位windows系统使用GS指向系统定义结构体的段地址。FS和GS通常被内核用于访问线程独有的内存空间。Windows用GS来管理线程独有内存。Linux则用于访问CPU专用内存。

一开始，段寄存器是被设计用来允许程序访问许多不同的（大）内存段，这些内存段本来是独立的，是持久虚拟存储的一部分。这个想法来自1966年的Multics操作系统，该系统将文件视为简单的可寻址内存段。不用阻塞于IO来“打开文件，写记录，关闭文件”，只是“存储这个值到虚拟数据段”脏页刷新。

2010年左右，出现了一批现在称为"阉割版"操作系统。这些操作系统使用所谓的扁平化寻址技术，程序只能对进程空间的单个段进行寻址。所幸x86-32机器上的段寄存器仍然可以用于真正的段寄存器。Intel时任掌控者完全没明白这个意义的内涵，甚至断言这是个根本没用的功能。哥们，滚吧！同一时间，AMD在做64位芯片设计的时候也犯了几乎相同的错误，认为Multics是一种无关轻重的功能（不客气的说，他们根本不懂这个Multics），AMD在64位模式禁用了段寄存器功能。

实际上，线程仍然需要访问线程私有存储空间，每个线程都需要一个指针来指向这些线程私有空间，在某些情况下线程还需要可以直接访问这些私有空间（常见的操作系统Thread Local）。基于上述原因，Windows和Linux的32位版本都使用了FS和GS。

鉴于此，AMD不得不重新设计了64位模式下的段寄存器，让这个模式下的段寄存器（FS和GS）只用于线程私有空间的访问。Intel此时并未支持64位下的段寄存器，因此在市场竞争中陷入被动。未免在64位CPU的竞争中被市场淘汰，Intel直接抄袭了AMD的设计（另外则是前领导者退休了）。

如果扁平化寻址技术能让每个线程的地址空间中存在一个指向线程私有变量存储空间的指针（即使没有段寄存器），这也是一个更优雅的架构。原文作者曾经在20世纪70年代，就在一个8位操作系统中实现了这一点，它非常方便，就像有一大堆寄存器可以使用一样。

现在的段寄存器有点像人类身上的阑尾，不管以前存在多么强大的功能，现在剩下的只是一小部分。这是我们集体的损失！！！

那些不了解历史的人注定不会重蹈覆辙；他们注定要做一些更愚蠢的事情。