这是一个相当复杂的问题，因为它需要几个组件来解决。那些组件是：
- 中央处理器
- 内存控制器单元
- BIOS /（U）EFI
- 操作系统
- 应用
最后一项与问题没有直接关系，但为了完整起见，我添加了它。
简而言之，所有上述组件都必须支持超过4 GB的内存才能成功。
中央处理器
让我们从CPU开始。但首先需要注意的是，CPU根本没有使用任何内存的神奇能力。相反，它只能访问其可寻址空间内的任何地址。现在来了一点点的事情。32位CPU能够访问 0到4 GiB范围内的地址。但是，该范围不仅要适应可用的RAM，ROM，SMRAM，图形地址重映射表，还要适应所有必需的内存映射I / O. 还有更多，这可能需要这个地址范围的很大一部分。因此，完全可能的是，某些内存地址被这些用途遮蔽，因此无法用于RAM上的操作。为了重新获得隐藏的内存，有必要扩展CPU 可访问的地址空间。如果是32位CPU 物理地址扩展可能会有所帮助。这允许寻址高达64 GiB。默认情况下，以本机64位模式运行的64位CPU可以访问高达16 EiB，这是相当巨大的，不需要这样的技巧。但另一方面，64位CPU使用64位寻址是不切实际的，因此实际上它们仍然受到地址总线的限制，其范围小于16 EiB。
内存控制器单元
最初它位于北桥，但是由AMD开始使用AMD64处理器和英特尔的Nehalem处理器进入处理器芯片。即使具有PAE的CPU能够自己访问 64 GiB，它仍然需要MCU来访问RAM。简单地说：如果请求的地址驻留在RAM中，则访问特定地址的CPU 将从PCI设备，BIOS ROM闪存或MCU获得回复，依此类推。然而，出于营销原因，MCU（在北桥或CPU中）支持比64 GiB 小得多的可寻址空间并不罕见。
BIOS /（U）EFI
BIOS /（U）EFI也很重要，因为它们有责任在任何实际操作之前配置硬件。除此之外，它们还负责将整个处理器可寻址空间映射到硬件设备，总线，RAM等存储器范围。有趣的是，可能会发生整个RAM分裂并映射到几个可用的非连续点。BIOS的问题在于它的开发人员可能不希望系统内RAM使用超过3 GiB，因此BIOS无法正确映射所有要使用的内存。很可能这不会发生在（U）EFI上。
操作系统
操作系统还应支持寻址4个以上的GiB内存。更具体地说，它应配置CPU以使用PAE。一些32位操作系统完全能够使用PAE并访问超过4 GiB，其他操作系统对最大内存有软件限制，即使它们启用PAE以增强安全性（Windows XP就是一个例子）。64位操作系统自然也没有这样的困难，并且通常支持超过4 GiB的内存。
应用
最后一点来自不同的世界，因为应用程序通常在虚拟地址空间中运行，所以为了完整起见，我添加了它。尽管如此，在编译应用程序时需要一些额外的步骤才能使用更多内存。默认情况下，32位应用程序只能使用2 GiB内存。如果操作系统支持并启用了CPU PAE，那么相同的32位应用程序可以处理多达4 GiB的内存。更具体地说，它可以使用最多3 GiB的内存，另一个GiB可以作为公共库和操作系统内核寻址，但不可写（最终这取决于操作系统架构而不是应用程序本身）。同样，64位应用程序本身支持寻址超过4 GiB的内存，并且首先没有这样的麻烦。
为了全面了解这一点，我们考虑几个例子。
考虑使用英特尔®82945G内存控制器。英特尔网站表示，它不支持PAE，并且仅限于4 GB的RAM。让我们9 System Address Map参考数据表的段落。它有很多信息。最有趣的是Figure 9-3. Main Memory Address Range：
和段落9.2 Main Memory Address Range (1 MB to TOLUD)，内容如下：
该地址范围从1 MB扩展到允许（G）MCH（在TOLUD寄存器中编程）可访问的物理存储器的顶部。对该范围内的地址的所有访问都由（G）MCH转发到主存储器，除非它们落入可选的TSEG，可选的ISA Hole或可选的IGD被盗VGA存储器中。（G）MCH提供4 GB的最大主存储器地址解码空间（82945GC / 82945GZ / 82945PL为2 GB）。（G）MCH不重映射APIC或PCI Express存储空间。这意味着，当系统中填充的物理内存量达到4 GB（82945GC / 82945GZ / 82945PL为2 GB）时，将存在物理内存，但仍然是不可寻址的，因此系统无法使用。
正如它所说，由于它不支持PAE，它最终无法重新映射 PCI和每个其他MMIO 超过 4 GiB，因此一些内存将被遮蔽和未使用。这意味着即使它与支持36位寻址的CPU一起使用，高于4 GiB的内存仍然不可用，并且一些接近4 GiB限制的内存也将被闲置。
相反，让我们考虑与前一个相关的英特尔®82955X内存控制器，但它指定支持8 GB与前一个相反！数据表段落2.1 Host Interface Signals建议，它确实使用36位地址总线到CPU，这是一个好兆头。段落 7 System Address Map有进一步的见解。与Figure 7-1. System Address Ranges我们之前看到的相比：
这清楚地表明它能够利用超过4 GiB的RAM，前提是它与CPU一起使用也能够进行36位寻址。值得注意的是，该段7 System Address Map指出了这一点MCH supports 64 GB of addressable memory space。然而，进一步澄清，最大可用 RAM限制为8 GB。这又一次宣告了可寻址和可用，因为我试图在CPU部分传达。
最后，我想指出两个相关的芯片组在内存处理方面实际上存在巨大差异。
让我们检查英特尔®奔腾®处理器至尊版840。它支持64位指令集，但不支持PAE。这意味着如果在32位模式下运行，它将无法使用超过4 GiB的RAM（如果我对这个假设错了，请纠正我）。让我们检查数据表和表格Table 4-3. Signal Description。即使该CPU具有64位功能，它仍然受到36位宽的地址总线的限制，因此将其限制为从0到64 GiB的可访问地址范围。
现在让我们来检查一个更新的CPU。以英特尔®酷睿™i7-7700处理器为例。它被宣传为支持高达64 GB的RAM。现在让我们查看它的数据表。段落2.3 System Address Map使我们相信，由于39位地址总线，该CPU的可寻址范围从0到512 GiB。请注意，对于64位CPU，它仍远离理论上的16 EiB范围。令人惊讶的是，它进一步澄清了这个CPU确实支持最多32 GiB的可用 RAM最大值（与网站上的64 GB相反）。这里还有一个感兴趣的图像Figure 2-2. System Address Range Example：
它很好地说明了PCI设备等存储器阴影的问题。它也提出了一种通过映射克服这个问题的方法。在CPU 可寻址范围内的实际RAM到高位地址范围的范围。从而回收隐藏的内存以供使用。请注意，此重新映射是在硬件初始化时由BIOS /（U）EFI完成的，正是出于这个原因，我确实在上面的子弹列表中包含了BIOS /（U）EFI。
我以英特尔产品为例，但AMD也是如此。
现在让我们讨论操作系统是如何参与的。Linux内核包括完整的PAE模式支持，从版本2.3.23开始，在32位系统上，Linux内核可以使用超过4 GiB的内存。但是请注意在某些硬件上具有超过4 GiB RAM的系统上32位Linux内核的未确定问题（根据我的经验，它与TLB击落有关）。无论如何，维基百科都有关于PAE支持的很好的信息。有趣的是Windows XP仅限于4 GB，而Windows Server 2003 Enterprise / Datacenter SP2则能够达到64 GB。其他Desktop-Server Windows对也是如此。
如您所见，列出的组件之间存在许多组合，在某些情况下，更换CPU或OS可能会有所帮助。处理BIOS /（U）EFI或MCU要困难得多，因为前者是专有的并且内置于系统中并且不易修改，后者内置于CPU中或焊接在板上。