实现可能遇到的问题：

  1. 引入 Fetch Bubble
  2. MOP Cache 覆盖率问题
  3. 指令融合 Inst Fusion 的影响: 如果指令融合在 decode 阶段实现，需要在 MOP Cache 中保存融合后的指令，否则相比于原有 ICache Path, Mop Cache 由于跳过了 decode 阶段，其带来的 ops 是融合前的，可能会造成更多的后端 ops

硬件实现需要处理的问题

引入 Fetch Bubbles

Fetch Bubble 增多可能有两个原因：

  1. ICache Pipeline 和 MOP Cache Pipeline 切换引入 fetch bubbles
  2. MOP Cache Entry 供指小于 rename width

对于 ICache Pipeline 和 MOP Cache Pipeline 切换，有以下几种情况：

  • 串行 lookup: MOP Cache tag lookup miss 后再查 ICache: 如果 MOP Cache miss 再转向 ICache Pipeline, 相比于直接走 ICache Pipeline, 引入一个 fetch bubble
  • 并行 lookup: MOP Cache tag lookup 同时查 ICache: 如果 MOP Cache hit, ICache 请求无效，占用一次 ICache lookup
    • ICache 功耗增加
    • 如果 ICache 不支持撤销请求且当前 ICache request miss，可能会引入额外的 ICache refill, lower cache requests 等，甚至可能阻塞下一次 Icache request.
  • AMD OC 做法：为 MOP Cache 准备一个 micro-tag array 快速 lookup, 之后再做完整的 tag lookup

如果 MOP Cache Entry 供指小于 Rename Width, 比如 MOP cache entry 中间出现控制流转移指令，会导致当前这一 cycle 控制流指令之后的 ops slots 为空，且 ICache Pipeline 来不及补充这部分 bubble，最终出现 bubble

MOP Cache 覆盖率问题

修改方向:

  • 只对高收益 block build / lookup
    • 用 access-count qualification 过滤低复用 entry，避免 MOP Cache 在不值得的 block 上反复进入 OC path
    • 但只保留高收益 block 理论上只有在 MOP Cache 性能受限于容量时才有效

问题 2 : basic block 的大小和 MOP Cache Slots 的关系 (slots 数量的取舍)

  1. 长 basic block ，跨越多个 mop entry, 一个 MOP entry 存不下
    • basic-block chaining 后的连续短 entry lookup
  2. 短 basic block, 单个 MOP entry slots 不用充分利用 (basic block ops < mop entry slots)
    • 可能不太适用

修改方向:

  • OC hit 后一周期供应更多 entry

    • data 是一 cycle 一个 entry。要发挥 MOP Cache，可以尝试支持每 cycle 读 2 个 entry 或预取 next sequential entry

  • OCQ/OCPipe 做 lookahead

    • 可以在 width-limited continuation 明确时提前 enqueue next PC，让下一个 OC lookup 不完全串行等待

  • 扩大单 entry payload 或改善 entry packing
    当前 imagick ops/lookup 约 4.62，如果 decode/fetch width 更大，单 entry 返回不够宽，就难以覆盖传统 fetch+decode 的吞吐