扩展 386 段选择器中的基地址宽度以超出 32 位操作系统中的 4GB RAM 限制？
随着内存需求的快速增长，如今越来越多的系统需要 64 位机器来访问更大的 RAM。
FWIK在386保护模式下，内存指针由两部分组成：段选择器指定的基地址（32位）和基地址加上的偏移地址（32位）。
要以 64 位重新编译所有程序，需要做很多工作，例如对于 C/C++ 程序，机器相关的“int”类型（在 32 位机器中是 32 位，在 64 位机器中是 32 位）在 64 位机器中）如果使用不正确将会导致问题。即使重建也没有问题，随着内存需求的不断增长，例如有一天我们将使用128位机器，我们是否需要再次重建所有程序以符合新的字长？
如果我们只是将基地址扩展到64位，从而在整个RAM上创建一个类似于4GB窗口的段，我们甚至根本不需要64位操作系统，不是吗？大多数应用程序/进程不需要在服务器端访问 4G+ 内存，例如，如果文件服务器使用 20GB RAM 进行缓存，则可以将其分为 10 个进程，每个进程访问 2GB，因此 32 位指针是足够的。并将每个放在不同的段中以覆盖20GB内存。
扩展段限制对上层程序是透明的，要做的只是CPU和操作系统的事情，如果我们能让Linux支持在不同的64位段上分配内存（尽管目前段基地址是32位）然而），我们可以轻松地在 32 位机器上使用 1TB RAM，不是吗？
我说得对吗？
As the memory requirement grows fast, today more and more system requires 64-bit machines to access even larger RAM.
FWIK in 386 protected mode, a memory pointer consists of two part: the base address (32-bit) specified by a segment selector, and the offset address (32-bit) added to the base address.
To re-compile all programs in 64-bit there's a lot of work to do, for example for C/C++ programs, the machine-dependent `int' type (which is 32-bit in 32-bit machine, and 64-bit in 64-bit machine) will cause problems if it's not used correctly. Even it's being rebuilt with no-problem, as the memory requirement continuous grow, for example someday we'll use 128-bit machines, and do we need to rebuild all the programs again to conform the new word size?
If we just extend the base address to 64-bit, thus make a segment like a 4GB window on the entire RAM, we don't even need a 64-bit OS at all, isn't it? Most of applications/processes won't have to access 4G+ memory, at server side, for example if a file server utilizes 20GB RAM for caching purpose, it may be split into 10 processes with each access 2GB, thus a 32-bit pointer is enough. And put each in different segment to cover 20GB memory.
Extend the segment limit is transparent to upper layer programs, what should be done is only about CPU and the OS, if we can let Linux to support to allocate memory on different 64-bit segments (though currently the segment base address is 32-bit yet), we can easily utilize 1TB RAM on 32-bit machine, isn't it?
Am I right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
内存访问是在 CPU 上使用汇编指令完成的。如果 CPU 有 32 位用于寻址内存段，则它最多可以寻址 4 GB，但不能超过。为了扩展此行为，CPU 需要一个 64 位寄存器。
32 位操作系统也有同样的限制。 64 位操作系统可以执行 32 位程序并使其访问高于 4 GB 的基地址，但需要 64 位处理器。
总之，操作系统（以及该操作系统上运行的进程间接访问）可访问的内存窗口的限制受到处理器寄存器宽度（以位为单位）的限制。
所以，你是不对的。
PAE 可能适合您的需求，但您需要硬件和操作系统支持，这是据我所知很常见。
The memory access is done on CPU, using assembly instructions. If the CPU have 32 bit for addressing a memory segment, it can address up to 4 GB, but no more. To extend this behavior, the CPU needs a 64 bit register.
A 32 bit OS has the same limitation. A 64 bit OS can execute 32 bit programs and make them access a base address higher than 4 GB, but needs a 64 bit processor.
As conclusion, the limit of the memory window accessible by the OS (and indirectly by the process running on that OS) are limited by the processor register width, in bits.
So, you are not right.
Propably the PAE fits your needs, but you need the hardware and the operative system support, which is very common as far as I know.
现在，您可以通过在 64 位内核上运行 32 位进程来获得这种效果。每个 32 位进程只有 4GB 虚拟地址空间，但这些地址可以映射到内核可访问的物理内存中的任何位置。不过，这并不是使用分段来完成的；它只是通过分页完成的。
You can get exactly this effect today by running 32 bit processes on a 64 bit kernel. Each 32 bit process only has a 4GB virtual address space, but those addresses can be mapped anywhere in the physical memory accessible to the kernel. It's not done using segmentation, though; it's just done through paging.