为什么操作系统不能使用整个 64 位进行寻址？为什么只有 48 位？
我正在阅读《理解Linux内核》。
64 位架构的分页
正如我们在前面所看到的 部分，两级分页通常是 由 32 位微处理器使用。 然而，两级分页并不是 适用于采用 64 位架构。让我们使用一个 思想实验来解释原因：
首先假设标准页面大小 4 KB。因为 1 KB 涵盖了一个范围 210 个地址，4 KB 涵盖 212 地址，因此 Offset 字段为 12 位。这留下最多 52 位 待分配的线性地址 表和目录之间 字段。 如果我们现在决定使用 64 位中只有 48 位用于寻址 （这个限制给我们留下了 舒适的 256 TB 地址空间！）， 剩余的 48-12 = 36 位将 必须在 Table 和 the 之间拆分 目录字段。如果我们现在决定 为这两个中的每一个保留 18 位 字段，页面目录和 每个进程的页表应该 包括 218 个条目，即超过 256,000 个条目。
“如果我们现在决定仅使用 64 位中的 48 位进行寻址”。为什么？ &为什么只有48位？为什么不是其他数字？
嗯，我只是一个普通的电脑用户&程序员。对我来说，很难相信 32 位寻址，即每个进程 4GB（更正确的是 2GB/3GB）地址空间是一个限制。如果您确实遇到了这个限制。请举个例子。
Windows 的此限制是多少？
我知道虚拟内存！=物理内存&处理器地址引脚与虚拟内存无关。这是一个完全不同的问题。如何知道处理器的地址引脚数量（= 地址总线的大小）。 http://ark.intel.com 处理器规格不包含此规格。
答案：
请参阅Paul Betts 的回答对第一个问题的合理回答。
I'm reading "Understanding Linux Kernel".
Paging for 64-bit Architectures
As we have seen in the previous
sections, two-level paging is commonly
used by 32-bit microprocessors.
Two-level paging, however, is not
suitable for computers that adopt a
64-bit architecture. Let's use a
thought experiment to explain why:Start by assuming a standard page size
of 4 KB. Because 1 KB covers a range
of 210 addresses, 4 KB covers 212
addresses, so the Offset field is 12
bits. This leaves up to 52 bits of the
linear address to be distributed
between the Table and the Directory
fields. If we now decide to use
only 48 of the 64 bits for addressing
(this restriction leaves us with a
comfortable 256 TB address space!),
the remaining 48-12 = 36 bits will
have to be split among Table and the
Directory fields. If we now decide to
reserve 18 bits for each of these two
fields, both the Page Directory and
the Page Tables of each process should
include 218 entries that is, more than
256,000 entries.
"If we now decide to use only 48 of the 64 bits for addressing". Why? & Why only 48 bits? Why not some other number?
Well, I'm just a regular PC user & programmer. Its just hard to believe for me that 32-bit addressing i.e. 4GB (2GB/3GB to be more correct) address space per process is a limit. If you really encountered this limit. Please give me example.
What is this limit for windows?
I know that virtual memory != physical memory & processor address pins have nothing to do with virtual memory. This is a completely different question. How to know the number of address pins (= size of address bus) for a processor. http://ark.intel.com specifications of a processor doesn't include this spec.
Answer:
See Paul Betts's answer for reasonable answer for 1st question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这些答案都不正确，操作系统不使用完整的 64 位的原因是因为页表会大得多（64 位已经达到 3 级页表），并且没有理由付费需要额外的间接寻址，48 位就足够了。 48 位也很方便，因为您可以获得一些额外的位来存储标志（指针标记）
None of these answers are right, the reason that OSs don't use the full 64-bits is because the page tables would be far larger (64-bit is already up to 3 levels of page tables), and there's no reason to pay the extra indirection needed, 48 bits is enough. 48-bits is also convenient because you get some extra bits to store flags in (pointer tagging)
系统架构师会做出权衡。 256TB 似乎足以容纳 1 个进程的地址空间。记住虚拟地址！=物理地址，一般来说，每个进程都有自己的地址空间。
只要指针是 64 位，这更多的是性能问题。如果&当 48 位成为限制时，可以调整操作系统以使用 64 位地址空间的更多位，而不会破坏应用程序的不兼容性。目前，建筑师们只是为自己争取了一段非常舒适的时间。
这可能与处理器端虚拟寻址功能有关，因为许多处理器现在都有内存管理单元 处理虚拟->物理内存映射。
这在很大程度上是无关紧要的。它是处理器实现各种物理寻址方案的一种方式。如果总线同步并且地址位及时复用，则 64 位处理器可以通过 64、32、16、8、4、2 或 1 个地址引脚实现其完整地址空间的外部地址/数据总线。再次强调，虚拟地址！=物理地址； 64 位虚拟寻址可以使用 48 位或 32 位物理地址来实现（只是内存限制为 248 或 232 字）。
更新：如果您确实想知道，则必须查看相关处理器的数据表。例如 Intel Core 2 Duo - 数据表的第 4.2 节讨论了信号——地址总线是 36 位宽（但实际上是 33 条信号线；数据宽度是 64 位 = 8 字节，因此在正确的数据对齐情况下，其他 3 条线可能是不必要的）
两个词：内存映射文件。
System architects make tradeoffs. 256TB seems like more than enough room for 1 process's address space. Remember virtual address != physical address, and generally speaking, each process has its own address space.
As long as pointers are 64 bits, this is more of a performance capability issue than anything else. If & when 48 bits becomes a limitation, the OS could be tweaked to use more bits of the 64-bit address space without breaking application incompatibility. For now, the architects are just buying themselves a very comfortable amount of time.
It may have to do with processor-side virtual addressing capabilities, as many processors now have memory management units to handle the virtual -> physical memory mapping.
This is for the most part irrelevant. It's a way for a processor to implement various physical addressing schemes. A 64-bit processor could achieve external address/data buses for its complete address space with 64, 32, 16, 8, 4, 2, or 1 address pin if the bus is synchronous and the address bits get multiplexed in time. Again, virtual address != physical address; 64-bit virtual addressing could be implemented with 48-bit or 32-bit physical addresses (just that you would be limited to 248 or 232 words of memory).
update: if you really want to know, you have to look at the datasheet of each processor in question. E.g. Intel Core 2 Duo -- section 4.2 of the datasheet talks about the signals -- the address bus is 36-bits wide (but is really 33 signal lines; the data width is 64-bit = 8 bytes so the other 3 lines are probably unnecessary with proper data alignment)
Two words: memory-mapped files.
目前的 x86-64 设计都没有为此使用超过 48 位 - 所以这是一个方便选择的数字，并且在 Windows 上也自动具有相同的限制。
No current x86-64 design uses more than 48 bits for this -- so it's a convenient number to pick, and it's automatically the same limit on Windows, too.
从 RAM 获取数据比从磁盘获取数据更有效（更快）。
SQL Server 的速度部分取决于它能够在 RAM 而不是磁盘上保存多少数据（例如，有多少索引页和数据页）。
因此，SQL 数据库（例如）在 RAM 超过 4GB 的计算机上可能会更快。
对于其他类型的服务器（例如文件服务器、HTTP 代理等）也是如此，如果它们可以拥有更大的 RAM 缓存，速度会更快。
It's more efficient (quicker) to get data from RAM than to get it from disk.
The speed of SQL server depends partly on how much data (e.g. how many of its index and data pages) it's able to keep in RAM instead of on disk.
So, SQL databases (for example) may be faster on machines with more than 4GB of RAM.
The same is true for other types of server (e.g. file servers, HTTP proxies, etc.), which can be faster if they can have larger RAM caches.
我认为最简单的答案是——摩尔定律。
摩尔定律基本上表明，IC 的成本每 18 个月就会减半。有几种解释方法： PC 中安装的内存量往往每 18 个月就会增加一倍。有效速度加倍（至少如果你采用核心 * MHz 而不仅仅是 MHz）。
无论如何，我们已经用完了 32 位地址空间，因此从 32 位地址空间跳转到 48 位地址空间意味着，在硬件方面，我们已经为摩尔定律的大约 16 次迭代分配了扩展空间 - 相当于大约 20 年。
我非常确定，虽然某些 PC 可能会被推到 10 年大关，但 20 年的扩展空间似乎是一个不错的权衡：20 年后的计算机将会有所不同 - 它们不会使用相同的 CPU 和 RAM 总线，正如20年前他们的不同一样。将 20 多年的余量设计到一个界面中，在工程上是愚蠢的，而且永远不会被使用。
而且它的寿命并没有短到现有硬件面临过早被淘汰的真正风险。
I think the simplest answer is - moore's law.
Moore's law basically says that ICs halve in cost every 18 months. There are some ways of interpreting this: The amount of memory installed in a PC tends to double every 18 months. The effective speed doubles (at least if you take the cores * the MHz rather than just the MHz).
Anyway, weve just really run out of 32bit address space, so a jump from 32 - 48 means that, on the hardware side, we've allocated expansion space for about 16 iterations of Moore's law - which works out to about 20 years.
Im pretty sure that while some PCs might be pushed to the 10 year mark, 20 years of expansion headroom seems a decent tradeoff: Computers in 20 years time are going to be different - they won't be using the same CPUs and RAM busses, just as they were different 20 years ago. Designing more than 20 years worth of headroom into an interface is just silly over engineering that never going to see use anyway.
And its not so short that existing hardware runs a real risk of being obsoleted too soon.
它不再存在了（除了一些老员工的个人机器上），但我在 20 世纪 90 年代末/2000 年代初开发了一套名为 RealiMation 的软件。它是一个用于可视化和模拟的实时 3D 引擎。我们的一位客户经常创建高度详细的模型，达到 2GB 内存限制。我们会在需要时动态加载纹理，并且必须添加代码来检查内存分配失败，以便我们可以继续显示模型，尽管没有纹理。
It doesn't exist any more (except on some old employees personal machines) but I worked on a suite of software called RealiMation back in the late 1990s/early 2000s. It was a real time 3D engine for visualisation and simulation. One of our customers regularly created highly detailed models that hit the 2GB memory limit. We would load textures on the fly as and when needed and had to add code to check for memory allocation failure so we could continue displaying the model, albeit untextured.
从硬件角度来看，另一个考虑因素是对齐。
一旦您需要超过 4 个字节（例如 6 个字节）的数据类型，您需要将它们放在 8 字节边界上，以便在单个指令中检索它们。如果不对齐，则需要进行位掩码和移位，并在（汇编）代码中添加对此的检查。
许多人对切换到 64 位感到恼火，因为他们的程序消耗了更多的内存。他们想要 48 位指针，如果没有对齐限制，CPU 制造商可能会制造 48 位架构。
请注意，如果您非常缺乏内存而希望指针为 6 个字节，则有多种方法可以做到这一点。但执行时间会受到惩罚。
From a hardware prespective, another consideration is alignment.
Once you need a data type of more than 4 bytes, say 6, you need to put them on 8-byte boundries to retrieve them in a single instruction. If you don't align you need to do bit masking and shifting, and add checks for this in the (assembly) code.
Many people were annoyed at the switch to 64-bit that their programs consumed so much more memory. They would have wanted 48-bit pointers, and if the restrictions on alignment weren't there the CPU makers probably would have made a 48-bit architecture.
Note that if you are so starved for memory that you want your pointers to be 6 bytes there are ways to do that. But there is a penalty to execution time.