Caching 一个寄存器文件如何足够？

比方说，我正在用汇编语言甚至更高级的语言编写一些代码，并在linux操作系统上编译和运行它

据我所知，当我的程序运行时，它使用CPU 8阵列寄存器文件，而每个阵列的长度为32位。 因此，我的程序运行——并且能够（并且确实）访问这些32位阵列中的每一个

现在我的问题是： 我的计算机，特别是CPU，怎么能负担得起将如此昂贵的资源——它的整个SRAM缓存——投入到一个简单的C/C++程序中，而它肯定有更重要的事情要做，并且在后台运行更广泛、要求更高的进程？

---

我希望我的简单C/C++程序将从RAM中获得一个很好的切片来运行。

如果有两个任务都想使用CPU，而机器中只有一个CPU，那么其中一个将运行，另一个将等待。偶尔会有一个计时器中断出现，导致CPU停止运行当前活动的作业，并跳转到内核的中断处理程序

内核可能决定恢复当前任务，或者给另一个任务一个机会。如果两者都不愿意让CPU（例如等待来自磁盘或网络的数据），那么内核将每秒在它们之间来回切换几次

决定何时切换任务是一个微妙的平衡：允许单个进程长期垄断CPU会使其他进程看起来没有响应，但切换太频繁会降低CPU缓存的效率（切换后，旧进程留下的缓存内容不太可能对新进程有用）

因此，从CPU的角度来看，没有“在后台运行”这样的事情。只有一个正在运行的任务，其他所有的都只是内存中等待使用的数据

---

你认为进程获取CPU的“切片”并不是完全错误的——你只是在错误的维度上进行切片。进程不获取寄存器文件的切片；它们获取整个CPU的时间片。它们被称为时间片。

你需要区分寄存器和缓存（以及现代多任务机器中涉及的所有其他事物）：

在调度程序的一段时间内，寄存器文件确实是专门分配给您的程序的。然而，在上下文切换中完全重新加载它并不是什么大问题——毕竟，您可能会在一个简单的函数调用中重新加载整个寄存器文件（如果您的函数有大量的局部变量）

缓存更复杂。首先，它非常依赖于特定的CPU实现-更简单/更旧的CPU确实可以在上下文开关上刷新缓存，但现代高端CPU不会这样做。如果缓存是“物理映射的”（缓存地址标记对应于物理内存位置，虚拟地址转换发生在缓存访问之前）然后CPU和操作系统都不必对上下文切换做任何特殊的操作。“逻辑映射”缓存（使用虚拟地址标记缓存线的缓存，以减少缓存访问延迟）通常在每一行上都会有额外的“任务标记”。操作系统在上下文切换时会将一些值设置为“任务id”寄存器，缓存硬件将使用这些值来确定哪一行属于当前正在运行的进程或是否应该被替换

---

简单的回答是，操作系统和CPU共同工作，在需要使用这些资源的所有进程之间共享时间。这是他们的工作。他们唯一的工作。CPU芯片上的大部分不动产都是为了使对内存的访问，特别是寄存器文件的访问，对于多个，大部分是独立的进程，尽可能高效nt，任务。