有几个因素：

• 高性能微架构使用寄存器重命名。也就是说，物理寄存器的数量高于架构上可见的寄存器的数量，并且它们能够跟踪它们的独立使用。

• 寄存器数量加倍不会使性能加倍。假设增加没有不利影响（这是一个非常乐观的假设），从 16 个寄存器增加到 32 个寄存器的ISTR（来自Computer architecture, A Quantitative Approach ）带来了大约 10% 的改进。

• 架构上可见的寄存器是有成本的。例如：

  • 增加它们的数量会增加指令格式中采用的位数以指示正在对哪个寄存器进行操作（将寄存器数量加倍意味着格式中每个寄存器多一个位，从而防止将这些位用于其他用途或强制更长的指令大小）。
  • 增加架构寄存器的数量会增加上下文切换成本（因为它们必须在上下文切换时保存和恢复）。

虽然寄存器和 RAM 都是存储器，但它们以不同的方式访问，以反映访问它们的成本（在芯片面积或隐藏时钟周期中）。

寄存器与 ALU 紧密绑定，可以充当数据源、接收器、修改器等多种角色。因此它们需要大量广泛的多路复用连接。在某些架构中，我们可以写出 R1 <= R2 + R3，而这正是在单个时钟周期内发生的情况。每个寄存器在操作码​​中直接寻址，这种寻址是非常有限的资源。

由于寄存器的实现成本很高，因此在大多数架构中，数量通常限制在 10/20 的数量级。

RAM 松散地绑定到 CPU，通常通过单个共享连接进行引导。这使得实现大量 RAM 的成本大大降低。RAM 地址通常来自寄存器存储的地址，因此不会占用大量指令宽度。

SPARC 是一种有趣的体系结构，具有 72 到 640 个 64 位寄存器，具有 32 个寄存器上下文，可以通过重叠进行移位，以便通过参数传递进行快速子程序调用。您往往不会在成本很重要的 PC 和服务器中找到它们，例如在 99.999% 的应用程序中。

寄存器必须在指令中寻址。如果寄存器很多，则指令较长。如果有很多寄存器，为中断服务保存和恢复寄存器内容需要更多时间。

与大多数情况一样，寄存器的数量是成本、复杂性和实用性之间的折衷。

寄存器被实现为多端口静态 RAM，这使得它们比其他存储选项更昂贵（芯片面积）。

然后将它们与处理器的指令集耦合在一起，增加寄存器的数量会增加指令集的复杂性。所以如果你想保持与指令集的兼容性，你不能仅仅增加下一代处理器中可用的寄存器数量来提高效率，程序不会使用它们。

接下来是您真正需要多少寄存器？它们的用处是有限度的。假设您编写了一个算法，该算法对 1024 个字节执行一些数学运算，比如说乘以 5。使用当前的寄存器计数，您最终会得到如下结果：

load operand1=5
load address
loop: load operand2=byte1@address
multiply Register1 with Register2
store result
increment address
if address = end goto endLoop
jump loop
endLoop:

现在，如果您将有 1024 个寄存器和所有数据存储在那里，您的程序将如下所示：

multiply Register1 with Register2
multiply Register1 with Register3
multiply Register1 with Register4
multiply Register1 with Register5
multiply Register1 with Register6
...

因为它们中的每一个都是不同的指令，所以它们中的每一个都必须写出来。因此，您需要的程序内存正在爆炸式增长。意识到这一点后，您可能需要介绍一些指令，例如，multiply register1 with register(2 to 256). 但是你什么时候停下来，你是否提供了所有组合的说明？

因此，也许我们目前可用的数字是成本、复杂性和实用性之间的良好权衡。