在 MSHR 存在的情况下,Load Store Queue 如何工作?

问题描述

我了解加载存储队列的基本工作原理,即

  1. 当负载计算它们的地址时,它们会检查存储队列中是否有任何先前存储到相同地址的存储,如果有,则它们从最近的存储中获取数据,否则从写入缓冲区或数据缓存中获取数据。
  2. 当商店计算他们的地址时,他们会检查加载队列是否有任何加载违规

我怀疑什么时候会发生

  1. 在第一种情况下,由于存储队列中一些未解析的存储地址而导致加载访问数据缓存,并且在 L1 数据缓存中访问未命中,并且在可以从缓存中检索数据之前,存储地址已解析.现在,商店会检查任何违规情况的加载队列。依赖负载之前已经访问了数据缓存,但由于长时间未命中,还没有从缓存中接收到值。商店是否发布加载违规或是否执行存储到加载转发并从缓存中取消数据?

  2. 当l1数据缓存中的加载访问未命中时,加载被放置在MSHR中,以免阻塞执行阶段。当未命中解决时,该加载的 MSHR 条目具有有关目标寄存器和物理地址的信息。因此该值可以在物理寄存器中更新,但是 MSHR 如何与加载队列通信该值可用?这在流水线阶段什么时候发生? 因为我在某处读到 MSHR 存储物理地址和加载存储队列存储虚拟地址。那么 MSHR 如何与 LSQ 通信?

我没有找到有关这些疑问的任何资源。

解决方法

  1. 这是一种推测执行,其中加载绕过旧存储。当旧存储被解决时,我们可以抛出负载违规。如果地址别名的概率很低,那么推测执行是有利可图的(更高的吞吐量)——通常对于程序来说应该是正确的。在检测到加载违规时,我们可以采取适当的步骤 - (a) 存储到加载转发,或 (b) 回滚到已解决存储的管道。

  2. 与通过缓存命中提供负载时相同(L1 命中可能需要 1-3 个周期)。例如,在具有 CDB(公共数据总线)的保留站中,结果将与所有需要它的硬件结构共享。

相关问答

错误1:Request method ‘DELETE‘ not supported 错误还原:...
错误1:启动docker镜像时报错:Error response from daemon:...
错误1:private field ‘xxx‘ is never assigned 按Alt...
报错如下,通过源不能下载,最后警告pip需升级版本 Requirem...