《深入理解计算机系统》内存store操作及s_addr、s_data、load工作机制疑问

疑问a解答 #

你这里的误解点在于store操作不会立刻写内存，s_data完成只是把数据写入CPU的store buffer（存储缓存），还没真正刷到L1缓存/主存里。

• load要等s_data的情况是条件触发的：只有当本次load的地址和前面未提交的store的地址完全匹配的时候才会触发，这是CPU为了保证内存访问顺序正确性的store-to-load forwarding（存储到加载转发）机制：如果后面的load读的地址刚好是前面刚写的地址，直接从store buffer里拿最新的写结果，不需要等刷到内存，但是前提是前面的store已经把数据写到store buffer的对应条目里了，也就是s_data必须执行完。你现在参考的CSAPP示例就是典型的存储别名场景：如果传入的src和dst指向同一个地址，每次循环的load都会命中前一次的store，就会触发这个等待依赖，性能会差很多；如果地址不同就不会有这个损耗。
• 不是每次s_data执行完都要调用load，这个依赖完全是load端匹配地址后触发的，和s_data本身执行无关，地址不匹配的话两者完全并行执行，互不干扰。

疑问b解答 #

不是的，movq (%rdi), %rax是load指令，只有**store指令（也就是写内存的mov指令）**才会被拆分为s_addr和s_data两个操作，读内存的load指令没有这两个步骤。

• 所有load指令执行前，确实需要先拿自己要读的地址，和store buffer里所有未提交的store条目的地址（也就是前面所有store指令s_addr生成的地址）做匹配检查，这个检查是硬件自动完成的：
  1. 匹配到对应地址：触发刚才说的条件依赖，等对应store的s_data写完，直接从store buffer拿数据
  2. 未匹配到对应地址：直接去缓存/内存读数据，不需要等任何未提交的s_data执行

三者协作逻辑与触发场景 #

store指令执行流程：

1. 解码到写内存的指令时，首先触发s_addr操作：计算要写的内存地址，在store buffer里占用一个空条目，把地址存在这个条目里
2. 等要写的数据就绪后，触发s_data操作：把数据写入store buffer对应条目的数据字段，这条store的逻辑操作就完成了，后续CPU会在空闲的时候把store buffer的条目批量刷到L1缓存/主存
3. 每解码到一条load指令时，先计算自己要读的地址，然后和store buffer里所有已生成地址（也就是s_addr执行完的条目）的地址做比对：
   • 匹配：等待对应条目的s_data执行完成，从store buffer读数据，不需要访问缓存
   • 不匹配：直接发请求到缓存/内存读数据，和未完成的store操作并行执行

内容的提问来源于stack exchange，提问作者Megan Darcy