杰哥的{运维，编程，调板子}小笔记

Nginx 反代导致 SSE 延迟变高的问题与解决方法

Thu, 05 Mar 2026 00:00:00 +0000

Nginx 反代导致 SSE 延迟变高的问题与解决方法¶

背景¶

最近有同学遇到这么一个问题：在 Nginx 反代后面搭了一个使用 SSE（Server Sent Events）机制的服务端，但客户端观察到请求延迟比较高，数据批量到达，而不是一行一行地出现。经过排查，发现是 Nginx 的 buffering 机制导致的。本文通过实验复现该问题，并探索了几种解决方法。

问题复现¶

为了复现这个问题，我 Vibe Coding 了一个测试服务端 server.py，监听 8080 端口，在 /events 路径下每秒发送一条 SSE 消息，共发送 5 次：

#!/usr/bin/env python3 """SSE server that sends 5 messages, one every second."""  import time from http.server import HTTPServer, BaseHTTPRequestHandler   class SSEHandler(BaseHTTPRequestHandler):  def do_GET(self):  if self.path == "/events":  self.send_response(200)  self.send_header("Content-Type", "text/event-stream")  self.end_headers()   for i in range(5):  message = f"data: Message {i + 1} at {time.time()}\n\n"  self.wfile.write(message.encode("utf-8"))  self.wfile.flush()  time.sleep(1)   self.wfile.close()  else:  self.send_response(404)  self.end_headers()   def log_message(self, format, *args):  print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] {format % args}")   if __name__ == "__main__":  server = HTTPServer(("0.0.0.0", 8080), SSEHandler)  print("SSE server starting on http://0.0.0.0:8080")  server.serve_forever()

启动服务端，使用 curl 访问 localhost:8080/events，可以看到每秒输出一条消息，没有延迟。接下来在 docker compose 里启动 Nginx，配置如下：

services:  nginx:  image: nginx:alpine  ports:  - "80:80"  volumes:  - ./nginx.conf:/etc/nginx/nginx.conf:ro  depends_on:  - sse-server  networks:  - sse-network   sse-server:  image: python:3.11-slim  command: python /app/server.py  volumes:  - ./server.py:/app/server.py:ro  ports:  - "8080:8080"  networks:  - sse-network  networks:  sse-network:  driver: bridge

接着是 nginx 的配置：

events {  worker_connections 1024; }  http {  server {  listen 80;   location /events {  proxy_pass http://sse-server:8080;   # Add additional config later here  }  } }

启动 docker compose，用 curl 分别访问 80 和 8080 端口的 /events，观察到以下现象：

通过 80 端口访问 nginx：5 秒后一次性输出所有 data
通过 8080 端口直接访问 server：每秒输出一条 data

这说明确实是 nginx 导致的。接下来测试几种解决方法。

解决方法¶

首先，查阅 nginx 的文档，可以看到它的描述：

Syntax: proxy_buffering on | off; Default: proxy_buffering on; Context: http, server, location  Enables or disables buffering of responses from the proxied server.  When buffering is enabled, nginx receives a response from the proxied server as soon as possible, saving it into the buffers set by the proxy_buffer_size and proxy_buffers directives. If the whole response does not fit into memory, a part of it can be saved to a temporary file on the disk. Writing to temporary files is controlled by the proxy_max_temp_file_size and proxy_temp_file_write_size directives.  When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. The maximum size of the data that nginx can receive from the server at a time is set by the proxy_buffer_size directive.  Buffering can also be enabled or disabled by passing “yes” or “no” in the “X-Accel-Buffering” response header field. This capability can be disabled using the proxy_ignore_headers directive.

根据描述，可以想到一些可能的解决方法：

Nginx 配置添加 proxy_buffering off;：工作
服务端在响应的 header 里添加 X-Accel-Buffering: no（self.send_header("X-Accel-Buffering", "no")）：工作

在一开头的场景里，由于中间的 Nginx 配置改起来比较麻烦，最后就用了第二种方法。回想起来，一开始思路走偏了，一直在往 cache 方向想，实际上是 buffering 的问题：Nginx 会先从 server 读取一大片数据，攒够了再发给 client，避免来回转发小段数据的开销，但 SSE 又希望有较低的延迟，这就冲突了。

小结一下：排查这类问题要理解 Nginx 的工作机制，找错方向可能很难定位；同时，利用 LLM 快速构建可复现的测试环境，有助于验证假设。

记一次软 RAID1 坏盘的恢复过程

Wed, 21 Jan 2026 00:00:00 +0000

记一次软 RAID1 坏盘的恢复过程¶

背景¶

最近遇到一个运维场景，两个 SATA 盘组了一个 RAID1，Linux 的根系统也在上面，启动时能进内核，但是内核一直在报错 link is too slow to respond, please be patient 以及 COMRESET failed (errno=-16)。下面记录一下故障排查以及恢复的过程。

恢复过程¶

考虑到 Linux 系统也在 RAID1 上面，所以找了另一台机器，接上两个 SATA 盘，然后观察到，其中一个盘直接无法识别，另一个盘可以正常访问，但它分区表里只有一个分区，参与到了 md 组的 RAID1 当中。遇到盘坏了又是 RAID，第一反应是买一个新盘，然后重建 RAID。但是一通询价，发现最近硬盘价格涨的比较多，所以先尝试如何单盘启动。由于是 UEFI 启动，推测 ESP 在已经坏的那个盘上面，好的盘上并没有 ESP，但它唯一的分区已经占满了整个空间，所以第一步是对 RAID 分区缩容，这就需要：

首先用 fsck -f /dev/md0 && resize2fs /dev/md0 newsize 对根分区进行缩容
用 mdadm --grow --size=newsize /dev/md0 对 RAID 进行缩容
停止 RAID：mdadm --stop /dev/md0
重新分区，缩小 RAID 分区大小：cfdisk /dev/sda
重新启动 RAID，更新 device size：mdadm --assemble --update=devicesize /dev/md0 /dev/sda1

这些步骤完成以后，就可以在空余的空间里建 ESP 分区了：建分区，mkfs.vfat，挂载到 /mnt/boot/efi（假设 /dev/sda1 已经挂载到了 /mnt），接着 arch-chroot /mnt（或者手抄 Archlinux Wiki），进去 grub-install，修改 /etc/fstab，重新 update-grub。

这个过程中，踩了一些小坑，比如：

重启以后直接进 grub shell，没有菜单显示出来，后来发现是 UEFI 启动项里有之前的旧残留，导致 grub 没有能够正确加载 ESP 里面的 grub.cfg，如果在 grub shell 里手动 source 一下是正常的
如果不更新 device size，那么 assemble 的时候会说 does not have a valid v1.2 superblock 报错，实际上就是它记录了旧的分区大小，和新的分区大小不匹配，此时要强制修改它
最后买了个新盘，但是不够大：960GB vs 1TB，导致如果要重组 RAID1 还得再缩小一次已有的 RAID1 分区，之前缩小的时候只给 ESP 预留了足够的空间，但分区还不够小到能够在新盘里建一个相同大小的分区

IBM POWER9 微架构评测

Sat, 17 Jan 2026 00:00:00 +0000

IBM POWER9 微架构评测¶

背景¶

继 IBM POWER8 之后，也来评测一下后续的 IBM POWER9 微架构。IBM POWER9 有 SMT4 和 SMT8 两种版本，我只有 SMT4 版本的测试环境，下列所有评测都是针对 SMT4 版本进行测试。

官方信息¶

IBM 关于 POWER9 微架构有如下公开信息：

下面分各个模块分别记录官方提供的信息，以及实测的结果。官方信息与实测结果一致的数据会加粗。

Benchmark¶

IBM POWER9 的性能测试结果见 SPEC。

前端¶

L1 ICache¶

官方信息：32KB(SMT4)/64KB(split into 2 regions, SMT8)

为了测试 L1 ICache 容量，构造一个具有巨大指令 footprint 的循环，由大量的 nop 和最后的分支指令组成。观察在不同 footprint 大小下的 IPC：

测试环境是 SMT4 Core，所以只有 32KB 的容量。超出 L1 ICache 容量后，IPC 从 6 降低到了 4.7。相比 POWER8，容量不变，超出 ICache 容量后的 IPC 提高了。

测试过程详见测试代码。

取指带宽¶

官方信息：32 bytes/cycle

为了测试实际的 Fetch 宽度，参考如何测量真正的取指带宽（I-fetch width） - JamesAslan 构造了测试。

其原理是当 Fetch 要跨页的时候，由于两个相邻页可能映射到不同的物理地址，如果要支持单周期跨页取指，需要查询两次 ITLB，或者 ITLB 需要把相邻两个页的映射存在一起。这个场景一般比较少，处理器很少会针对这种特殊情况做优化，但也不是没有。经过测试，把循环放在两个页的边界上，发现 IBM POWER9 微架构遇到跨页的取指时确实会拆成两个周期来进行。

在此基础上，构造一个循环，循环的第一条指令放在第一个页的最后四个字节，其余指令放第二个页上，那么每次循环的取指时间，就是一个周期（读取第一个页内的指令）加上第二个页内指令需要 Fetch 的周期数，多的这一个周期就足以把 Fetch 宽度从后端限制中区分开，实验结果如下：

图中蓝线（cross-page）表示的就是上面所述的第一条指令放一个页，其余指令放第二个页的情况，横坐标是第二个页内的指令数，那么一次循环的指令数等于横坐标 +1。纵坐标是运行很多次循环的总 cycle 数除以循环次数，也就是平均每次循环耗费的周期数。可以看到每 8 条指令会多一个周期，因此 IBM POWER9 的前端取指宽度确实是 8 条指令即 32 字节。

为了确认这个瓶颈是由取指造成的，又构造了一组实验，把循环的所有指令都放到一个页中，这个时候 Fetch 不再成为瓶颈（图中 aligned），两个曲线的对比可以明确地得出上述结论。

随着指令数进一步增加，最终瓶颈在每周期执行的 NOP 指令数，因此两条线重合。

测试过程详见测试代码。

L1 ITLB¶

为了测试 L1 ITLB 的容量，构造 b 序列，每个 b 在一个单独的页（64KB 的页大小）中，观察 b 的性能：

可以看到明显的 256 pages 的拐点，对应了 256 entry 的 L1 ITLB。CPI 从 3 升高到了 28。相比 POWER8 的 64-entry L1 ITLB 容量有所提升。

测试过程详见测试代码。

BTB (aka Branch Target Address Calculator, BTAC)¶

官方信息：1 cycle latency

Return Address Stack¶

构造不同深度的调用链，测试每次调用花费的时间，得到如下测试结果：

可以看到 64 的拐点，对应的就是 RAS 的大小。

测试过程详见测试代码。

CBP (Conditional Branch Predictor)¶

官方信息：BHT(3 cycle redirect) + TAGE(4 components, 5 cycle redirect), 256-bit LGHB(long global history vector)

Dispatch¶

官方信息：6 instructions per SMT4, 12 instructions per SMT8

后端¶

ROB (aka ICT)¶

官方信息：256 entries per SMT4 core

把两个独立的 long latency pointer chasing load 放在循环的头和尾，中间用 NOP 填充，当 NOP 填满了 ROB，第二个 pointer chasing load 无法提前执行，导致性能下降。测试结果如下：

拐点在 256 附近。相比 POWER8 的 28*6=168 有所提升

测试过程详见测试代码。

Issue Queue¶

官方信息：54 instructions per SMT4 core, 108 instructions per SMT8 core

L1 DCache¶

官方信息：32KB(SMT4)/64KB(SMT8, split into two regions)

L1 DTLB¶

用类似测 L1 DCache 的方法测试 L1 DTLB 容量，只不过这次 pointer chasing 链的指针分布在不同的 64KB page 上，使得 DTLB 成为瓶颈：

可以看到 256 Page 出现了明显的拐点，对应的就是 256 的 L1 DTLB 容量。没有超出 L1 DTLB 容量前，Load to use latency 是 4 cycle。L1 DTLB 容量相比 POWER8 的 48(ST)/96(SMT) 有所提升，和 POWER8 的 256-entry L2 DTLB 容量相同。

测试过程详见测试代码。

L2 Cache¶

官方信息：8-way 512KB L2 cache

L3 Cache¶

官方信息：20-way 10MB eDRAM L3 cache per core

Prefetcher¶

参考 Battling the Prefetcher: Exploring Coffee Lake (Part 1) 的方式，研究预取器的行为：分配一片内存，把数据从缓存中 flush 掉，再按照特定的访存模式访问，触发预取器，最后测量访问每个缓存行的时间，从而得到预取器预取了哪些缓存行的信息。

首先是连续访问若干个 128B cacheline，观察哪些被预取了进来：

预取的行为相比 POWER8 更加激进：有更多的缓存行被预取到了更近的 L1（或者是 L2？）。

如果是访问了几个分立的缓存行，有时会表现出 Next 3 Line 的行为，但都是到 L3：

测试过程详见测试代码。

IBM POWER8 微架构评测

Thu, 15 Jan 2026 00:00:00 +0000

IBM POWER8 微架构评测¶

背景¶

之前评测了很多 AMD64 和 ARM64 指令集的处理器，这次也来评测一下 PPC64LE 指令集的 IBM POWER8 微架构。

官方信息¶

IBM 关于 POWER8 微架构有如下公开信息：

IBM POWER8 processor core microarchitecture

下面分各个模块分别记录官方提供的信息，以及实测的结果。官方信息与实测结果一致的数据会加粗。

Benchmark¶

IBM POWER8 的性能测试结果见 SPEC。

前端¶

L1 ICache¶

官方信息：32 KB, 8-way set associative

为了测试 L1 ICache 容量，构造一个具有巨大指令 footprint 的循环，由大量的 nop 和最后的分支指令组成。观察在不同 footprint 大小下的 IPC：

超出 L1 ICache 容量后，IPC 从 6 降低到了 2.4。其中 6 IPC 来自于，IBM POWER8 在 ST 模式下每周期可以发射 8 条指令，但其中分支指令最多两条，非分支指令最多六条，所以执行 NOP 指令的 IPC 只能达到 6。

测试过程详见测试代码。

L1 ITLB (aka Instruction Effective to Real Address translation Table, IERAT)¶

官方信息：64-entry, fully associative

为了测试 L1 ITLB 的容量，构造 b 序列，每个 b 在一个单独的页（64KB 的页大小）中，观察 b 的性能：

可以看到明显的 64 pages 的拐点，对应了 64 entry 的 L1 ITLB。

测试过程详见测试代码。

BTB (Branch Target Buffer)¶

官方信息：无 BTB，总是通过 3 周期延迟的 Fetch + Decode(Branch Scan) 来得到分支指令的目的地址，靠 SMT 来填补流水线的气泡。

实测也是如此，对于连续执行多个 b 指令的情况，每条 b 指令都需要 3 周期。

Return Address Stack (aka Link Stack)¶

官方信息：32-entry(ST/SMT2)/16-entry(SMT4)/8-entry(SMT8) Link Stack per thread，也就是说总容量是 64，但每个线程只能用一部分

构造不同深度的调用链，测试每次调用花费的时间，得到如下测试结果：

可以看到 32 的拐点，对应的就是 ST 模式下 RAS 的大小。在同一个物理核上的其他三个逻辑核分别运行 stress，就测得 SMT4 模式下的 RAS 大小 16：

类似地，在其余七个逻辑核上分别运行 stress 负载，得到 SMT8 模式下的 RAS 大小为 8：

测试过程详见测试代码。

CBP (Conditional Branch Predictor)¶

官方信息：16K-entry LBHT, 16K-entry GBHT, 16K-entry GSEL，使用 21-bit GHV 记录全局分支历史，GSEL 用来选择由 LBHT 还是 GBHT 提供预测（通过 2-bit 饱和计数器），LBHT 采用 PC 索引，GBHT 和 GSEL 采用 PC+GHV 的哈希索引；此外，还支持把 conditional branch to +8 也就是只跳过一条指令的分支指令改写为 predication

IBP (Indirect Branch Predictor)¶

官方信息：256-entry local count cache, 512-entry global count cache，前者采用 PC 索引，后者采用 PC+GHV 的哈希索引，entry 内容是 30-bit 预测的目的地址加 2-bit 的 confidence（local count cache 的 entry 还有额外的 2-bit 饱和计数器用于选择 local 还是 global）

Dispatch¶

官方信息：按 Group 来 Dispatch，ST 模式下每周期一个 Group，每个 Group 最多 8 条指令（最多 2 条分支，最多 6 条非分支，且第二条分支必须是最后一条指令）；SMT 模式下，每周期从两个线程各 Dispatch 一个 Group，每个 Group 最多 4 条指令（最多 1 条分支，3 条非分支）

后端¶

ROB (aka Global Completion Table, GCT)¶

官方信息：28-entry，ST 模式下每个 entry 对应一个 Group；SMT 模式下每个 entry 对应两个来自同一个线程的 Group；所以最多容纳 28*8=224 条指令；Commit 的粒度是 Group，ST 模式下每周期 Commit 一个 Group，SMT 模式下每周期 Commit 两个 Group

拐点大致在 168 附近，因为每 6 条 NOP 指令对应一个 Group，所以只能容纳 28*6=168 条指令。

测试过程详见测试代码。

Register File¶

官方信息：一共可以有 106 个 Inflight 的 Rename，由 GPR（General Purpose Register）和 VSR（Vector and Scalar Register）共享；GPR 分为两组，每组 124-entry；VSR 分为两组，每组 144-entry；还有额外的两组 SAR（Software Architected Registers），一组用于 GPR，一组用于 VSR；CR（Condition Register）单独 Rename（32-entry mapper）到 64-entry Architected Register File；XER（fiXed-point Exception Register）Rename（30-entry mapper）到 32-entry Architected Register File；LR，CTR 和 TAR 单独 Rename（20-entry mapper）到 24-entry Architected Register File；FPSCR（Floating Point Status and Control Register）单独 Rename 到 28-entry buffer。

Issue Queue¶

官方信息：15-entry Branch Issue Queue，8-entry Condition Register Queue，64-entry UniQueue 用于其他指令；每周期最多 Issue 10 条指令：1x Branch, 1x Condition Register Logical, 2x Fixed Point, 2x Load/Store/Fixed Point to LSU, 2x Load/Fixed Point to LU, 2x Vector-Scalar to VSU/DFU(Decimal Floating point Unit)/Crypto

执行单元¶

官方信息：2 个定点计算流水线（FX），2 个 Load/Store 流水线（LS/FX），2 个 Load 流水线（L/FX），4 个双精度浮点流水线（或 8 个单精度浮点流水线），2 个向量流水线（VMX），1 个密码学流水线（Crypto），1 个分支流水线（Branch），1 个条件寄存器流水线（CR），1 个十进制浮点数流水线，共 16 个；其中 2 个 Load/Store 流水线和 2 个 Load 流水线还能执行简单的定点计算

Load Store Unit¶

官方信息：共有四个 Pipeline，L0/L1 仅 Load，LS0/LS1 可 Load/Store, 3 cycle load-to-use latency

Load/Store (Reorder) Queue¶

官方信息：40-entry（128 Virtual）Store Reorder queue，44-entry（128 Virtual）Load Reorder Queue

Load to use latency¶

官方信息：3-cycle latency

实测在下列的场景下可以达到 3 cycle:

ldr 4, 0(4): load 结果转发到基地址，无偏移
ldr 4, 8(4)：load 结果转发到基地址，有立即数偏移
ldx 4, 4, 6：load 结果转发到基地址，有寄存器偏移
ldx 4, 6, 4：load 结果转发到寄存器偏移

如果访存跨越了 128B 边界，则退化到 16 cycle。

L1 DCache¶

官方信息：64KB, 8-way set associative, 128B cache line, 4 read port, 1 write port，3 cycle load to use latency, store-through（写入会同时写 L1 DCache 和 L2），所以 store miss 不分配 cache line, 16 MSHR(aka Load Miss Queue)

构造不同大小 footprint 的 pointer chasing 链，测试不同 footprint 下每条 load 指令耗费的时间：

可以看到 64KB 出现了明显的拐点，对应的就是 64KB 的 L1 DCache 容量。第二个拐点在 512KB，对应的是 L2 Cache 的容量。第三个拐点是 3MB，对应的是 L1 DTLB 的容量：48*64KB=3MB。

测试过程详见测试代码。

Banking¶

官方信息：L1 DCache 由 16 个 macro 组成，每个 macro 是 16 个 bank，一共是 256 个 bank；sram 用的是 2R 或 1W，所以每个 bank 可以支持每周期 2R 或 1W

L1 DTLB (aka primary Data Effective-to-Real Address Translation, DERAT)¶

官方信息：48-entry(ST)/96-entry(SMT), fully associative

用类似测 L1 DCache 的方法测试 L1 DTLB 容量，只不过这次 pointer chasing 链的指针分布在不同的 64KB page 上，使得 DTLB 成为瓶颈：

可以看到 48 Page 出现了明显的拐点，对应的就是 48 的 L1 DTLB 容量。没有超出 L1 DTLB 容量前，Load to use latency 是 3 cycle。最终出现一个 18.8 cycle 的平台。

测试过程详见测试代码。

L2 DTLB (aka secondary Data Effective-to-Real Address Translation, DERAT)¶

官方信息：256-entry（ST 模式下全可见，SMT 模式下每个线程只有一半可见）, fully associative

继续扩大 DTLB 测试规模，可以看到在 256 处出现了新的拐点，其中 256 的地方出现周期数的骤降，是触发了 Linux 的大页合并功能：

关掉 THP(Transparent Huge Page) 后，周期数的骤降消失，256 的拐点之后周期数增加而不是减少：

测试过程详见测试代码。

L3 TLB¶

官方信息：2048-entry, 4-way set associative, 4 concurrent page table walk

继续扩大 DTLB 测试规模，在 2048 处出现了拐点，注意要关闭 THP，否则拐点会消失，因为实际上没有用到 2048 个页：

测试过程详见测试代码。

Prefetcher¶

官方信息：16-entry Stream Prefetcher，可以跨 4KB/64KB 页边界，用虚拟地址预取，可以预取到 L1/L2/L3

首先是连续访问若干个 128B cacheline，观察哪些被预取了进来：

可以看到后面有 12 个 cacheline 都被预取了，但是预取到了不同的 cache 层次，猜测距离越近的 4 个 cacheline 预取到 L1，更远的 2 个到 L2，其余的 6 个到 L3。

如果是访问了几个分立的缓存行，行为变成了 Next 3 Line：

测试过程详见测试代码。

2025 年我是怎么使用 AI 的

Thu, 25 Dec 2025 00:00:00 +0000

2025 年我是怎么使用 AI 的¶

前言¶

经常看我博客的读者应该能看出来，我研究的主要是计算机系统结构方向，特别是处理器的微架构，几乎没有涉及到 AI 的内容，我也确实不喜欢 AI 研究，仅关注但不参与。但今年，因为各种 AI 技术尤其是 LLM 的发展，我确实成为了很多 AI 技术的用户，可以说 2025 年是我正经大规模用 AI 的元年，所以在年末做一个简单的总结。

我不想在这里给大模型厂商打广告，所以相关的名字我都会按照某 PDF 的方法进行打码，有需要的朋友可以自行查看实际的内容。

Vibe Coding¶

首先的一个冲击来自于 Vibe Coding。我写代码也有大概十五年了，一直都是坚持自己写代码，但今年从一些朋友那里了解到一些 Vibe Coding 的效果以后，也自己尝试了一下，确实能够感受到 Vibe Coding 对写代码的巨大冲击，我的心态也出现了一定的变化。Vibe Coding 并不复杂，其实就是用一些 Coding 客户端，配上 LLM 加一些 Tool Call，使得 LLM 可以自己编写、测试和运行代码。目前随着 LLM 能力的变强，Vibe Coding 逐渐成为了一个可以负担得起且效果不错的东西。结合实际的使用，以及受朋友们的一些启发，我目前已经用它进行了一些 Vibe Coding 尝试，例如：

写一些简单的 MCP 服务器，例如 devdocs-mcp-server 把 devdocs.io 的文档通过 MCP 暴露给 LLM，让它可以精确读取标准库的文档，避免幻觉，还有让 LLM 可以读取波形文件的 waveform-mcp；
写一个 API 路由器 llm-api-router，可以在多个 API 提供商之间自动 Fallback，类似于本地版的 OpenRouter，但在这里主要是为了解决 Rate Limit 问题；
对已有代码的一些改进，比如实现 TODO，修复代码 BUG 等等；
给定提示词，让 LLM 用 Typst 或者 SVG 绘图，相比直接 AI 绘图，我更希望是可编辑的矢量图；
给定一张图，让 LLM 用 Typst 或者 SVG 复刻出来，然后再用 Vision LLM 识别绘制出来的图，观察内容是否和输入足够相似；
对于闭源的软件，让 LLM 自动逆向工程，得到一份关于内部实现的代码，甚至让它实现一份开源的等价实现。

目前给我的感觉是，LLM 借助各种 MCP Tooling，在很多事情上可以做的很好，但也有一些前提条件。第一是 LLM 需要有针对这个事情的知识，但如果它的知识停留在几年前，又做一些比较新的东西（例如 Typst 语法很多 LLM 就不会写），它就比较难写对；第二是，一定要给 LLM 反馈的路径，能够让它自产自纠自查，不然幻觉是很难避免的，一次写对的情况很少，有反馈和无反馈完全是两个表现；第三是，目前 LLM 做复杂事情需要大量的 Token，这就意味着 API 调用时间和开销都是不可忽略的因素，即使我用了比较便宜的 DeepSeek 模型，让 LLM 在后台跑几个小时，价格一样受不了。

举一个数据，我这个月在 DeepSeek 上已经花费了 200 多元，而这个月之前的所有时间加起来，也就不过 10 元。如果相同的 Token 数用在 Claude 上，这个价格不可想象。所以我也终于能理解，那些几百美刀一个月的订阅服务为啥有市场了。也是因为这个原因，我才会降本增效，通过订阅 GLM Coding Plan 去解决一些低频的 Vibe Coding 需求，但它的用量限制和并发限制都比较容易触发，所以才去 Vibe Coding 了一个 API 路由器，对于 GLM Coding Plan 用量以外的需求，再 Fallback 到 DeepSeek 上。

在使用 Vibe Coding 的过程中，我也有一些感受，就感觉我并不是在 Vibe Coding，而是在指挥一个水平飘忽不定的人在写代码。它有时候能精准地找到问题并写出正确的代码，有时候又注意力涣散，必须要我及时地打断它，让它按照我指定的方法去做。对于一些简单的代码，可能可以让它在后台跑，我去做一些别的事情，然后隔一段时间再看看它做得怎么样，有问题了，再提供及时的纠正。然后我就在想，这其实就是当领导吧，给钱让手下的人干活，不一定干的对，所以还得时不时地去纠正一下。某种意义来说，LLM 让每个人都有了成为领导，领导一群 LLM 干活的能力。我目前的工作流就是在 tmux 里挂几个 Qwen Code，连上几个配好的 MCP 服务器以及 API 路由器，然后时不时地看看它做的咋样，做得好就验收，让它 Git Commit，做得不好就让它改，时不时还得翻翻代码看看怎么帮它修。某种意义上，这和课后布置作业，给学生答疑也没啥本质上的区别，甚至 LLM 还更爱说话一点。

既然提到了答疑，也来谈谈教学。这种 Vibe Coding 的能力对于计算机教育的冲击无疑是巨大的，本来很多上课教的内容，AI 可以比较容易地完成，那学生可能就更倾向于让 AI 去完成了，换位思考一下，如果让我在 2025 年成为大一不会编程的新生，我也很难抵御这个诱惑。但是，锻炼代码和工程能力就欠缺了。这就对应一个很重要的问题，就是 AI 它到底是不是一种类似编译器、调试器或者编程语言的工具？我们说学生可以从编程语言而不是汇编学起，是因为它是一个很成熟很可靠的工具，你学会了高层次的工具就是会了，就可以用它做很多事情。AI 就很奇怪，它确实可以做很多事情，但又不总是可以完成，它好像是概率性的图灵完全，全看是否出现幻觉，所以它不是一个可靠的工具，但又是一个好用的工具。那么紧接的问题是，计算机教育，是要教出来真的会写代码的人，还是会用 AI 写代码就行？我目前没有答案，也不知道未来会怎么发展，只能慢慢走一步看一步了。但抛开计算机专业的教育，如果是对于计算机的通识教育，我觉得用 AI 写代码完全没有问题，毕竟对于更多人来说，能解决问题就可以，可不可靠，其实很多时候并不在考虑范围内。

我知道上面这段话可能会让读者有一些焦虑，但我觉得，它都这样了，就共存吧，反正焦虑也没有用，不如拥抱它。至于是否担心自己会被替代，我确实是不担心，目前它还不够专业，就算它再专业，它也没有身份证是吧。希望早日实现生产力极大富足，实现共同富裕，那就不用思考人是不是会被 AI 替代了。另外，高级编程语言出现了，那些写汇编的人去写高级语言，现在 Vibe Coding 来了，只是同一拨人又跑去做 Vibe Coding 罢了。持续学习才是最重要的。今年开始尝试 Vibe Coding 也是让我意识到，随着年龄增大，确实是没有当年对新事物接受得那么快了，这也让我有了一些反思，以后还是要多多接触新技术，一些过去的思维可能也要重新审视。

目前我对 Vibe Coding 的态度是，它不能替代我的思考，相反，我可以更多地思考一些更高层次的东西，而可以适当地把一些细节交给 AI。我也持续在自己写代码，特别是一些关键的部分，我还是无法信任完全由 AI 编写，毕竟它比人还懂得偷懒，经常写出来一些没有测试效果的测例，一看测例都过，一测全是 BUG。

我还会继续尝试和 LLM 协作，尽量保持高质量的代码产出，我认为这是用 Vibe Coding 的底线：用 AI 并不是写出烂代码的理由。以前我们有所谓的中文羞耻，觉得写了很多中文的项目的代码可能不靠谱，现在是所谓的 AI 羞耻，看到 README 里一堆 AI 生成的辞藻就觉得不靠谱一样。我们作为业内人士，还是要把事情做得漂亮，而不是让 AI 生成一个勉强能用的组装拖拉机就完事。

写作和语音输入¶

另一方面 AI 影响比较大的，其实是写作，包括日常的各种文字，比较正式的文档、论文甚至教材，不得不承认，AI 在写作方面确实是比我这种语文是考试弱项的偏科生要做得更好。我通常会自己编写一遍，然后交给 DeepSeek 来润色一遍，再在润色的基础上修改，保证我要表达的意思能够完全地被保留下来。一些小的人情世故，比如微信上和各种人打交道的措辞，网络上发送的邮件或者是 GitHub Issue 等等场合的客套话，AI 确实也是做得比自己好。但是，更完整的内容，或者整体架构上的把握，还是不会让 AI 完全去完成，因为能感觉到 AI 训练所使用的语料和自己的思维方式或者写作的习惯还是不一样的，我还是希望我写的东西能更加得有我的思考和劳动在里面，AI 只是一个让文字看起来更加通顺的工具，帮我纠正一些语法错误之类的。例如，我平时可能更习惯一些口语化的表达，能够让我很快地通过打字或者语音输入把我的脑子里的想法变成文字，然后再让 AI 改写成更加严肃的文字，像教材或者论文，这时 AI 就沦为了纯粹的文字风格改写或者语言翻译器。

既然提到了语音输入法，就不得不提，今年我用语音输入的比例大大提升了。其实语音输入法历史已经很久了，但是以前每次体验，都觉得效果不行，每次输入的有错误还得改，自己改正的时间，还不如自己打字来得快。所以一直以来我都是坚持在所有设备上都是 26 键打字用拼音输入的，当然包括手机，经过多年的练习，确实速度还不错，包括我也不喜欢麻烦别人在微信上听语音，所以我尽量都是用文字的。但今年感受下来，确实是不一样，感觉语音输入的准确率有了质的飞跃，能看到它先识别出一个音对字不对的状态，再纠正成正确的表达，还会提示你，这里可能是另一个词，如果你要修改的话，就直接点一下就行。有这个功能以后，我在手机上真的很多时候就直接用语音输入了，尤其是在一些不太正式的场合，对方也能够对那些少数的识别错误脑补的时候，语音输入确确实实替代了手机上打字。在电脑上，还是打字通常更快一些，但最近也尝试了一下智谱 AutoGLM 的输入法，感觉这种语音输入和 LLM 结合还挺有意思的，就是它们家的语音输入准确率还比不上鸿蒙 6 上的小艺输入法，要是二者的优点能够结合在一起就更好了，相信这一天并不遥远。

小结¶

目前想到的就这么多，其实 AI 还有很多场景可以用到，比如生成图片、视频和音乐等等，目前还没有太多的尝试，相信明年开始会逐渐接触，到时候再在年底写一个 AI 使用总结。总的下来，就是感叹自己也到了感慨科技进步的年纪了，十几年前学技术，虽然也能感觉到科技进步，但因为自己是从零开始，学的就是最新的科技，所以没有啥感觉。但这几年，不断地把新的输入和已有的积累进行对比，就能感觉明显到技术潮流和技术栈的移动，也能感觉到自己对新技术的接受度开始有了略微的下降，这值得让我警醒。以前，我们总是嘲笑大人不追求潮流，不去学习手机等新技术，我们在这个时代长大的人，可也不能犯这样的错误呀。

条件分支预测器逆向工程（以 Apple M1 Firestorm 为例）

Tue, 28 Oct 2025 00:00:00 +0000

条件分支预测器逆向工程（以 Apple M1 Firestorm 为例）¶

背景¶

去年我完成了针对 Apple 和 Qualcomm 条件分支预测器（Conditional Branch Predictor）的逆向工程研究，相关论文已发表在 arXiv 上，并公开了源代码。考虑到许多读者对处理器逆向工程感兴趣，但可能因其复杂性而望而却步，本文将以 Apple M1 Firestorm 为例，详细介绍条件分支预测器的逆向工程方法，作为对原论文的补充说明。

背景知识¶

首先介绍一些背景知识。要逆向工程条件分支预测器，需要先了解其工作原理。条件分支预测器的基本思路是：

条件分支的跳转行为（跳转或不跳转）通常是高度可预测的
预测器的输入包括条件分支的地址，以及近期执行的若干条分支的历史记录；输出则是预测该条件分支是否跳转

为了在硬件上实现这一算法，处理器会维护一个预测表，表中每一项包含一个 2 位饱和计数器，用于预测跳转方向。查表时，系统会对条件分支地址以及近期执行的分支历史进行哈希运算，使用哈希结果作为索引读取表项，然后根据计数器的值来预测分支的跳转方向。

（图源：CMU ECE740 Computer Architecture: Branch Prediction）

目前主流处理器普遍采用 TAGE 预测器，它在上述基础查表方法的基础上进行了重要改进：

观察到不同分支的预测所需的历史长度各不相同：有些分支无需历史信息即可准确预测，有些依赖近期分支的跳转结果，而有些则需要更久远的历史信息；
分支历史越长，可能的路径组合就越多，导致预测器训练过程变慢，训练期间的预测错误率较高，因此希望尽快收敛；
为满足不同分支对历史长度的需求，TAGE 设计了多个预测表，每个表使用不同长度的分支历史。多个表同时进行预测，当多个表都提供预测结果时（仅在 tag 匹配时提供预测），选择使用最长历史长度的预测结果。

（图源：Half&Half: Demystifying Intel's Directional Branch Predictors for Fast, Secure Partitioned Execution）

因此，要逆向工程处理器的条件分支预测器，需要完成以下工作：

确定分支历史的记录方式：通常涉及分支地址和目的地址，通过一系列移位和异或操作，将结果存储在寄存器中；
确定 TAGE 算法的具体实现：包括表的数量、每个表的大小、索引方式以及使用的分支历史长度。

分支历史的逆向¶

第一步是逆向工程处理器记录分支历史的方式。传统教科书方法使用一个寄存器，每当遇到条件分支时记录其跳转方向（跳转记为 1，不跳转记为 0），每个分支占用 1 bit。然而，现代处理器（包括 Intel、Apple、Qualcomm、ARM 和部分 AMD）普遍采用 Path History Register 方法。这种方法设计一个长度为 $n$ 的寄存器 $\mathrm{PHR}$，每当遇到跳转分支（包括条件分支和无条件分支）时，将寄存器左移，然后将当前跳转分支的地址和目的地址通过哈希函数映射，将哈希结果异或到移位寄存器中。用数学公式表示为：

$\mathrm{PHR}_{\mathrm{new}} = (\mathrm{PHR}_{\mathrm{old}} \ll \mathrm{shamt}) \oplus \mathrm{footprint}$

其中 $\mathrm{footprint}$ 是通过分支地址和目的地址计算得到的哈希值。接下来的任务是确定 $\mathrm{PHR}$ 的位宽、每次左移的位数，以及 $\mathrm{footprint}$ 的计算方法。

历史长度¶

首先分析这个更新公式：它将最近的 $\lceil n / \mathrm{shamt} \rceil$ 条跳转分支的信息压缩存储在 $n$ 位的 $\mathrm{PHR}$ 寄存器中。随着移位操作的累积，更早的分支历史信息对 $\mathrm{PHR}$ 的贡献最终会变为零。

第一个实验的目标是确定 $\mathrm{PHR}$ 能够记录多少条最近分支的历史。具体方法是构建一个分支历史序列：

第一个条件分支：以 50% 的概率随机跳转或不跳转；
中间插入若干条无条件分支；
最后一个条件分支：跳转方向与第一个条件分支相同。

接下来分析两种情况：

如果在预测最后一个条件分支时，分支历史 $\mathrm{PHR}$ 仍然包含第一个条件分支的信息，预测器应该能够准确预测最后一个条件分支的方向；
如果中间的无条件分支数量足够多，使得第一个条件分支的跳转信息对预测最后一个条件分支时的 $\mathrm{PHR}$ 没有影响，预测器只能以 50% 的概率进行正确预测。

通过构造上述程序，调整中间无条件分支的数量，并使用性能计数器统计分支预测错误率，可以找到一个临界点。当无条件分支数量超过这个阈值时，第二个条件分支的错误预测率会从 0% 上升到 50%。这个临界点对应 $\mathrm{PHR}$ 能够记录的分支历史数量，即 $\lceil n / \mathrm{shamt} \rceil$。

经过测试：

# 第一列：第二步插入的无条件分支数量加一 # 第二列到第四列：分支预测错误概率的 min/avg/max # 第五列：每次循环的周期数 size,min,avg,max,cycles 97,0.00,0.00,0.01,216.87 98,0.00,0.00,0.01,221.02 99,0.00,0.00,0.01,225.18 100,0.00,0.00,0.01,229.17 101,0.45,0.50,0.53,331.97 102,0.47,0.50,0.54,336.27 103,0.46,0.50,0.54,339.85

测试结果表明阈值为 100：在 Apple M1 Firestorm 上，最多可以记录最近 100 条分支的历史信息。

分支预测错误率是怎么测量的？

处理器内置了性能计数器，会记录分支预测错误次数。在 Linux 上，可以用 perf 子系统来读取；在 macOS 上，可以用 kpep 私有 API 来获取。我开源的代码中对这些 API 进行了封装，可以实现跨平台的性能计数器读取。更进一步，我们还逆向了 Qualcomm Oryon 的针对条件分支的预测错误次数的隐藏性能计数器，用于后续的实验。

分支地址 B 的贡献¶

接下来需要推测 $\mathrm{footprint}$ 的计算方法，即分支地址和目的地址如何参与 $\mathrm{PHR}$ 的更新过程。约定分支地址记为 $B$（Branch 的首字母），目的地址记为 $T$（Target 的首字母），用 $B[i]$ 表示分支地址从低到高第 $i$ 位（下标从 0 开始）的值，$T[i]$ 同理。假设 $\mathrm{footprint}$ 的每一位都由若干个 $B[i]$ 和 $T[i]$ 通过异或运算得到。

分支指令本身占用了多个字节，那么分支地址指的是哪一个字节的地址呢？

经过测试，AMD64 架构下，分支地址用的是分支指令最后一个字节的地址，而 ARM64 架构下，分支地址用的是分支指令第一个字节的地址。这大概是因为 AMD64 架构下分支指令是变长的，并且可以跨越页的边界；ARM64 则是定长的，并且不会跨越页的边界。

设计以下程序来推测某个 $B[i]$ 如何参与 $\mathrm{footprint}$ 的计算：

根据上面的分析，Apple M1 Firestorm 最多可以记录最近 100 条分支的历史信息，为了让 $\mathrm{PHR}$ 进入一个稳定的初始值，执行 100 个无条件分支；
设计两条分支指令，第一条是条件分支，按 50% 的概率跳或不跳；第二条是无条件分支；这两条分支的分支地址只在 $B[i]$ 上不同，其余的位都相同，目的地址相同；
执行若干条无条件分支，目的是把 $B[i]$ 对 $\mathrm{PHR}$ 的贡献向前移动；
执行一条条件分支指令，其跳转方向与第二步中条件分支的方向一致。

对应的代码如下：

// step 1. // 100 jumps forward goto jump_0; jump_0: goto jump_1; // ... jump_98: goto jump_99; jump_99:  // step 2. int d = rand(); // the follow two branches differ in B[i] // first conditional branch, 50% taken or not taken if (d % 2 == 0) goto target; // second unconditional branch else goto target; target:  // step 3. // variable number of jumps forward goto varjump_0; varjump_0: goto varjump_1; // ... varjump_k: goto last;  // step 4. // conditional branch last: if (d % 2 == 0) goto end; end:

第二步中条件分支跳转与否，会影响分支历史中 $B[i]$ 一个位的变化，它会经过哈希函数，影响 $\mathrm{footprint}$，进而异或到 $\mathrm{PHR}$ 中。通过调整第三步执行的无条件分支个数，可以把 $B[i]$ 对 $\mathrm{PHR}$ 的影响左移到不同的位置。如果 $B[i]$ 对 $\mathrm{PHR}$ 造成了影响，就可以正确预测最后一条条件分支指令的方向。当左移次数足够多时，$B[i]$ 对 $\mathrm{PHR}$ 的贡献会变为零，此时对最后一条条件分支指令的方向预测只有 50% 的正确率。在 Apple M1 Firestorm 上测试，得到如下结果：

横坐标 Dummy branches 指的是上面第三步插入的无条件分支的个数，纵坐标 Branch toggle bit 代表修改的是具体哪一个 $B[i]$，颜色对应分支预测的错误率，浅色部分对应最后一条分支只能正确预测 50%，深色部分对应最后一条分支总是可以正确预测。

从这个图可以得到什么信息呢？首先观察 $B[2]$ 对应的这一行，可以看到它确实参与到了 $\mathrm{PHR}$ 的计算中，但是仅仅经过 28 次移位，这个贡献就被移出了 $\mathrm{PHR}$，为了保留在 $\mathrm{PHR}$ 内，最多移动 27 次。类似地，在移出 $\mathrm{PHR}$ 之前，$B[3]$ 最多移动 26 次，$B[4]$ 最多移动 25 次，$B[5]$ 最多移动 24 次。

但实际上，这些 $B$ 是同时进入 $\mathrm{PHR}$ 的：这暗示它们对应 $\mathrm{footprint}$ 的不同位置。如果某个 $B[i]$ 出现在 $\mathrm{footprint}$ 更高位的地方，它也会进入 $\mathrm{PHR}$ 更高位，经过更少的移位次数就会被移出 $\mathrm{PHR}$；反之，如果 $B[i]$ 出现在 $\mathrm{footprint}$ 更低位的地方，它能够在 $\mathrm{PHR}$ 中停留更长的时间。

根据上面的实验，可见 $B[5], B[4], B[3], B[2]$ 参与到了 $\mathrm{footprint}$ 计算中，而 $B$ 的其他位则没有。但比较奇怪的是，$\mathrm{PHR}$ 理应可以记录最近 100 条分支的信息，但实际上只观察到了 28。所以一定还有其他的信息。

目的地址 T 的贡献¶

刚刚测试了 $B$，接下来测试 $T$ 各位对 $\mathrm{PHR}$ 的贡献，方法类似：

为了让 $\mathrm{PHR}$ 进入一个稳定的初始值，执行 100 个无条件分支；
设计一个间接分支，根据随机数，随机跳转到两个不同的目的地址，这两个目的地址只在 $T[i]$ 上不同，其余的位都相同，分支地址相同；
执行若干条无条件分支，目的是把 $T[i]$ 对 $\mathrm{PHR}$ 的贡献向前移动；
执行一条条件分支指令，其跳转方向取决于第二步中间接分支所使用的随机数。

对应的代码如下：

// step 1. // 100 jumps forward goto jump_0; jump_0: goto jump_1; // ... jump_98: goto jump_99; jump_99:  // step 2. int d = rand(); // indirect branch // the follow two targets differ in T[i] auto targets[2] = {target0, target1}; goto targets[d % 2]; target0: // add many nops target1:  // step 3. // variable number of jumps forward goto varjump_0; varjump_0: goto varjump_1; // ... varjump_k: goto last;  // step 4. // conditional branch last: if (d % 2 == 0) goto end; end:

在 Apple M1 Firestorm 上测试，得到如下结果：

为了测试 T[31]，岂不是要插入很多个 NOP，一方面二进制很大，其次还要执行很长时间？

是的，所以这里在测试的时候，采用的是类似 JIT 的方法，通过 mmap MAP_FIXED 在内存中特定位置分配并写入代码，避免了用汇编器生成一个巨大的 ELF。同时，为了避免执行大量的 NOP，考虑到前面已经发现 $B[6]$ 或更高的位没有参与到 $\mathrm{PHR}$ 计算中，所以可以添加额外的一组无条件分支来跳过大量的 NOP，它们的目的地址相同，分支地址低位相同，因此对 PHR 不会产生影响。对应的代码如下：

// step 1. // 100 jumps forward goto jump_0; jump_0: goto jump_1; // ... jump_98: goto jump_99; jump_99:  // step 2. int d = rand(); // indirect branch // the follow two targets differ in T[i] auto targets[2] = {target0, target1}; goto targets[d % 2]; target0: // skip over nops, while keeping B[5:2]=0 goto target2; // add many nops target1: goto target2;  target2:  // step 3. // variable number of jumps forward goto varjump_0; varjump_0: goto varjump_1; // ... varjump_k: goto last;  // step 4. // conditional branch last: if (d % 2 == 0) goto end; end:

由此我们终于找到了分支历史最长记录 100 条分支的来源：$T[2]$ 会经过 $\mathrm{footprint}$ 被异或到 $\mathrm{PHR}$ 的最低位，然后每次执行一个跳转分支左移一次，直到移动 100 次才被移出 $\mathrm{PHR}$。类似地，$T[3]$ 只需要 99 次就能移出 $\mathrm{PHR}$，说明 $T[3]$ 被异或到了 $\mathrm{PHR}[1]$。依此类推，可以知道涉及 $T$ 的 $\mathrm{footprint} = T[31:2]$，其中 $T[31:2]$ 代表一个 30 位的数，每一位从高到低分别对应 $T[31], T[30], \cdots, T[2]$。

小结¶

那么问题来了，前面测试 $B$ 的时候，移位次数那么少，明显少于 $T$ 的移位次数。这有两种可能：

硬件上只有一个 $\mathrm{PHR}$ 寄存器，$T[31:2]$ 被异或到 $\mathrm{PHR}$ 的低位，而 $B[5:2]$ 被异或到 $\mathrm{PHR}$ 的中间位置；
硬件上有两个 $\mathrm{PHR}$ 寄存器，其中一个是 100 位，它的 $\mathrm{footprint} = T[31:2]$，记为 $\mathrm{PHRT}$；另一个是 28 位，它的 $\mathrm{footprint} = B[5:2]$，记为 $\mathrm{PHRB}$。

经过后续的测试，基本确认硬件实现的是第二种。用数学公式表达：

$\mathrm{PHRT}_{\mathrm{new}} = (\mathrm{PHRT}_{\mathrm{old}} \ll 1) \oplus \mathrm{T}[31:2]$

$\mathrm{PHRB}_{\mathrm{new}} = (\mathrm{PHRB}_{\mathrm{old}} \ll 1) \oplus \mathrm{B}[5:2]$

有意思的是，在我的论文发表后不久，Apple 公开的专利 Managing table accesses for tagged geometric length (TAGE) load value prediction 中就出现了相关表述，证明了逆向结果的正确性。

按照这个方法，我还逆向工程了 Apple、Qualcomm、ARM 和 Intel 的多代处理器的分支历史记录方法，并进行了公开，供感兴趣的读者阅读，也欢迎读者将测试代码移植到更多处理器上，并贡献逆向工程的结果。

TAGE 表的逆向¶

接下来，我们将目光转向 TAGE 表的逆向工程。TAGE 表与缓存结构类似，也是一个多路组相连的结构，通过 index 访问若干路，然后对每一路进行 tag 匹配，匹配正确的那一路提供预测。TAGE 在预测时，输入是历史寄存器，即上面逆向得到的 $\mathrm{PHRT}$ 和 $\mathrm{PHRB}$，以及分支地址，目前这两个输入都是可控的。为了避免多个表同时提供预测，首先逆向工程使用分支历史最长的表的参数：它的容量是多少，index 如何计算，tag 如何计算，以及几路组相连。

如何确保使用分支历史最长的表提供预测呢？其实还是利用分支历史的特性，将随机数注入到 $PHRT$ 中，例如前面的间接分支，让两个目的地址只在 $T[2]$ 上不同：

// add some unconditional jumps to reset phr to some constant value // 100 jumps forward goto jump_0; jump_0: goto jump_1; // ... jump_98: goto jump_99; jump_99:  // inject int d = rand(); // indirect branch // the follow two targets differ in T[2] auto targets[2] = {target0, target1}; goto targets[d % 2]; target0: // add nop here target1:  // add some unconditional jumps to shift the injected bit left goto varjump_0; varjump_0: goto varjump_1; // ... varjump_k: goto last; last:

根据前面的分析，$T[2]$ 会被异或到 $\mathrm{PHRT}$ 的最低位上，每执行一次无条件分支，就左移一位。因此，通过若干个无条件分支，可以把 d % 2 这个随机数注入到 $\mathrm{PHRT}$ 的任意一位上。之后我们还会很多次地进行这种随机数的注入。

把随机数注入到 $\mathrm{PHRT}$ 高位以后，再预测一个根据随机数跳转或不跳转的分支，就可以保证它只能由使用分支历史最长的表来进行预测。

逆向工程 PC 输入¶

首先，我们希望推断 PC 如何参与到 index 或 tag 计算中。通常，TAGE 只会采用一部分 PC 位参与 index 或 tag 计算。换句话说，如果两个分支在 PC 上不同的部分没有参与 index 或 tag 计算，那么 TAGE 无法区分这两条分支。如果这两个分支跳转方向相反，并且用相同的 PHR 进行预测，那么一定会出现错误的预测。思路如下：

用 100 个无条件分支，保证 PHR 变成一个确定的值；
注入随机数 d % 2 到 PHRT，并移动到高位（例如 $PHRT[99]$），使用前面所述的方法；
执行两个条件分支，它们在分支地址上只有一位 $PC[i]$ 不同，它们的跳转条件相反，当第一个条件分支不跳转的时候，会执行第二个条件分支，它总是会跳转。

对应代码类似于：

// step 1. inject phrt int d = rand(); inject_phrt(d % 2, 99);  // step 2. a pair of conditional branches with different direction // their PC differs in one bit if (d % 2 == 0) goto end; if (d % 2 == 1) goto end;  end:

经过测试，PC 的输入是 $PC[18:2]$，其余的没有。

逆向工程相连度和 index 函数的 PC 输入¶

接下来是比较复杂的一步，同时逆向工程表的相连度和 index 函数的 PC 输入。这是因为这两部分是紧密耦合的：只有知道相连度，才能知道预测出来的分支数对应几个 set；但不知道 index 函数，又无法控制分支被分配到几个 set 中。首先，为了避免 PHR 的干扰，还是只注入一个随机数到 $PHRT[99]$ 上（事实上，$PHRT[99]$ 不是随便选择的，而是需要在 index 函数中，但通过测试可以找到满足要求的位）。其次，构造一系列分支，它们的地址满足：第 i 条分支（i 从 0 开始）的分支地址是 $i2^k$，其中 $k$ 是接下来要遍历的参数。当 $k=3$ 时，分支会被放到 0x0, 0x8, 0x10, 0x18, 0x20 等地址，涉及的 PC 位数随着分支数的增加而增加。接下来，我们分类讨论：

假如涉及的 PC 位都在 tag 中，没有出现在 index 中：那么这些分支都会被映射到同一个 set 内，一旦分支数量超出相连度，就会出现预测错误。
假如涉及的 PC 位有一部分出现在 index 中：那么每有一个 PC 位出现在 index 中，这些分支可以被分配到的 set 数量就翻倍，直到这些 set 都满了以后，才会出现预测错误。
假如涉及的 PC 位有一部分超出 PC 输入的范围（如前面逆向工程得到的 $PC[18:2]$）：那么超出输入的部分地址会被忽略，使得 set 内出现冲突。

实验结果如下图：

纵坐标就是上面的 $k$，横坐标是测试的条件分支数，颜色表示预测的错误率。当颜色从深色变浅，就说明出现了预测错误。观察：

$PC[3]$ 的情况下，只能预测 4 个分支，而 $PC[4]$ 或 $PC[5]$ 可以预测 8 个分支，暗示了四路组相连，然后 $PC[4]$ 和 $PC[5]$ 对应到了两个 set，所以能够正确预测 8 个分支。
$PC[6]$ 的情况下，可以预测 16 个分支，对应 4 个 set；后续 $PC[7]$ 和 $PC[8]$ 又可以预测 8 个分支，对应 2 个 set；意味着 $PC[6]$ 在 index 中，给 $PC[4]$ 和 $PC[5]$ 提供了两倍的 set；$PC[9]$ 在 index 中，给 $PC[6]$、$PC[7]$ 和 $PC[8]$ 提供了两倍的 set。
后续更高的 PC 位，没有受到 index 函数的影响，因此都是 4，直到最后超出 PC 输入范围。

这就说明它是四路组相连，PC[6] 和 PC[9] 参与到了 index 函数中。

下面给读者一个小练习，下面是在 Qualcomm Oryon 上测得的结果，可以看到噪声比较大，你能推断出它是几路组相连，有哪些 PC 参与到了 index 计算吗？

揭晓答案

四路组相连，$PC[6]$ 和 $PC[7]$ 参与到了 index 函数。

那么，这种测试是怎么构造的呢？即需要用相同的 PHR 去预测 $PC=i2^k$ 的多条分支。思路比较复杂：

首先执行一条间接分支，目的地址是 $i2^{k-1}$，那么它对 PHRT 的贡献是 $\mathrm{PHRT}_1 = (\mathrm{PHRT}_0 \ll 1) \oplus (i2^{k-3})$；
接下来，在 $i2^{k-1}$ 的位置，再执行一条直接分支，目的地址是 $i2^k$，那么它对 PHRT 的贡献是 $\mathrm{PHRT}_2 = (\mathrm{PHRT}_1 \ll 1) \oplus (i2^{k-2}) = (((\mathrm{PHRT}_0 \ll 1) \oplus (i2^{k-3})) \ll 1) \oplus (i2^{k-2}) = \mathrm{PHRT}_0 \ll 2$。

可见经过两步以后，PHRT 是保持不变的。针对 PHRB，只要 $i2^{k-1}$ 没有涉及 $PC[5:2]$，就能保证相同。那么如果 $k$ 足够小，也有办法：

首先执行一条间接分支，目的地址是 $i2^{k-1}$；
接下来执行大量的 NOP，使得 $B$ 的低位等于 0，然后再执行一条间接分支，目的地址是 $i2^k$。

因此我们总是可以通过两次分支，实现用相同的 PHR 预测不同 PC 上的多条分支。

逆向工程 tag 函数¶

接下来，进行 tag 函数的逆向工程。为了逆向工程 tag 函数，我们希望找到两个位在 tag 函数中有异或关系，那么如果这两个位同时设为 0，或者同时设为 1，其异或结果都等于 0，使得计算出来的 tag 函数相同，如果此时 index 还相同，那么预测器就无法区分这两种情况。

为了利用这一点，生成两个 0 到 1 的随机数 $k$ 和 $l$，分别把它们注入到 PC、PHRB 或者 PHRT 中，去预测一个条件分支，其跳转与否取决于 $k$ 的值（论文中有个小 typo）。如果 $k$ 和 $l$ 在 tag 函数中有异或关系，那么预测器总会预测错误。

实验结果大致如下，横纵坐标表示注入哪一个位，颜色代表预测错误率，深色意味着预测错误，也就是找到了一组异或关系：

其中有一些异或关系，因为对应的位在 index 中出现的缘故，导致没有显现出来。根据已知的异或关系外推，可以得到如下的 tag 计算公式：

PC[7] xor PHRT[0,12,...,96] xor PHRB[8,21]
PC[8] xor PHRT[1,13,...,97] xor PHRB[9,22]
PC[9] xor PHRT[2,14,...,98] xor PHRB[10,23,24]
PC[10] xor PHRT[3,15,...,87,99] xor PHRB[11,12,25]
PC[11] xor PHRT[4,16,...,88] xor PHRB[0,13,26]
PC[12] xor PHRT[5,17,...,89] xor PHRB[1,14,27]
PC[13] xor PHRT[6,18,...,90] xor PHRB[2,15]
PC[14] xor PHRT[7,19,...,91] xor PHRB[3,16]
PC[15] xor PHRT[8,20,...,92] xor PHRB[4,17]
PC[16] xor PHRT[9,21,...,93] xor PHRB[5,18]
PC[17] xor PHRT[10,22,...,94] xor PHRB[6,19]
PC[18] xor PHRT[11,23,...,95] xor PHRB[7,20]
PC[2:5]: 单独出现，不和其他位异或

那么，这里是怎么实现针对 PC、PHRT 和 PHRB 的注入的呢？针对 PHRT 的注入前面已经提到过，只需要一个间接分支：

// target differs in T[2] auto targets[2] = {target0, target1}; goto targets[d % 2]; target0: // add nop target1:

PHRB 的注入就比较复杂了，例如要注入 $B[2]=k$，我们需要进行三次分支的跳转：

第一次跳转，$B$ 相同，$T[2]=k$；
第二次跳转，$B[2]=k$，$T[3]=k$；
第三次跳转，$B[2]=B[3]=k$, $T$ 相同。

经过计算，可以发现前两次跳转对 PHRT 的抵消，第二次跳转的 $B[2]$ 与第三次跳转的 $B[3]$ 抵消，最后相当于只有最后一次跳转的 $B[2]=k$ 对 PHRB 产生了贡献。

最复杂的是 PC 的注入，这次需要分情况讨论：

第一种情况是，要注入的 PC 位比较高，具体来说，是 $PC[7]$ 或者更高的位数，此时我们可以很容易地避免引入对 PHRB 的贡献，因为它只考虑 $B[5:2]$：

第一次跳转，$B$ 相同，$T[6]=k$；
第二次跳转，$B[6]=k$ 但对 PHRB 没有贡献，$T[7]=k$。

那么两次跳转完以后，PHRB 不变，PHRT 的贡献被抵消掉，同时实现了 $PC[7]=k$ 的注入。

第二种情况是，要注入的正好是 $PC[6]$，继续用上面的方法会发现 PHRB 无法抵消，这时候，需要引入第三次跳转：

第一次跳转，$B$ 相同，$T[3]=k$；
第二次跳转，$B[3]=k$，$T[5]=T[4]=k$；
第三次跳转，$B[4]=k$，$T[6]=k$。

验算可以发现，PHRB 和 PHRT 的贡献全都被抵消，成功注入 $PC[6]=k$。

最后来看要注入的 PC 更低的情况，例如要注入 $PC[3]=k$，还是用三次跳转：

第一次跳转，$B$ 相同，$T[2]=k$；
第二次跳转，$B[2]=k$，$T[2]=T[3]=k$；
第三次跳转，$B[3]=k$，$T[3]=k$。

这样就成功注入 $PC[3]=k$。

那么 PC 的注入就完成了，只有 $PC[2]$ 没有找到合适的方法来注入。

逆向工程 index 函数¶

相连度和 tag 函数已知，接下来，让我们逆向工程最后的 index 函数。逆向工程的思路如下：

通过前面的逆向工程，发现 $PC[5:2]$ 是独立出现在 tag 函数中，并且没有出现在 index 中，所以我们可以构造出多个分支，它们的 tag 不同；
进一步，构造两组条件分支，每组都有四个条件分支，因为是四路组相连，如果这两组分别映射到两个 set 中，就可以正确预测；反之，如果被映射到同一个 set 中，就会预测错误；
和之前类似，向 PC、PHRB 或 PHRT 注入两个随机数 $k$ 和 $l$，然后预测两组共八个条件分支，这些条件分支的跳转方向都是 k xor l；
如果 $k$ 和 $l$ 注入的位同时出现在 index 函数中，但是没有异或关系，那么这八个条件分支可以正确地被预测；
如果 $k$ 和 $l$ 注入的位同时出现在 index 函数中，并且有异或关系，那么这八个条件分支会被映射到同一个 set 内，最多只能正确预测其中四个分支；
如果 $k$ 和 $l$ 注入的位至少出现一个在 tag 函数中，那么一个分支会在同一个 set 内占用两项，导致最多只能正确预测其中两个分支。

注入 $PC[9]$ 和 $PHRT[i]$ 的实验结果如下：

结合上面的讨论，可以知道：

PC[9] 和 PHRT[38] 和 PHRT[88] 有异或关系
PHRT[2]、PHRT[12]、PHRT[17]、PHRT[22]、PHRT[27]、PHRT[33]、PHRT[43]、PHRT[53]、PHRT[58]、PHRT[63]、PHRT[68]、PHRT[73]、PHRT[78]、PHRT[83]、PHRT[93] 在 index 中，但是和 PC[9] 没有异或关系

实际上还有 PHRT[7] 和 PHRT[48] 也在 index 中，但实际上测试的时候为了保证历史最长的表提供预测，还额外注入了 PHRT[99]，它与 PHRT[7] 和 PHRT[48] 有异或关系，所以在上图没有显现出来。

用类似的方法，去测试 PHRT 与 PHRT、PHRT 与 PHRB、PHRB 与 PHRB 之间的异或关系，就可以找到最终的 index 函数：

PHRT[2] xor PHRT[43] xor PHRT[93]
PHRT[7] xor PHRT[48] xor PHRT[99]
PHRT[12] xor PHRT[63] xor PHRB[5]
PHRT[17] xor PHRT[68] xor PHRB[10]
PHRT[22] xor PHRT[73] xor PHRB[15]
PHRT[27] xor PHRT[78] xor PHRB[20]
PHRT[33] xor PHRT[83] xor PHRB[25]
PHRT[38] xor PHRT[88] xor PC[9]
PHRT[53] xor PHRT[58] xor PHRB[0]
PC[6]

至此使用分支历史最长的表的逆向就完成了。接下来讨论一下，如何逆向工程分支历史更短的表。

逆向工程使用分支历史更短的 TAGE 表¶

前面提到，TAGE 在预测时，会选取提供预测的多个表中使用历史最长的那个表。那么，如果要测试使用历史第二长的表，应该怎么办呢？我们尝试了以下方法：

在使用历史更长的表里，预先插入一些表项，再去测试历史较短的表的情况，由于 TAGE 会利用它的 useful 计数器来进行新表项的分配，当历史更长的表里的表项的 useful 不为零，可以防止它被覆盖成新的内容，逼迫 TAGE 用历史更短的表来进行预测；
把多个表当成一个整体来考虑，比如在测试能够正常预测的分支数量的时候，得到的是多个表叠加的结果，再减去已知数量，可以得到历史比较短的表的信息；
在超出要测试的表的历史部分，注入大量随机数，例如要测试的一个表，只用到了历史的低 57 位，那就在更高的部分注入大量的随机数，那么历史最长的表能够提供预测的概率会非常小，从而逼迫 TAGE 用当前被测试的表来做预测。

通过这些方法，我们成功地逆向出了 Firestorm 的剩下的 TAGE 表的信息：

有兴趣的读者可以试着自己复现一下，看看能不能得到对应的实验结果，然后从结果中分析出硬件的参数。有意思的是，我们逆向出来 Qualcomm Oryon 的分支预测器的大小（6 个表一共 80KB 的空间），与官方在 Hot Chips 上公开的是一致的。

总结¶

我们通过一系列方法，实现了对 Apple M1 Firestorm 的条件分支预测器的逆向，并且成功地把它应用到了设计基本一样的 Qualcomm Oryon 处理器上，为后续的研究提供了基础。

引用文献¶

本博客近三个月来的访问数据观察

Thu, 09 Oct 2025 00:00:00 +0000

本博客近三个月来的访问数据观察¶

写在前面¶

这个博客自 2014 年更新至今，已走过近十一个年头，累计发布了四百多篇文章。出于好奇，我一直想了解哪些内容更受读者欢迎。五年前，我曾配置过 Google Analytics，但使用体验并不理想，于是转而自行部署了 rybbit 实例来收集访问数据。如今三个月过去，是时候与大家分享一些有趣的发现。

P.S. 如果你对数据收集有所顾虑，可以屏蔽对应的 analytics 脚本。

数据总览与趋势¶

首先来看这三个月内的整体访问情况与趋势：

访问量比我的预期要高一些。虽然这些年写了不少内容，但并没有刻意宣传，主要依赖搜索引擎推荐和读者的订阅与转发。从时间趋势上可以看出两个明显特点：

工作日访问量显著高于周末，通常为周末的两到三倍；
开学后工作日的访问量比暑假期间又高出一倍，但周末依然低迷。

由此推测，学生读者占比较高。结合国庆假期访问量的下降来看，国内读者仍是主力。下面是各国家与地区的访问分布：

值得一提的是，也有不少海外读者访问，看来近年来有意识地撰写英文内容确实产生了效果。

以 UTC+8 时区为基准，从访问时间分布中可以看出大家的作息习惯：

尽管大家可能习惯熬夜，但深夜阅读博客的并不多，多数访问集中在工作时间。

接下来是基于 User Agent 的统计。首先是浏览器分布：

不出所料，Chrome 及基于 Chromium 内核的浏览器占据主流，Firefox 和 Safari 占比不高。我本人目前也在使用 Firefox，希望它能持续发展，避免 Chrome 一家独大。

操作系统分布如下：

Windows 占比最高，macOS 次之。考虑到博客内容主要涉及计算机技术，这也大致反映了相关从业人员的偏好。

以下是访问次数较多的几篇文章：

这个排名有些出乎我的意料。这几篇文章在撰写时并未特别考虑入门读者的理解难度或内容的丰富性。或许是因为它们涉及的领域资料较少，因此在相关关键词搜索中容易被找到。这一点在 Google Search Console 中也得到了印证：

相比之下，一些精心准备的文章阅读量并不高，可能是因为所在领域已有较多优质内容，新文章难以脱颖而出。这也说明文章质量与阅读量之间并非简单的正比关系。

我还注意到一些重度用户，他们不仅阅读多篇文章，且停留时间较长：

未知用户一：阅读了分支预测、乱序执行、CPU 微架构分析等文章，推测可能是刚开始研究 CPU 微架构的同行；
未知用户二：浏览了 wishbone、乱序执行相关内容，猜测是学习清华计算机组成原理课程的学生；
未知用户三：从华为相关文章进入，随后浏览了其他内容，可能是搜索华为内容进入博客后，被其他文章吸引的读者；
未知用户四：阅读了 ARM/Samsung/Intel 等处理器微架构分析文章，又一位同行，但有一定基础，更加关注业界。

类似的例子还有不少，在此不一一列举。尽管 CPU 相关文章的阅读量不及软件类内容，但能得到这么多同行的关注，确实令人欣慰——毕竟这本身就是一个小众领域，不能奢求过高的阅读量。

通过这次数据分析，我收获了不少有趣的观察。未来可能会不定期更新类似内容，看看随着时间推移，是否会有新的发现。

最后，如果你对访问数据的收集感到不适，可以直接屏蔽 analytics 脚本（或许你的浏览器插件已经这样做了）。根据 rybbit 的官方说明，其信息收集方法较为尊重用户隐私，我也没有对代码进行任何修改，不放心的读者可以阅读 rybbit 的源码来审计。

P.S. 你能看出这篇文章是，我先写了一遍，然后让大模型润色的结果吗？

ARM 公版核微架构演进

Wed, 10 Sep 2025 00:00:00 +0000

ARM 公版核微架构演进¶

背景¶

ARM 公版核微架构的演进频繁，型号又比较多，相关信息散落在各种地方，为了方便查阅，在这里做一个收集。

2025 年¶

C1-Ultra¶

Arm の新しい CPU「C1」は 2 桁パーセントの性能アップ。電力効率も大幅改善
Inside Arm's New C1‑Ultra CPU: Double‑Digit IPC Gains Again!
- C1-Ultra: successor to Cortex X925
- Branch prediction: Additional tracking for local/per-PC history
- 33% increase in L1 I-Cache available bandwidth
- Out of order window size growth: Up to 25% growth, Up to ~2K instruction in flight
- 2x L1 data cache capacity (128KB)
- Data prefetchers: array-indexing coverage
Arm® C1-Ultra Core Technical Reference Manual
- Implementation of the Scalable Vector Extension (SVE) with a 128-bit vector length and Scalable Vector Extension 2 (SVE2)
- Implementation of the Scalable Matrix Extension (SME) and Scalable Matrix Extension 2 (SME2), and support for the C1-SME2 unit
- configure the L2 cache to be 2048KB or 3072KB
- A 64KB, 4-way set associative L1 instruction cache with 64-byte cache lines
- A fully associative L1 instruction Translation Lookaside Buﬀer (TLB) with native support for 4KB, 16KB, 64KB, and 2MB page sizes
- A 128KB, 4-way set associative cache with 64-byte cache lines
- A fully associative L1 data TLB with native support for 4KB, 16KB, and 64KB page sizes and 2MB and 512MB block sizes
- L2 cache is private to the core and can be configured to be 2MB 8-way set associative or 3MB 12-way set associative
- L1 instruction TLB, Fully associative, 128 entries
- L1 data TLB, Fully associative, 96 entries
- L1 Statistical Profiling Extension (SPE) TLB, Located in the SPE block, VA to PA translations of any page and block size, 1 entry
- L1 TRace Buﬀer Extension (TRBE) TLB, VA to PA translations of any page and block size, 1 entry
- L2 TLB, Shared by instructions and data, 8-way set associative, 2048 entries
- L1 instruction cache, 64KB, 4-way set associative, Virtually Indexed, Physically Tagged (VIPT) behaving as Physically Indexed, Physically Tagged (PIPT), Pseudo-Least Recently Used (LRU) cache replacement policy for L1, 32 bytes per cycle interface with L2
- L1 data cache, 128KB, 4-way set associative, Virtually Indexed, Physically Tagged (VIPT) behaving as Physically Indexed, Physically Tagged (PIPT), Re-Reference Interval Prediction (RRIP) replacement policy, 4×64-bit read paths and 4×64-bit write paths for the integer execute pipeline, 4×128-bit read paths and 4×128-bit write paths for the vector execute pipeline
- L2 cache, 2MB 8-way set associative with 4 banks or 3MB 12-way set associative with 4 banks, Physically Indexed, Physically Tagged (PIPT), Dynamic biased cache replacement policy, One CHI Issue E compliant interfaces with 256-bit read and write DAT channel widths

C1-Pro¶

Arm Lumex C1-Pro CPU Core: What You Need to Know
- C1-Pro: successor to Cortex-A725
- Larger direction predictor and branch history
- 2x capacity 0-cycle BTB
- 16x capacity 1-cycle BTB
- 50% more L1 Instruction TLB capacity
- Increase effective L1D cache bandwidth
- Lower latency L2 TLB hit
- New indirect prefetcher

2024 年¶

Cortex X925¶

Arm Unveils 2024 CPU Core Designs, Cortex X925, A725 and A520: Arm v9.2 Redefined For 3nm Archive
- Decode & Dispatch: 10-wide
- SIMD/FP execution: 6x 128b
- Integer ALU pipelines: 1- and 2-cycle operations
- Integer multiply execution: 4x versus Cortex-X4
- FP compare execution: 2x versus Cortex-X4
- >2x increase in SIMD/FP issue queues
- 2x increase in max instruction-window capacity（注：Cortex X4 是 384x2，推测 Cortex X925 是 768x2）
- Sign-extension instruction elimination
- Branch prediction: 2x instruction window size
- Instruction Fetch: 2x increase in L1 I$ available bandwidth, 2x increase in L1 iTLB size, Fold out unconditional direct branches
- 3 -> 4 load pipelines
- 2x increase in L1 D$ available bandwidth
- 25-40% in back-end OoO growth
Arm® Cortex-X925 Core Technical Reference Manual
- Implementation of the Scalable Vector Extension (SVE) with a 128-bit vector length and Scalable Vector Extension 2 (SVE2)
- configure the L2 cache to be 2048KB or 3072KB
- A 64KB, 4-way set associative L1 instruction cache with 64-byte cache lines
- A fully associative L1 instruction Translation Lookaside Buﬀer (TLB) with native support for 4KB, 16KB, 64KB, and 2MB page sizes
- A 64KB, 4-way set associative cache with 64-byte cache lines
- A fully associative L1 data TLB with native support for 4KB, 16KB and 64KB page sizes and 2MB and 512MB block sizes
- L2 cache is private to the core and can be configured to be 2MB 8-way set associative or 3MB 12-way set associative
- L1 instruction TLB, Caches entries at the 4KB, 16KB, 64KB, or 2MB granularity of Virtual Address (VA) to Physical Address (PA) mapping only, Fully associative, 128 entries
- L1 data TLB, Caches entries at the 4KB, 16KB, 64KB, 2MB, or 512MB granularity of VA to PA mappings only, Fully associative, 96 entries
- L2 TLB, Shared by instructions and data, VA to PA mappings for 4KB, 16KB, 64KB, 2MB, 32MB, 512MB, and 1GB block sizes, Intermediate Physical Address (IPA) to PA mappings for: 2MB and 1GB block sizes in a 4KB translation granule, 32MB block size in a 16KB translation granule, 512MB block size in a 64KB granule; Intermediate PAs (descriptor PAs) obtained during a translation table walk, 8-way set associative, 2048 entries
- L1 instruction cache, 64KB, 4-way set associative, Virtually Indexed, Physically Tagged (VIPT) behaving as Physically Indexed, Physically Tagged (PIPT)
- The Cortex®-X925 core supports the AArch64 prefetch memory instructions, PRFM PLI, into the L1 instruction cache or L2 cache
- L1 data cache, 64KB, 4-way set associative, Virtually Indexed, Physically Tagged (VIPT) behaving as Physically Indexed, Physically Tagged (PIPT), Re-Reference Interval Prediction (RRIP) replacement policy, 4×64-bit read paths and 4×64-bit write paths for the integer execute pipeline, 4×128-bit read paths and 4×128-bit write paths for the vector execute pipeline
- L2 cache, 2MB 8-way set associative with 4 banks or 3MB 12-way set associative with 4 banks, Physically Indexed, Physically Tagged (PIPT)
Arm® Cortex-X925 Core Software Optimization Guide

2023 年¶

Cortex X4¶

Arm Unveils 2023 Mobile CPU Core Designs: Cortex-X4, A720, and A520 - the Armv9.2 Family Archive
- Support for larger L2 (2M)
- Dispatch width: 10 instrs vs Cortex-X3 (6 instrs I$, 8 instrs Mop$)
- Overall pipeline depth (branch mispredict penalty): 10 cycles vs Cortex-X3 (11 cycles I$, 9 cycles Mop$)
- ALUs: 8 vs 6 (Cortex-X3)
- Branch units: 3 vs 2 (Cortex-X3)
- Integer MAC: 2 vs 1 (Cortex-X3)
- Pipelined FP divider / sqrt: Y vs N (Cortex-X3)
- MCA capacity: 320x2 -> 384x2
- 4th LS address generation: LS LS LD -> LS LD LD ST
- New L1 temporal data prefetcher
- Reduced L1 data bank conflicts
- Larger L1 data TLB: 48 -> 96
Arm® Cortex-X4 Core Technical Reference Manual

Cortex A720¶

Arm Unveils 2023 Mobile CPU Core Designs: Cortex-X4, A720, and A520 - the Armv9.2 Family Archive
- 11-cycle mispredict penalty, vs 12 (Cortex-A715)
- Improved 2-taken branch prediction
- Pipelined FDIV/FSQRT unit
- Faster transfers from Floating-Point/NEON/SVE2 to Integer
- Earlier deallocation of mops from Load-Store Issue Queues
- Lower latency for L2 cache hits, 9-cycle latency to access L2, vs 10 (Cortex-A715)
- Up to 2x memset(0) bandwidth in L2
- New L2 spatial-prefetch engine

2022 年¶

Cortex X3¶

Arm Unveils Next-Gen Flagship Core: Cortex-X3
- 50% larger L1 + L2 (new) BTB capacity
- 10x larger L0 BTB capacity
- New predictor dedicated for indirect branches
- Double return-stack capacity (32 entries)
- Mop cache 50% capacity (1.5K entries)
- Removed 1 pipeline stage in Mop Cache fetch, 10->9 cycles for a branch mispredict
- Increase decode bandwidth: 5->6
- Integer ALUs increase 4->6: 2->4 single-cycle (SX), 2 single-/multi-cycle (MX)
- ROB/MCQ: 288x2 -> 320x2
- Integer load bandwdith: 24B -> 32B
- Additional data prefetch engines: Spatial, Pointer/Indirect
Arm® Cortex‑X3 Core Technical Reference Manual

Neoverse V2¶

Arm Neoverse V2 platform: Leadership Performance and Power Efficiency for Next-Generation Cloud Computing, ML and HPC Workloads
- 6-wide/8-wide front-end
- 64KB ICache
- 320+ OoO window
- 8-wide dispatch
- 8-wide retire
- 2 LS + 1 LD / cycle
- 64KB DCache
- 6-ALU + 2-branch
- Quad 128-bit low latency SIMD datapath
- L2 10-cycle load-to-use, 128B/cycle, private L2 cache 1 or 2 MB
- Two predicted branches per cycle
- Predictor acts as ICache prefetcher
- 64kB, 4-way set-associative L1 instruction cache
- Two-level Branch Target Buffer
- 8 table TAGE direction predictor with staged output
- 10x larger nanoBTB
- Split main BTB into two levels with 50% more entries
- TAGE: 2x larger tables with 2-way associativity, Longer history
- Indirect branches: Dedicated predictor
- Fetch bandwidth: Doubled instruction TLB and cache BW
- Fetch Queue: Doubled from 16 to 32 entries
- Fill Buffer: Increased size from 12 to 16 entries
- Decode bandwidth: Increased decoder lanes from 5 to 6, Increased Decode Queue from 16 to 24 entries
- Rename checkpoints: Increased from 5 to 6 total checkpoints, Increased from 3 to 5 vector checkpoints
- Late read of physical register file – no data in IQs
- Result caches with lazy writeback
- Added two more single-cycle ALUs
- Larger Issue Queues, SX/MX: Increased from 20 to 22 entries, VX: Increased from 20 to 28 entries
- Predicate operations: Doubled predicate bandwidth
- Zero latency MOV; Subset of register-register and immediate move operations execute with zero latency
- Instruction fusion: More fusion cases, including CMP + CSEL/CSET
- Two load/store pipes + one load pipe
- 4 x 8B result busses (integer)
- 3 x 16B result busses (FP, SVE, Neon)
- ST to LD forwarding at L1 hit latency
- RST and MB to reduce tag and data accesses
- Fully-associative L1 DTLB with multiple page sizes
- 64kB 4-way set associative Dcache
- TLB Increased from 40 to 48 entries
- Replacement policy Changed from PLRU to dynamic RRIP
- Larger Queues: Store Buffer, ReadAfterRead, ReadAfterWrite
- Efficiency: VA hash based store to load forwarding
- Multiple prefetching engines training on L1 and L2 accesses: Spatial Memory Streaming, Best Offset, Stride, Correlated Miss Cache, Page
- New PF engines: Global SMS – larger offsets than SMS, Sampling Indirect Prefetch – pointer dereference, TableWalk – Page Table Entrie
- Private unified Level 2 cache, 8-way SA, 4 independent banks
- 64B read or write per 2 cycles per bank = 128B/cycle total
- 96-entry Transaction Queue
- Inclusive with L1 caches for efficient data and instruction coherency
- AMBA CHI interface with 256b DAT channels
- Capacity 2MB/8-way with latency of 1MB (10-cycle ld-to-use)
- Replacement policy 6-state RRIP (up from 4)
Hot Chips 2023: Arm’s Neoverse V2
Arm® Neoverse™ V2 Core Technical Reference Manual
Arm Neoverse V2 Software Optimization Guide

2021 年¶

Cortex X2¶

2020 年¶

Neoverse N2¶

Arm Neoverse N2: Arm’s 2nd generation high performance infrastructure CPUs and system IPs
- Branch Prediction, 2x 8 instrs (up to 2 taken per cycle), 2x improvement
- Nano BTB (0 cyc taken-branch bubble), 64 entry, 4x improvement
- Conditional branch direction state, 1.5x improvement
- Main BTB, 8K entry, 1.33x improvement
- Alt-Path Branch Prediction
- 64KB Instruction cache
- 1.5K entry Mop Cache
- 16-entry Fetch Queue, 1.33x improvement
- Fetch Width: 4 instr from i$, 5 instr from MOP$, Up to 1.5x improvement
- Early branch redirect: uncond + cond
- Decode width: 4 (I-cache) or 5 (Mop cache), Up to 1.25x improvement
- Branch predict up to 16-inst/cycle, 2-taken/cycle
- New Macro-op (MOP) cache with 1.5k entries
- 50% larger branch direction predicton
- 33% larger BTB with shorter average latency
- Early re-steering for conditional branches that miss the BTB
- Rename width: 5 instrs, 1.2x improvement
- Rename Checkpointing: Yes
- ROB size: 160+, 1.25x improvement
- ALUs: 4, 1.33x improvement
- Branch resolution: 2 per cycle, 2x improvement
- Overall Pipeline Depth: 10 cycles, 1.1x improvement
- 64KB L1 Data cache
- Private 512KB/1MB L2 Cache
- AGU: 2-LD/ST + 1 LD, 1.5x improvement
- L1 LD Hit bandwidth: 3x 16B/cycle, 1.5x improvement
- Store data B/W: 32B/cycle, 2x improvement
- L2 bandwidth: 64B read + 64B write, 2x improvement
- L2 transactions: 64, 1.3x improvement
- Data Prefetch Engines: Stride, spatial/region, stream, temporal
- Correlated Miss Caching (CMC) prefetching

Neoverse V1¶

SW defined cars: HPC, from the cloud to the dashboard for an amazing driver experience
- Faster run-ahead for prefetching into the I$ (2x32B bandwidth)
- 33% larger BTBs (8K entry)
- 6x nano BTB (96 entry), zero-cycle bubble
- 2x number of concurrent code regions tracked in front-end
- Introduction of Mop Cache, L0 decoded instruction cache (3K entry)
- high dispatch bandwidth, 8-instrs per cycle, 2x increase, I$ decode bandwidth increased from 4x to 5x
- Lower latency decode pipeline by 1 stage
- OoO window size, 2x+ ROB (256 entry + compression)
- Increase superscalar integer execution bandwidth, 1->2 Branch Execution, 3->4 ALU
- 2x vector/fp bandwidth, 2x256b – SVE (new), 4x128b – Neon/FP
- 3rd LD AGU/pipe (50% incr), LS LS LD
- LD/ST data bandwidth, LD: 2x16B -> 3x16B, LD (SVE): 2x32B, ST: 16B -> 32B (2x), broken out into separate issue pipes
- Number of outstanding external memory transactions (48->96)
- MMU capacity 1.2K->2K entry (67% incr)
- L2 latency reduced by 1 cycle for 1M (now 10cyc load to use)
- 11+ stage accordion pipeline
- 8-wide front-end / 15-wide issue
- Four 64-bit integer ALUs + two dedicated Branch units
- 2x 256-bit SVE datapaths
- 4x 128-bit Neon/FP datapaths
- 3x load / store addr
- 3x load data & 2x store data pipeline
- 8-wide Instruction fetch
- 5-8 wide decode / rename
- pipeline: P1 P2 F1 F2 DE1 RR RD I0 I1 I2 ...

Cortex X1¶

Arm's New Cortex-A78 and Cortex-X1 Microarchitectures: An Efficiency and Performance Divergence Archive
- 50% larger L0-BTB capacity, 96 entries, zero-cycle bubble taken-branch latency
- Increased fetch bandwidth available, 5 instruction fetch from the instruction cache, 8 Mop fetch from the Mop cache
- 2x Mop cache capacity over Cortex-A77, 3K entries
- 33% increase in dispatch bandwidth, up to 8-instr/cycle
- 40% increase in out-of-order window size, 224 entry instruction window
- 2x FP/ASIMD execution bandwidth, 4x128b total bandwidth
- Doubling available L1-D, L2 bandwidth
- Doubleing of maximum L2 capacity
- Up to 33% increase in window growth for in-flight loads and stores
- 66% larger L2-TLB capacity, 2K entries
Arm Cortex-X1: The First From The Cortex-X Custom Program
Arm® Cortex®‑X1 Core Technical Reference Manual

Cortex A78¶

Arm's New Cortex-A78 and Cortex-X1 Microarchitectures: An Efficiency and Performance Divergence Archive
- Expand prediction support to 2 taken branches per cycles
- Additional IMUL bandwidth, up to 2x per cycle
- 50% increase in load bandwidth over Cortex-A77, additional load AGU / result
- Double store-data bandwidth, 32B per cycle
- Double L2 interface bandwidth

2019 年¶

Neoverse N1¶

The Arm Neoverse N1 Platform: Building Blocks for the Next-Gen Cloud-to-Edge Infrastructure SoC
- 4-wide front-end
- dispatching/committing up to 8 instructions per cycle
- three ALUs, a branch execution unit, two Advanced SIMD units, and two load/store execution units
- minimum misprediction penalty is 11-cycle
- fetch up to 4 instructions per cycle
- large 6K-entry main branch target buffer with 3-cycle access latency
- 64-entry micro-BTB and a 16-entry nano-BTB
- 12-entry fetch queue
- fully associative 48-entry instruction TLB
- 4-way set-associative 64KB I-cache
- I-cache can deliver up to 16B of instructions per cycle
- up to 8 outstanding I-cache refill requests
- 4-wide decoder
- renaming unit can receive up to 4 macro-ops per cycle
- up to 8 micro-operations can be dispatched into the out-of-order engine each cycle
- The commit queue can track up to 128 micro operations
- up to 8 micro-ops can be committed per cycle
- a distributed issue queue with more than 100 micro-operations
- 4 integer execution pipelines, 2 load/store pipelines, and 2 Advanced SIMD pipelines
- 64kB 4-way set associative L1 data cache, 4-cycle load to use latency and a bandwidth of 32 bytes/cycle
- The core-private 8-way set associative L2 cache is up to 1MB in size and has a load-to-use latency of 11 cycles
- can also be configured with smaller L2 cache sizes of 256kB and 512kB with a load-to-use latency of 9 cycles
- L2 cache connects to the system via an AMBA 5 CHI interface with 16-byte data channels
- L3 cluster cache can be up to 2MB, with a load-to-use latency ranging between 28 and 33 cycles
- up to 256MB of shared system-level cache

AMD Zen 3 的 BTB 结构分析

Tue, 08 Jul 2025 00:00:01 +0000

AMD Zen 3 的 BTB 结构分析¶

背景¶

在之前，我们分析了 AMD Zen 1 和 AMD Zen 2 的 BTB，接下来分析它的再下一代微架构：2020 年发布的 AMD Zen 3 的 BTB，看看 AMD 的 Zen 系列的 BTB 是如何演进的。

官方信息¶

AMD 在 Software Optimization Guide for AMD EPYC™ 7003 Processors (Publication No. 56665) 中有如下的表述：

The branch target buffer (BTB) is a two-level structure accessed using the fetch address of the previous fetch block.

Zen 3 的 BTB 有两级，相比 Zen 1 和 Zen 2 少了一级。BTB 是用之前 fetch block 的地址去查询，而不再是当前 fetch block 的地址。用当前 fetch block 的地址查询 BTB 很好理解，要寻找某个地址开始的第一个分支，就用这个地址去查询 BTB，Zen 1 和 Zen 2 都是如此；用之前 fetch block 的地址，则是用更早的信息，去获取当前 fetch block 的信息，例如：

entrypoint1:  jmp entrypoint2  entrypoint2:  # what's the first branch after entrypoint2?

在查询从 entrypoint2 开始的第一条分支指令的时候，如果使用当前 fetch block，就是用 entrypoint2 的地址去查询，那就必须等到前面 jmp entrypoint2 指令的目的地址被计算得出；如果使用之前 fetch block，就是用 entrypoint1 的地址去查询，不用等到 jmp entrypoint2 指令的目的地址被计算得出。因此，如果用之前 fetch block，可以更早地进行 BTB 的访问，从而减少 BTB 的延迟，或者在相同延迟下获得更大的容量。但是，代价是：

从 entrypoint1 跳转到的 fetch block 可能有多个，例如最后一条是间接分支指令，那就需要找到正确的分支的信息
可能会从不同的地址跳转到 entrypoint2 这个 fetch block，因此它的信息可能会保存多份

Each BTB entry can hold up to two branches if the last bytes of the branches reside in the same 64-byte aligned cache line and the first branch is a conditional branch.

Zen 3 的 BTB entry 有一定的压缩能力，一个 entry 最多保存两条分支，前提是两条分支在同一个 64B 缓存行中，并且第一条分支是条件分支。这样，如果第二条分支是无条件分支，分支预测的时候，可以根据第一条分支的方向预测的结果，决定要用哪条分支的目的地址作为下一个 fetch block 的地址。虽然有压缩能力，但是没有提到单个周期预测两条分支，所以只是扩大了等效 BTB 容量。和 Zen 1、Zen 2 一样。

L1BTB has 1024 entries and predicts with zero bubbles for conditional and unconditional direct branches, and one cycle for calls, returns and indirect branches.

Zen 3 的第一级 BTB 可以保存 1024 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；针对条件和无条件直接分支的预测不产生气泡，意味着它的延迟是一个周期。相比 Zen 2 容量翻倍，且延迟降低一个周期，猜测和使用 previous fetch block 有关。

L2BTB has 6656 entries and creates three bubbles if its prediction differs from L1BTB.

Zen 3 的第二级 BTB 可以保存 6656 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；预测会产生三个气泡，意味着它的延迟是四个周期。

简单整理一下官方信息，大概有两级 BTB：

1024-entry L1 BTB, 1 cycle latency
6656-entry L2 BTB, 4 cycle latency

相比 Zen 1 和 Zen 2 有比较大的不同：去掉了原来很小的 L0 BTB，扩大了 L1 BTB，同时延迟缩短了一个周期；虽然 L2 BTB 有所缩小，但是延迟也变短了一个周期。

下面结合微架构测试，进一步研究它的内部结构。

微架构测试¶

在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。

考虑到 Zen 3 的 BTB 可能出现一个 entry 保存两条分支的情况，并且还对分支的类型有要求，因此下面的测试都会进行四组，分别对应四种分支模式：

uncond：所有分支都是无条件分支：uncond, uncond, uncond, uncond, ...
cond：所有分支都是条件分支：cond, cond, cond, cond, ...
mix (uncond + cond)：条件分支和无条件分支轮流出现，但 uncond 在先：uncond, cond, uncond, cond, ...
mix (cond + uncond)：条件分支和无条件分支轮流出现，但 cond 在先：cond, uncond, cond, uncond, ...

虽然 Zen 3 使用 previous fetch block 来访问 BTB，但在这几种分支模式中，使用 previous fetch block 还是访问 current fetch block，结果都是唯一的，所以并不会对结果带来影响。

stride=4B¶

首先是 stride=4B 的情况：

可以看到，图像上出现了三个比较显著的拐点：

第一个拐点是 4 条分支，CPI=1，对应 L1 BTB，没有达到完整容量，可能是因为分支太过密集
第二个拐点是 2048 条分支，CPI=3.6；第三个拐点是 4096 条分支，CPI=4/4.2/4.4

Zen 3 在 stride=4B 的情况下 L1 BTB 表现比较一般，应该是牺牲了高密度分支下的性能；而主要命中的是 L2 BTB，在不同的分支模式下，测出来差不多的结果。为了验证这一点，统计了如下的性能计数器（来源：Processor Programming Reference (PPR) for AMD Family 19h Model 21h, Revision B0 Processors）：

PMCx08B [L2 Branch Prediction Overrides Existing Prediction (speculative)] (Core::X86::Pmc::Core::BpL2BTBCorrect)

它代表了 L2 BTB 提供预测（准确地说，L2 BTB 提供了预测且和 L1 BTB 提供的预测结果不同，覆盖了 L1 BTB 的预测结果）的次数，当分支数不大于 4 的时候，这个计数器的值约等于零；此后快速上升，说明后续都是 L2 BTB 在提供预测。

更进一步观察，发现 2048 到 4096 的 CPI 上升，来自于 L1 BTB 完全失效：2048 条分支时，L1 BTB 还能提供约 10% 的预测，所以 CPI=0.1*1+0.9*4=3.7，但到 4096 条分支的时候，完全由 L2 BTB 提供分支，此时 CPI=4。

超过 4096 以后，则 L2 BTB 也开始缺失，出现了译码时才能发现的分支，如果这是一条 uncond 分支，那么会在译码时回滚，这一点可以通过如下性能计数器的提升来证明（来源：Processor Programming Reference (PPR) for AMD Family 19h Model 21h, Revision B0 Processors）：

PMCx091 [Decode Redirects] (Core::X86::Pmc::Core::BpDeReDirect): The number of times the instruction decoder overrides the predicted target.

但在 L2 BTB 缺失后，如果译码器发现了 cond 分支，会把它预测为不跳转，所以要等到执行才能发现分支预测错误。这就导致了 cond 模式下 L2 BTB 溢出时 CPI=16，而 uncond 模式下 L2 BTB 溢出时 CPI=12，提前在译码阶段发现了 uncond 分支并纠正。

但译码器的纠正能力不是万能的：假如它首先发现了一条 cond 分支，在它其后又发现了一条 uncond 分支，它会用 uncond 分支去纠正，但实际上前面的 cond 分支会跳转，所以此时译码器纠正也无法提升性能，即使 BpDeReDirect 计数器的值看起来很大。

stride=8B¶

接下来观察 stride=8B 的情况：

第一个台阶在所有分支模式下都是 1024 个分支，CPI=1，对应 1024-entry 的 L1 BTB
第二个台阶不太明显，但是在 4096 附近在所有分支模式下都是一个拐点，CPI=4，对应 L2 BTB；在 mix (uncond + cond) 模式下，超过 4096 分支后 CPI 缓慢上升，到 6144 条分支 CPI=4.25，到 6656 条分支 CPI=4.85，之后 CPI 快速上升；在 mix (cond + uncond) 模式下，到 5888 条分支 CPI=5。

L2 BTB 的容量不太确定，超过 4096 后需要一个 entry 保存两条分支才能获得更多容量，但也带来了一定的额外的延迟。与此同时 4096 也对应了 32KB ICache 的容量，这会对分析带来干扰。

从 BpDeReDirect 计数器来看，uncond 分支模式下，当分支数量超过 4096 后，L2 BTB 从 4096 时无缺失，之后缺失快速提升，说明此时 L2 BTB 容量确实是 4096。在 mix (cond + uncond) 模式下，分支数超过 4096 时，BpDeReDirect 计数器略微上升，直到 6144 条分支后才有明显的上升。

stride=16B¶

继续观察 stride=16B 的情况：

相比 stride=8B，L1 BTB 的行为没有变化。4096 对应的 CPI 有所下降，从 BpL2BTBCorrect 性能计数器可以发现是 L1 BTB 起了一定的作用。在 mix (cond + uncond) 模式下，直到 5632 条分支还维持了 CPI=3.25，之后 CPI 缓慢上升，到 6656 条分支时 CPI=3.75，到 6912 条分支时 CPI=4。

CPI=3.25 可能是来自于 1 和 4 的加权平均：25% 的时候是 1 周期，75% 的时候是 4 周期，平均下来就是 1*0.25+4*0.75=3.25。这意味着 L1 BTB 还要保持 25% 的命中率。观察 BpL2BTBCorrect 性能计数器，发现它的取值等于 75% 的分支执行次数，意味着 L1 BTB 确实提供了 25% 的预测，L2 BTB 提供了剩下 75% 的预测。这一点是挺有意思的，意味着 L1 BTB 可能采用了一些对这种循环访问模式友好的替换策略：朴素的 LRU（或类 LRU）替换策略会导致 L1 BTB 出现 100% 缺失。

stride=32B¶

继续观察 stride=32B 的情况：

相比 stride=16B，L1 BTB 的行为没有变化，但是出现了一些性能波动。所有分支模式下，L2 BTB 的拐点都出现在 5120，但性能波动比较大，mix (cond + uncond) 模式下的 CPI 达到了 4.6。通过 BpDeReDirect 性能计数器的变化，可以确认这个拐点确实是来自于 L2 BTB 的缺失。

前面提到，译码器的纠正能力可能会给出错误的答案，在 stride=32B 时，就会出现一个很有意思的现象：

超出 L2 BTB 容量后，mix (uncond + cond) 模式下 BpDeReDirect 占分支数量的 50%
超出 L2 BTB 容量后，mix (cond + uncond) 模式下 BpDeReDirect 占分支数量的接近 100%

解释起来也并不复杂：stride=32B 的情况下，一个 64B cacheline 只有两条分支，那么：

mix (uncond + cond) 模式下，第一条分支是 uncond，译码器会发现并 redirect；第二条分支是 cond，译码器会无视它，不进行 redirect；所以最后是 50% 的 redirect 比例
mix (cond + uncond) 模式下，第一条分支是 cond，译码器会看到后面的 uncond 分支并 redirect；第二条分支是 uncond，译码器会发现并 redirect；所以最后是接近 100% 的 redirect 比例

顺带一提，uncond 模式下的 BpDeReDirect 占分支数量的接近 100%，cond 模式下的 BpDeReDirect 占分支数量的 0%，都是符合预期的。

stride=64B¶

继续观察 stride=64B 的情况：

相比 stride=32B，L1 BTB 的容量减半，达到了 512。之后出现了比较明显的性能波动，但四种分支模式下，拐点依然都是出现在 5120 条分支的位置。通过 BpDeReDirect 性能计数器的变化，可以确认这个拐点确实是来自于 L2 BTB 的缺失。由于 uncond 模式下，BTB sharing 不会工作，意味着 L2 BTB 至少有 5120 个 entry。

stride=128B¶

继续观察 stride=128B 的情况：

相比 stride=64B，L1 BTB 的容量进一步减小，达到了 256；L2 BTB 的性能依然波动剧烈，但四种分支模式下，拐点依然都是出现在 5120 条分支的位置。

考虑到 5120 这个拐点频繁出现，认为 L2 BTB 在不考虑 BTB entry sharing 的情况下，实际容量应该是 5120。那么剩下的 1536 个分支就是来自于压缩。

小结¶

测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：

L1 BTB 是 1024-entry，1 cycle latency，容量随着 stride 变化，大概率是 PC[n:5] 这一段被用于 index，使得 stride=64B 开始容量不断减半
L2 BTB 是 5120-entry，4 cycle latency；其中有 1536 个 entry 最多保存两条分支，前提是这两条分支在同一个 cacheline 当中，并且第一条是 cond，第二条是 uncond

Zen 1 到 Zen 3 的 BTB 的对比¶

下面是对比表格：

uArch	AMD Zen 1	AMD Zen 2	AMD Zen 3
L0 BTB size	4+4 branches	8+8 branches	N/A
L0 BTB latency	1 cycle	1 cycle	N/A
L1 BTB size	256 branches	512 branches	1024 branches
L1 BTB latency	2 cycles	2 cycles	1 cycle
L2 BTB size w/o sharing	2K branches	4K branches	5K branches
L2 BTB size w/ sharing	4K branches	7K branches	6.5K branches
L2 BTB latency	5 cycles	5 cycles	4 cycles
Technology Node	14nm	7nm	7nm
Release Year	2017	2019	2020

Zen 3 在 Zen 2 的基础上，没有更换制程，而是通过 previous fetch block 的方式，减少 L1 BTB 的延迟到 1 cycle，顺带去掉了 L0 BTB。L2 BTB 的大小进行了调整，减少了共享的部分，而增加了不限制分支类型的 BTB entry 数量，同时减少了一个周期的延迟，不确定这个延迟是单纯通过优化容量实现的，还是说也依赖了 previous fetch block 的方法来减少周期，更倾向于是后者，因为 L1 和 L2 BTB 都减少了一个周期的延迟。

如果按照 Intel 的 tick-tock 说法，那么 Zen 2 相比 Zen 1 是一次 tick，更换制程，微架构上做少量改动；Zen 3 相比 Zen 2 是一次 tock，不更换制程，但是在微架构上做较多改动。Zen 4 是 2022 年发布的，使用的是 5nm 制程；Zen 5 是 2024 年发布的，使用的是 4nm 制程。总结一下规律，AMD 会花费两年的时间来升级制程，并且实际上，Zen 4 和 Zen 5 不仅更新了制程，还在前端微架构上有较大的改动。

AMD Zen 3 和 ARM Neoverse V1 的 BTB 的对比¶

AMD Zen 3 和 ARM Neoverse V1 都是在 2020 发布的处理器，下面对它们进行一个对比：

uArch	AMD Zen 3	ARM Neoverse V1
L1/Nano BTB size	1024 branches	48*2 branches
L1/Nano BTB latency	1 cycle	1 cycle
L1/Nano BTB throughput	1 branch	1-2 branches
L2/Main BTB size w/o sharing	5K branches	4K*2 branches
L2/Main BTB size w/ sharing	6.5K branches	4K*2 branches
L2/Main BTB latency	4 cycles	2 cycles
L2/Main BTB throughput	1 branch	1-2 branches
Technology Node	7nm	5nm

虽然 AMD Zen 3 通过 previous fetch block 优化，实现了 1 cycle 下更大的 L1 BTB，但这一点在 2022 年发布的 ARM Neoverse V2 上被追赶：ARM Neoverse V2 的 L1/Nano BTB 也做到了 1024 的容量。

在 L2 BTB 方面，ARM Neoverse V1 占据了领先，无论是延迟还是容量；当然了，ARM Neoverse V1 的制程也要更加领先，ARM 采用的 5nm 对比 AMD 采用的 7nm。

更进一步，ARM Neoverse V1 实现了一个周期预测两条分支，即 two taken（ARM 的说法是 two predicted branches per cycle），在 2 cycle 的 Main BTB 上可以实现接近 AMD Zen 3 的 L1 BTB 的预测吞吐。AMD 也不甘示弱，在 2022 年发布的 AMD Zen 4 处理器上，实现了 two taken。

AMD Zen 2 的 BTB 结构分析

Tue, 08 Jul 2025 00:00:00 +0000

AMD Zen 2 的 BTB 结构分析¶

背景¶

在之前，我们分析了 AMD Zen 1 的 BTB，接下来分析它的下一代微架构：2019 年发布的 AMD Zen 2 的 BTB，看看 AMD 的 Zen 系列的 BTB 是如何演进的。

官方信息¶

AMD 在 Software Optimization Guide for AMD EPYC™ 7002 Processors (Publication No. 56305) 中有如下的表述：

The branch target buffer (BTB) is a three-level structure accessed using the fetch address of the current fetch block.

Zen 2 的 BTB 有三级，是用当前 fetch block 的地址去查询，和 Zen 1 一样。

Each BTB entry includes information for branches and their targets. Each BTB entry can hold up to two branches if the branches reside in the same 64-byte aligned cache line and the first branch is a conditional branch.

Zen 2 的 BTB entry 有一定的压缩能力，一个 entry 最多保存两条分支，前提是两条分支在同一个 64B 缓存行中，并且第一条分支是条件分支。这样，如果第二条分支是无条件分支，分支预测的时候，可以根据第一条分支的方向预测的结果，决定要用哪条分支的目的地址作为下一个 fetch block 的地址。虽然有压缩能力，但是没有提到单个周期预测两条分支，所以只是扩大了等效 BTB 容量。和 Zen 1 一样。

L0BTB holds 8 forward taken branches and 8 backward taken branches, and predicts with zero bubbles

Zen 2 的第一级 BTB 可以保存 8 条前向分支和 8 条后向分支，预测不会带来流水线气泡，也就是说每个周期都可以预测一次。相比 Zen 1 容量翻倍。

L1BTB has 512 entries and creates one bubble if prediction differs from L0BTB

Zen 2 的第二级 BTB 可以保存 512 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；预测会产生单个气泡，意味着它的延迟是两个周期。相比 Zen 1 容量翻倍。

L2BTB has 7168 entries and creates four bubbles if its prediction differs from L1BTB.

Zen 2 的第三级 BTB 可以保存 7168 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；预测会产生四个气泡，意味着它的延迟是五个周期。

简单整理一下官方信息，大概有三级 BTB：

(8+8)-entry L0 BTB, 1 cycle latency
512-entry L1 BTB, 2 cycle latency
7168-entry L2 BTB, 5 cycle latency

从表述来看，除了容量以外基本和 Zen 1 一致，猜测是在 Zen 1 的基础上扩大了容量。

下面结合微架构测试，进一步研究它的内部结构。

微架构测试¶

在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。

考虑到 Zen 2 的 BTB 可能出现一个 entry 保存两条分支的情况，并且还对分支的类型有要求，因此下面的测试都会进行四组，分别对应四种分支模式：

uncond：所有分支都是无条件分支：uncond, uncond, uncond, uncond, ...
cond：所有分支都是条件分支：cond, cond, cond, cond, ...
mix (uncond + cond)：条件分支和无条件分支轮流出现，但 uncond 在先：uncond, cond, uncond, cond, ...
mix (cond + uncond)：条件分支和无条件分支轮流出现，但 cond 在先：cond, uncond, cond, uncond, ...

stride=4B¶

首先是 stride=4B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

所有分支模式下，第一个台阶都是到 8 条分支，CPI=1，8 对应了 8-entry 的 L0 BTB
所有分支模式下，第二个台阶都是到 256 条分支，CPI=2，对应了 512-entry 的 L1 BTB，只体现出了一半的容量；但在 mix (uncond + cond) 和 mix (cond + uncond) 模式下，分支从 256 到 512 时 CPI 缓慢上升，意味着 L1 BTB 的 512-entry 还是可以完整访问，只是带来了一定的开销：CPI 从 2 增加到了 2.5
在 uncond 和 cond 模式下，第三个台阶到 4096 条分支，CPI=5，对应 L2 BTB，没有显现出完整的 7168 的大小
在 mix (uncond + cond) 模式下，第三个台阶延伸到了 5120，超出了 4096，依然没有显现出完整的 7168 的大小
在 mix (cond + uncond) 模式下，第三个台阶延伸到了 7168，显现出完整的 7168 的大小

和 Zen 1 不同，Zen 2 的 L1 BTB 出现了不同模式下容量不同的情况，原因未知，后续还会看到类似的情况。

Zen 2 的 L2 BTB 依然是带有压缩的，只有在 mix (cond + uncond) 模式下才可以尽可能地用上所有的容量，而其余的三种模式都有容量上的损失。

stride=8B¶

接下来观察 stride=8B 的情况：

现象和 stride=4B 基本相同，L1 BTB 从 256 到 512 部分的变化斜率有所不同，其余部分一致。

stride=16B¶

继续观察 stride=16B 的情况：

相比 stride=4B/8B，L0 BTB 和 L2 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量减半到了 128，意味着 L1 BTB 采用了组相连，此时有一半的 set 不能被用上。此外，比较特别的是，从 stride=16B 开始，CPI=5 的平台出现了波动，uncond 模式下 CPI 从 5 变到 4 再变到了 5，猜测此时 L1 BTB 也有一定的比例会介入。

stride=32B¶

继续观察 stride=32B 的情况：

相比 stride=16B，L0 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量进一步减到了 64，符合组相连的预期；L2 BTB 在 mix (uncond + cond) 模式下不再能体现出 5120 的容量，而是 4096：此时在一个 64B cacheline 中只有两条分支，第一条分支是 uncond，第二条分支是 cond，不满足 entry 共享的条件（必须 cond + uncond，不能是 uncond + cond），此时 uncond 和 cond 分别保存在两个 entry 中，每个 entry 只保存一条分支，因此 L2 BTB 只能体现出 4096 的容量。而 mix (cond + uncond) 模式依然满足 entry 共享的条件，所以依然体现出 7168 的容量。特别地，在 mix (cond + uncond) 模式下出现了非常剧烈的 CPI 抖动，可能出现了一些预期之外的性能问题。

stride=64B¶

继续观察 stride=64B 的情况：

相比 stride=32B，L0 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量进一步减到了 32，符合组相连的预期，但 cond 模式下依然保持了 512 的容量；L2 BTB 在 mix (cond + uncond) 模式下只能体现出 4096 的容量，此时每个 64B cacheline 都只有一条分支，不满足两条分支共享一个 entry 的条件。

stride=128B¶

继续观察 stride=128B 的情况：

相比 stride=64B，L0 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量进一步减到了 16，符合组相连的预期，而 cond 模式下 L1 BTB 容量也减少到了 256；L2 BTB 的容量减半到了 2048，意味着 L2 BTB 也是组相连结构。

小结¶

测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：

L0 BTB 是 (8+8)-entry，1 cycle latency，不随着 stride 变化，全相连
L1 BTB 是 512-entry，2 cycle latency，容量随着 stride 变化，大概率是 PC[n:3] 这一段被用于 index，使得 stride=16B 开始容量不断减半；但 cond 模式下的行为和其余几种模式不同，直到 stride=128B 才开始容量减半
L2 BTB 是 4096-entry，5 cycle latency，容量随着 stride 变化，大概率是 PC[n:6] 这一段被用于 index，使得 stride=128B 开始容量不断减半；其中有 3072 个 entry 最多保存两条分支，前提是这两条分支在同一个 cacheline 当中，并且第一条是 cond，第二条是 uncond；因此最多保存 7168 条分支

Zen 1 和 Zen 2 的 BTB 的对比¶

下面是对比表格：

uArch	AMD Zen 1	AMD Zen 2
L0 BTB size	4+4 branches	8+8 branches
L0 BTB latency	1 cycle	1 cycle
L1 BTB size	256 branches	512 branches
L1 BTB latency	2 cycles	2 cycles
L2 BTB size w/o sharing	2K branches	4K branches
L2 BTB size w/ sharing	4K branches	7K branches
L2 BTB latency	5 cycles	5 cycles
Technology Node	14nm	7nm
Release Year	2017	2019

可见 Zen 2 在容量上做了一定的扩展，但机制上比较类似；特别地，可能是观察到 cond + uncond 的压缩能够生效的比例没有那么高，所以只允许其中一部分 entry 被压缩，例如 4 路组相连，只有前 3 个 way 是可以保存两条分支；剩下的一个 way 只能保存一条分支。

AMD Zen 2 和 ARM Neoverse N1 的 BTB 的对比¶

AMD Zen 2 和 ARM Neoverse N1 都是在 2019 发布的处理器，下面对它们进行一个对比：

uArch	AMD Zen 2	ARM Neoverse N1
L0/Nano BTB size	8+8 branches	16 branches
L0/Nano BTB latency	1 cycle	1 cycle
L1/Micro BTB size	512 branches	64 branches
L1/Micro BTB latency	2 cycles	2 cycles
L2/Main BTB size w/o sharing	4K branches	3K*2 branches
L2/Main BTB size w/ sharing	7K branches	3K*2 branches
L2/Main BTB latency	5 cycles	2-3 cycles
Technology Node	7nm	7nm

可见 AMD Zen 2 在 BTB 容量上有优势，但是延迟要更长；两者都在最后一级 BTB 上做了压缩，但是压缩的方法和目的不同：

AMD Zen 2 的压缩方法是，把同一个 64B cacheline 内一条 cond 和一条 uncond 指令放在同一个 entry 当中。这样做的好处是，当预测到 cond 分支不跳转的时候，可以直接根据 uncond 指令的信息，得到下一个 fetch block 的地址；但是也对代码的结构有要求，必须是在同一个 cacheline 中，依次出现一个 cond 和一个 uncond
ARM Neoverse N1 的压缩方法是，根据立即数范围对分支进行分类，如果分支的立即数范围比较小，就只占用一个 entry 的一半也就是 41 bit；如果分支的立即数范围过大，就占用一个完整的 82 bit 的 entry；这主要是一个减少 SRAM 占用的优化，避免了所有的分支都要记录完整的 82 bit 信息；对代码的结构要求比较小，只要是跳转距离不太远的分支，都可以存到 41 bit 内

二者都没有实现一个周期预测两条分支，即 two taken（ARM 的说法是 two predicted branches per cycle）。这要等到 2020 年的 ARM Neoverse N2/V1，或者 2022 年的 AMD Zen 4 才被实现。

注意到 AMD 的 Software Optimization Guide for AMD EPYC™ 7002 Processors (Publication No. 56305) 文档里，有这么一段表述：

Branches whose target crosses a half-megabyte aligned boundary are unable to be installed in the L0 BTB or to share BTB entries with other branches.

也就是说，如果两个分支要共享一个 BTB entry，那么它们的目的地址不能跨越 512KB 边界，也就是和分支地址的偏移量不超过 19 位。按 48 位虚拟地址计算，如果 BTB entry 只记录一条分支，最多需要记录目的地址的完整 48 位地址；如果现在 BTB entry 要存两条分支，这两条分支的目的地址都只需要记录 19 位，加起来也就 38 位，还可以空余 10 位的信息用来维护 BTB sharing 所需的额外信息。

所以说到底，无论是 AMD 还是 ARM，做的事情都是对一个固定长度的 entry 设置了不同的格式，一个格式保存的地址位数多，但是只能保存一个分支；另一个格式保存的地址位数少，但是可以保存两个分支。区别就是 AMD 对两个分支的类型和位置有要求，而 ARM 允许这两个分支毫无关系。这就是不同厂商的取舍了。

AMD Zen 1 的 BTB 结构分析

Mon, 07 Jul 2025 00:00:00 +0000

AMD Zen 1 的 BTB 结构分析¶

背景¶

AMD Zen 1 是 AMD 在 2017 年发布的 Zen 系列第一代微架构。在之前，我们分析了 ARM Neoverse N1 和 V1 的 BTB，那么现在也把视线转到 AMD 上，看看 AMD 的 Zen 系列的 BTB 是如何演进的。

官方信息¶

AMD 在 Software Optimization Guide for AMD Family 17h Processors (Publication No. 55723) 中有如下的表述：

The branch target buffer (BTB) is a three-level structure accessed using the fetch address of the current fetch block.

Zen 1 的 BTB 有三级，是用当前 fetch block 的地址去查询。

Each BTB entry includes information for branches and their targets. Each BTB entry can hold up to two branches if the branches reside in the same 64-byte aligned cache line and the first branch is a conditional branch.

Zen 1 的 BTB entry 有一定的压缩能力，一个 entry 最多保存两条分支，前提是两条分支在同一个 64B 缓存行中，并且第一条分支是条件分支。这样，如果第二条分支是无条件分支，分支预测的时候，可以根据第一条分支的方向预测的结果，决定要用哪条分支的目的地址作为下一个 fetch block 的地址。虽然有压缩能力，但是没有提到单个周期预测两条分支，所以只是扩大了等效 BTB 容量。

例如，有这么一段代码：

# fetch block entrypoint entrypoint: # do something jnz targetA # do something jmp targetB

那么 jnz 和 jmp 指令可以放到同一个 entry 当中，一次读出来，然后对 jnz 指令进行分支方向预测：

如果 jnz 预测为跳转，那么当前 fetch block 从 entrypoint 开始，到 jnz 结束；下一个 fetch block 从 targetA 开始
如果 jnz 预测为不跳转，那么当前 fetch block 从 entrypoint 开始，到 jmp 结束；下一个 fetch block 从 targetB 开始

L0BTB holds 4 forward taken branches and 4 backward taken branches, and predicts with zero bubbles.

Zen 1 的第一级 BTB 可以保存 4 条前向分支和 4 条后向分支，预测不会带来流水线气泡，也就是说每个周期都可以预测一次。

L1BTB has 256 entries and creates one bubble if prediction differs from L0BTB.

Zen 1 的第二级 BTB 可以保存 256 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；预测会产生单个气泡，意味着它的延迟是两个周期。

L2BTB has 4096 entries and creates four bubbles if its prediction differs from L1BTB.

Zen 1 的第三级 BTB 可以保存 4096 个 entry，但不确定这个 entry 是否可以保存两条分支，也不确定这个 entry 数量代表了实际的 entry 数量还是分支数量，后续会做实验证实；预测会产生四个气泡，意味着它的延迟是五个周期。

简单整理一下官方信息，大概有三级 BTB：

(4+4)-entry L0 BTB, 1 cycle latency
256-entry L1 BTB, 2 cycle latency
4096-entry L2 BTB, 5 cycle latency

下面结合微架构测试，进一步研究它的内部结构。

微架构测试¶

在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。

考虑到 Zen 1 的 BTB 可能出现一个 entry 保存两条分支的情况，并且还对分支的类型有要求，因此下面的测试都会进行四组，分别对应四种分支模式：

uncond：所有分支都是无条件分支：uncond, uncond, uncond, uncond, ...
cond：所有分支都是条件分支：cond, cond, cond, cond, ...
mix (uncond + cond)：条件分支和无条件分支轮流出现，但 uncond 在先：uncond, cond, uncond, cond, ...
mix (cond + uncond)：条件分支和无条件分支轮流出现，但 cond 在先：cond, uncond, cond, uncond, ...

stride=4B¶

首先是 stride=4B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

所有分支模式下，第一个台阶都是到 4 条分支，CPI=1.25，比 1 周期略高，猜测是因为循环体比较小，循环结束的操作的开销没有平摊造成的；4 对应了 4-entry 的 L0 BTB
所有分支模式下，第二个台阶都是到 256 条分支，CPI=2，对应了 256-entry 的 L1 BTB，意味着 L1 BTB 没有做一个 BTB entry 记录两条分支的优化，实际上就是 256 个 entry 保存 256 条分支
在 uncond 和 cond 模式下，第三个台阶到 2048 条分支，CPI=5，对应 L2 BTB，没有显现出完整的 4096 的大小，意味着 L2 BTB 实际上只有 2048 个 entry，每个 entry 最多保存两条分支，而 uncond 和 cond 模式下，不满足每个 entry 保存两条分支的条件，所以只保存了 2048 条分支
在 mix (uncond + cond) 模式下，第三个台阶一直延伸到了 3072，超出了 2048，意味着出现了两条分支保存在一个 entry 的情况，但并没有体现出完整的 4096 条分支的大小
在 mix (cond + uncond) 模式下，第三个台阶延伸到了 4096，体现出完整的 4096 的 L2 BTB 大小

可以观察到，过了 L2 BTB 容量以后，性能骤降到十多个 cycle，此时还没有超出 L1 ICache 容量，这么长的延迟，即使是在 uncond 模式下，可以在译码的时候发现 uncond 分支并 redirect，也要 16+ 个周期，可见其流水线之长。

stride=8B¶

接下来观察 stride=8B 的情况：

现象和 stride=4B 基本相同，各级 BTB 显现出来的大小没有变化。

stride=16B¶

继续观察 stride=16B 的情况：

相比 stride=4B/8B，L0 BTB 的行为没有变化；L1 BTB 的容量减半到了 128，意味着 L1 BTB 采用了组相连，此时有一半的 set 不能被用上。此外，比较特别的是，从 stride=16B 开始，CPI=5 的平台出现了波动，CPI 从 5 变到 4 再变到了 5，猜测此时 L1 BTB 也有一定的比例会介入。L2 BTB 在 mix (uncond + cond) 模式下，拐点从 3072 前移到 2560。

stride=32B¶

继续观察 stride=32B 的情况：

相比 stride=16B，L0 BTB 的行为没有变化；L1 BTB 的容量进一步减到了 64，符合组相连的预期；L2 BTB 在 mix (uncond + cond) 模式下不再能体现出 3072 的容量，而是 2048：此时在一个 64B cacheline 中只有两条分支，第一条分支是 uncond，第二条分支是 cond，不满足 entry 共享的条件（必须 cond + uncond，不能是 uncond + cond），此时 uncond 和 cond 分别保存在两个 entry 中，每个 entry 只保存一条分支，因此 L2 BTB 只能体现出 2048 的容量。而 mix (cond + uncond) 模式依然满足 entry 共享的条件，所以依然体现出 4096 的容量。

stride=64B¶

继续观察 stride=64B 的情况：

相比 stride=32B，L0 BTB 的行为没有变化；L1 BTB 的容量进一步减到了 32，符合组相连的预期；L2 BTB 在 mix (cond + uncond) 模式下只能体现出 2048 的容量，此时每个 64B cacheline 都只有一条分支，不满足两条分支共享一个 entry 的条件。

stride=128B¶

继续观察 stride=128B 的情况：

相比 stride=64B，L0 BTB 的行为没有变化；L1 BTB 的容量进一步减到了 16，符合组相连的预期；L2 BTB 的容量减半到了 1024，意味着 L2 BTB 也是组相连结构。

小结¶

测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：

L0 BTB 是 (4+4)-entry，1 cycle latency，不随着 stride 变化，全相连
L1 BTB 是 256-entry，2 cycle latency，容量随着 stride 变化，大概率是 PC[n:3] 这一段被用于 index，使得 stride=16B 开始容量不断减半
L2 BTB 是 2048-entry，5 cycle latency，容量随着 stride 变化，大概率是 PC[n:6] 这一段被用于 index，使得 stride=128B 开始容量不断减半；每个 entry 最多保存两条分支，前提是这两条分支在同一个 cacheline 当中，并且第一条是 cond，第二条是 uncond；因此最多保存 4096 个分支

也总结一下前面发现了各种没有解释的遗留问题：

stride=4B/8B/16B 且为 mix (uncond + cond) 模式时，L2 BTB 体现出 3072/3072/2560 的容量，而非 4096：解析见后
L2 BTB 对应的 CPI=5 的台阶出现比较明显的，在 4-5 之间的波动：暂无解释

接下来尝试解析一下这些遗留问题背后的原理。部分遗留问题，并没有被解释出来，欢迎读者提出猜想。

解析遗留问题¶

stride=4B/8B/16B 且为 mix (uncond + cond) 模式时，L2 BTB 体现出 3072/3072/2560 的容量，而非 4096¶

前面测试出来，观察到两个奇怪的容量：3072 和 2560，分别有 3 和 5 的因子。下面通过进一步的实验，观察它的来源。

stride=16B 对应 2560 的 L2 BTB 容量¶

首先针对这个 2560 的拐点，做了一系列测试，在 stride=16B 的情况下，测试不同的 uncond/cond 分支的组合，下面是 64B cacheline 内四条分支的类型的不同组合（U 代表 Uncond，C 代表 Cond），以及该组合对应的容量：

CCCC: 2048（即 cond 模式）
CCCU: 2560
CCUC: 2560
CCUU: 2560
CUCC: 2560
CUCU: 4096（即 mix (cond + uncond) 模式）
CUUC: 2560
CUUU: 2560
UCCC: 2048
UCCU: 2560
UCUC: 2560（即 mix (uncond + cond) 模式）
UCUU: 2560
UUCC: 2048
UUCU: 2560
UUUC: 2048
UUUU: 2048（即 uncond 模式）

可以观察到，如果没有出现连续的 CU（CCCC/UCCC/UUCC/UUUC/UUUU），容量是 2048；如果出现了一组 CU（CCCU/CCUC/CCUU/CUCC/CUUC/CUUU/UCCU/UCUC/UCUU/UUCU），容量是 2560；出现了两组 CU（CUCU），就是 mix (cond + uncond) 模式，容量是 4096。

一种可能的猜想：

如果没有出现连续的 CU，那么每个 branch 占用一个 entry，那么容量就是 2048 个 branch
如果出现了一组 CU，那么一个 64B cacheline 里的 4 个 branch 对应 3 个 entry，那么前 2048 个 branch 对应 1536 个 entry，还剩下 512 个 entry，这些 entry 每个 entry 只放 1 个 branch（讨论见后），所以最后容量是 2048+512=2560 个 branch
如果出现了两组 CU，那么每一组 CU 的两个 branch 对应一个 entry，容量是 4096 个 branch

但是也遗留了一个问题，就是只有一组 CU 的情况下，为啥剩下的 512 个 entry 只放 512 个 branch，而不能放 1024 个 branch，按理说是可能再次出现 cond + uncond 合并？这个问题暂时还没有解释。

由此可以看出，2560 的来源是 4 路组相连，然后其中一路发生了 cond + uncond 的合并，所以最终是 5 个分支保存到 4 路当中，再来一条分支就会放不下。

stride=4B/8B 对应 3072 的 L2 BTB 容量¶

带着上面的分析，再去观察 stride=4B/8B 时的 3072:3072 有 3 的因子，所以大概率是从 2 路组相连得来，其中一路出现了 cond + uncond 的合并，所以出现了 3 个 branch 占用 2 个 entry 的情况，最后体现出来就是 3072 的 L2 BTB 容量。

似乎到这里，3072 和 2560 分别的 3 和 5 的因子都能解释了，剩下的就是解析具体的组相连的结构。

组相连分析¶

那么到底是 2 路组相连，还是 4 路组相连呢，另外这个组相连的 set 是怎么构成的呢？

首先回忆一下，在 ARM Neoverse N1 中，连续的 32B 内能放 6 个分支，但是 stride=8B 的时候，一次就会往同一个 set 里增加 4 个分支，于是一个 set 内的分支数从 0 变到 4 再变到 8，拐点出现在 4 个分支，而不是 6 个分支。因此为了达到前面出现的 3072 和 2560 的拐点，新增的分支也得均匀地分到各个 set 当中。

前面根据 L2 BTB 的容量分析到，L2 BTB 的 Index 可能是 PC[n:6]，但肯定不是简单的这么取，否则也会出现 ARM Neoverse N1 类似的问题。只能说明 PC[6] 往上有若干个 bit 是单独出现在 L2 BTB 的 Index 当中的，而 PC[5] 以下的 bit，可能以某种哈希函数的形式，参与到 Index 当中。

所以，L2 BTB 可能是以 PC[n:6] 作为 Index 去访问，然后内部有多个 bank，每个 bank 内部是 2 路组相连。bank index 是通过 PC 经过哈希计算得来，使得在 stride=4B/8B 的时候，体现出 2 路组相连，而在 stride=16B 的时候，体现出 4 路组相连。同时，分支还能够均匀地分布到各个 bank 当中，避免了和 ARM Neoverse N1 类似的情况的发生。

ARM Neoverse V1 (代号 Zeus) 的 BTB 结构分析

Mon, 23 Jun 2025 00:00:00 +0000

ARM Neoverse V1 (代号 Zeus) 的 BTB 结构分析¶

背景¶

ARM Neoverse V1 是 ARM Neoverse N1 的下一代服务器 CPU，在 2020 年发布。此前我们分析过 Neoverse N1 的 BTB 设计。而 ARM Neoverse V1 在很多地方都和 Cortex-X1 类似，相比 Neoverse N1/Cortex-A76 有了一些改进，在这里对它的 BTB 做一些分析。

官方信息¶

首先收集了一些 ARM Neoverse V1 的 BTB 结构的官方信息：

SW defined cars: HPC, from the cloud to the dashboard for an amazing driver experience
- 64KB L1 ICache, 2x32B bandwidth
- 8K-entry main BTB
- 96-entry nano BTB, 0 cycle bubble
- 2 stage prediction pipeline: P1 & P2，大概率 nano BTB 在 P1，main BTB 在 P2
Arm Neoverse V2 platform: Leadership Performance and Power Efficiency for Next-Generation Cloud Computing, ML and HPC Workloads
- 2 predicted branches per cycle，每周期最多预测两条分支

简单整理一下官方信息，大概有两级 BTB：

96-entry nano BTB, 1 cycle latency (0 cycle bubble)
8K-entry main BTB
2 predicted branches per cycle

但是很多细节是缺失的，因此下面结合微架构测试，进一步研究它的内部结构。

微架构测试¶

在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件（uncond）或总是跳转的有条件（cond）直接分支，构成一个链条，然后测量 CPI。在先前的 Neoverse N1 测试里，我们只测试了无条件分支，但实际上，在 Neoverse N1 上用条件分支测出来的结果也是一样的，但在 Neoverse V1 上就不同了，所以在这里要分开讨论。

stride=4B uncond¶

首先是 stride=4B uncond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到接近 64 条分支，CPI=1，对应了 96-entry 的 nano BTB，但是没有体现出完整的 96 的容量
第二个台阶到 16384 条分支，CPI 在 5 到 6 之间，大于 main BTB 的 2 cycle latency，说明此时没有命中 main BTB，而是要等到取指和译码后，计算出正确的目的地址再回滚，导致了 5+ cycle latency；16384 对应 64KB L1 ICache 容量

那么 stride=4B uncond 的情况下就遗留了如下问题：

nano BTB 没表现出 96 的容量，只表现出接近 64 的容量
没有观察到 2 predicted branches per cycle
没有命中 main BTB

stride=4B cond¶

stride=4B cond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 48 条分支，CPI=1，对应了 96-entry 的 nano BTB，但是没有体现出完整的 96 的容量
之后没有明显的分界点，性能波动剧烈，没有观察到 main BTB 的台阶

nano BTB 只表现出 48 的容量，刚好是 96 的一半；同时没有观察到 2 predicted branches per cycle。考虑这两点，可以认为 nano BTB 的组织方式和分支类型有关，当分支过于密集（stride=4B）或者用条件分支（cond）时，不能得到完整的 96-entry 的大小，此时也会回落到 CPI=1 的情况。

那么 stride=4B cond 的情况下就遗留了如下问题：

没有命中 main BTB

stride=8B uncond¶

stride=8B uncond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 96 条分支，CPI=0.5，对应了 96-entry 的 nano BTB，体现了 2 predicted branches per cycle
第二个台阶到 8192 条分支，CPI=1，对应 main BTB，此时也对应了 64KB L1 ICache；此外，从 4096 开始有略微的上升

此时 nano BTB 完整地表现出了它的 96-entry 容量，并且实现了 CPI=0.5 的效果。main BTB 也实现了 CPI=1，考虑到它的容量不太可能单周期给出一个分支的结果，大概率是两个周期预测两条分支指令。

那么 stride=8B uncond 的情况下就遗留了如下问题：

从 4096 条分支开始性能有略微的下降

stride=8B cond¶

stride=8B cond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 48 条分支，CPI=1，对应了 96-entry 的 nano BTB，没有 2 predicted branches per cycle，容量也只有 96 的一半
第二个台阶到 8192 条分支，CPI=2，对应 main BTB，此时也对应了 64KB L1 ICache

和之前一样，遇到 cond 分支，nano BTB 的容量只有一半，也观察不到 2 predicted branches per cycle。另一边，main BTB 的 CPI 也到了 2，意味着此时 main BTB 也只能两个周期预测一条分支指令，和之前的分析吻合。

那么为什么用条件分支，就不能预测两条分支指令了呢？猜测是，BTB 可以一次给出两条分支的信息，但是没有时间去同时预测这两条分支的方向。所以就回落到了普通的 2 cycle BTB 情况。

stride=16B uncond¶

stride=16B uncond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 96 条分支，CPI=0.5，对应了 96-entry 的 nano BTB，体现了 2 predicted branches per cycle
第二个台阶到 2048 条分支，CPI=1；略微上升到 4096，此时是 64KB L1 ICache 的容量；到 8192 出现明显突变，对应 main BTB 容量

那么 stride=16B uncond 的情况下就遗留了如下问题：

从 2048 条分支开始性能有略微的下降

stride=16B cond¶

stride=16B cond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 48 条分支，CPI=1，对应了 96-entry 的 nano BTB，没有 2 predicted branches per cycle，容量也只有 96 的一半
第二个台阶到 8192 条分支，CPI=2，对应 main BTB

预测的效果和 stride=8B cond 完全相同。

那么 stride=16B cond 的情况下就遗留了如下问题：

64KB ICache 应该在 4096 条分支导致瓶颈，但是实际没有观察到

stride=32B uncond¶

stride=32B uncond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 96 条分支，CPI=0.5，对应了 96-entry 的 nano BTB，体现了 2 predicted branches per cycle
第二个台阶到 1024 条分支，CPI=1；略微上升到 2048，此时是 64KB L1 ICache 的容量；到 8192 右侧出现明显突变

那么 stride=32B uncond 的情况下就遗留了如下问题：

从 1024 条分支开始性能有略微的下降
性能明显下降的点在 8192 右侧，而不是 8192

stride=32B cond¶

stride=32B cond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 48 条分支，CPI=1，对应了 96-entry 的 nano BTB，没有 2 predicted branches per cycle，容量也只有 96 的一半
第二个台阶到 2048 条分支，CPI=2，对应 64KB L1 ICache 容量，之后缓慢上升，到 8192 出现性能突变，对应 main BTB 容量

基本符合预期，只是在 stride=16B cond 的基础上，引入了 64KB L1 ICache 导致的性能下降。

stride=64B uncond¶

stride=64B uncond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 96 条分支，CPI=0.5，对应了 96-entry 的 nano BTB，体现了 2 predicted branches per cycle
第二个台阶到 1024 条分支，CPI=1，对应 64KB L1 ICache 的容量
第三个台阶到 4096，CPI=3，对应 main BTB 的容量；main BTB 容量减半，意味着 main BTB 应当是个组相连结构

stride=64B cond¶

stride=64B cond 的情况：

可以看到，图像上出现了如下比较显著的台阶：

第一个台阶到 48 条分支，CPI=1，对应了 96-entry 的 nano BTB，没有 2 predicted branches per cycle，容量也只有 96 的一半
第二个台阶到 1024 条分支，CPI=2，对应 64KB L1 ICache 容量，之后缓慢上升，到 4096 出现性能突变，对应 main BTB 容量；main BTB 容量只有 8192 的一半，意味着它是组相连结构

小结¶

测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：

nano BTB 是 96-entry，1 cycle latency，对于 uncond 分支可以做到一次预测两条分支，大小不随着 stride 变化，对应全相连结构
main BTB 是 8K-entry，2 cycle latency，对于 uncond 分支可以做到一次预测两条分支，此时可以达到 CPI=1；容量随着 stride 变化，对应组相连结构
64KB ICache 很多时候会比 main BTB 更早成为瓶颈

也总结一下前面发现了各种没有解释的遗留问题：

cond 分支情况下，没有 2 predicted branches per cycle，此时两级 BTB 分别可以做到 CPI=1 和 CPI=2，同时 nano BTB 容量减半到 48：解释见后
stride=4B uncond/cond 的情况下，main BTB 没有像预期那样工作：解释见后
stride=8B/16B/32B uncond 的情况下，4096/2048/1024 条分支处出现了性能下降：暂无解释
stride=32B uncond 的情况下，main BTB 导致的拐点应该在 8192，但实际上在 8192 右侧：暂无解释
stride=16B cond 的情况下，64KB ICache 应该在 4096 条分支导致瓶颈，但是实际没有观察到：暂无解释

接下来尝试解析一下这些遗留问题背后的原理。部分遗留问题，并没有被解释出来，欢迎读者提出猜想。

解析遗留问题¶

cond 分支情况下，没有 2 predicted branches per cycle，同时 nano BTB 只有 48 的容量¶

比较相同 stride 下，cond 和 uncond 的情况，可以看到，cond 情况下两级 BTB 的 CPI 都翻倍，这意味着，当遇到全是 cond 分支时，大概是因为条件分支预测器的带宽问题，不能一次性预测两个 cond 分支的方向，而只能预测第一条 cond 分支，那么第二条 cond 分支的信息，即使通过 BTB 读取出来，也不能立即使用，还得等下一次的预测。

为了验证这个猜想，额外做了一组实验：把分支按照 cond, uncond, cond, uncond, ... 的顺序排列，也就是每个 cond 分支的目的地址有一条 uncond 分支。此时测出来的结果，和 uncond 相同，也就是可以做到 2 predicted branches per cycle。此时，BTB 依然一次提供了两条分支的信息，只不过条件分支预测器只预测了第一个 cond 的方向。如果它预测为不跳转，那么下一个 PC 就是 cond 分支的下一条指令；如果它预测为跳转，那么下一个 PC 就是 uncond 分支的目的地址。

nano BTB 的容量减半，意味着 nano BTB 的 96 的容量，实际上是 48 个 entry，每个 entry 最多记录两条分支。考虑到 nano BTB 的容量不随 stride 变化，大概率是全相连，并且是根据第一条分支的地址进行全相连匹配，这样，在 cond + cond 这种情况下，就只能表现出 48 的容量。但是 stride=4B uncond 的情况下表现出介于 48 和 64 之间的容量，还不知道是什么原因。

main BTB 的容量不变，意味着它在 cond + cond 的情况下，会退化为普通的 BTB，此时所有容量都可以用来保存 cond 分支，并且都能匹配到。

那么，具体是怎么做到 2 predicted branches per cycle 呢？猜测在执行的时候，检测这种一个分支的目的地址后，跟着一条 uncond 分支的情况：如果有的话，就把第二条分支的信息，放在第一条分支的信息后面（这在 Branch Target Buffer Organizations 中被称为 MB-BTB 结构），单个周期直接从 SRAM 读取出来，然后组成两个 fetch bundle：

prediction pc -- first branch pc
first branch target -- second branch pc

然后下一个周期从 second branch target 开始继续预测。根据官方信息，Neoverse V1 的 L1 ICache 支持 2x32B 的带宽，这个 2x 代表了可以从两个不同的地方读取指令，也就是 L1 ICache 至少是双 bank 甚至双端口的 SRAM。考虑到前面的测试中，CPI=0.5 的范围跨越了各种 stride，认为 L1 ICache 是双 bank 的可能写比较小，不然应该会观测到 bank conflict，大概率就是双端口了。

此外，考虑到 fetch bundle 的长度限制，first branch target 到 second branch pc 不能太远。在上面的测试中，这个距离总是 0；读者如果感兴趣，可以尝试把距离拉长，看看超过 32B 以后，是不是会让 2 predicted branches per cycle 失效。类似的表述，在 AMD Zen 4 Software Optimization Guide 中也有出现：

The branch target buffer (BTB) is a two-level structure accessed using the fetch address of the previous fetch block. Each BTB entry includes information for branches and their targets. Each BTB entry can hold up to two branches, and two pair cases are supported: • A conditional branch followed by another branch with both branches having their last byte in the same 64 byte aligned cacheline. • A direct branch (excluding CALLs) followed by a branch ending within the 64 byte aligned cacheline containing the target of the first branch. Predicting with BTB pairs allows two fetches to be predicted in one prediction cycle.

上面的第二种情况，对应了第二条分支的 pc，在第一条分支的 target 的同一个 64 字节 cacheline 内的要求。可见，ARM 和 AMD 在 BTB 的设计上是趋同的。

小结，Neoverse V1 在满足如下条件时，可以做到 2 predicted branches per cycle：

uncond + uncond
cond + uncond

stride=4B uncond/cond 的情况下，main BTB 没有像预期那样工作¶

类似的情况，我们在分析 Neoverse N1 的时候就遇到了。Neoverse N1 的情况是，每对齐的 32B 块内，由于 6 路组相连，最多记录 6 条分支，而 stride=4B 时，有 8 条分支，所以出现了性能问题。

那么 Neoverse V1 是不是还是类似的情况呢？查阅 Neoverse V1 TRM，可以看到它的 L1 (main) BTB 的描述是：

Index: [15:4]
Data: [91:0]

回想之前 Neoverse N1 的 main BTB 容量：Index 是 [14:5]，意味着有 1024 个 set；3 个 Way，每个 Way 里面是 82 bit 的数据，每个分支占用 41 bit，所以一共可以存 1024*3*2=6K 条分支。

类比一下，Neoverse V1 的 main BTB 容量也就可以计算得出：Index 是 [15:4]，意味着有 4096 个 set；没有 Way，说明就是直接映射；92 bit 的数据，大概率也是每个分支占用一半也就是 46 bit，所以一共可以存 4096*2=8K 条分支，和官方数据吻合。在需要 2 predicted branches 的时候，就把这两个分支放到同一个 92-bit entry 内即可。一共占用 4096*92=376832 bit 也就是 46 KB 的空间。

那么，在 stride=4B 的情况下，对齐的 16B 块内的分支会被放到同一个 set 内，而每个 set 只能放两条分支，而 stride=4B 时需要放四条分支，这就导致了 main BTB 出现性能问题。

但比较奇怪的是，main BTB 的容量，在 stride=32B 时是 8192，而 stride=64B 时是 4096，这和 Index 是 PC[15:4] 不符，这成为了新的遗留问题。有一种可能，就是 TRM 写的不准确，Index 并非 PC[15:4]。另外还有一个佐证：Neoverse N2 的 BTB 设计和 Neoverse V1 基本相同，但是它的 TRM 写的 Index 就是 [11:0]，这就肯定不是 PC[11:0] 了。

抛开 TRM，根据 JamesAslan 在偷懒的 BTB？ARM Cortex X1 初探中的测试，Main BTB 是四路组相连。如果按照四路组相连来考虑，那么 8K 条分支，实际上应该是 2048 个 set，2 个 way，一共是 4K 个 entry，每个 entry 最多保存两条分支。此时 Index 应该有 11 个 bit。在 2 way 每 way 两条分支等效为 4 way 的情况下，stride=4B 出现分支数比 way 数量更多的情况，stride=8B 则不会，意味着参与到 Index 的最低的 PC 应该是 PC[5]，即每个对齐的 32B 块内，最多放四条分支（Neoverse N1 上是每个对齐的 32B 块内最多放六条分支）。这样的话，Index 可能实际上是 PC[15:5]。

总结¶

最后总结一下 Neoverse V1 的 BTB：

48-entry(96 branches) nano BTB, at most 2 branches per entry, 1 cycle latency, at most 2 predicted branches every 1 cycle, fully associative
4K-entry(8K branches) main BTB, at most 2 branches per entry, 2 cycle latency, at most 2 predicted branches every 2 cycles, 2-way(4-branch-way) set-associative, index PC[15:5]

当 uncond + uncond 或者 cond + uncond 时，可以实现每次预测两条分支；对于 cond + cond，每次只能预测一条分支。

2 predicted branches per cycle 通常也被称为 2 taken branches per cycle，简称 2 taken。

附录¶

Neoverse N2（代号 Perseus）的 BTB 结构分析¶

根据官方信息，Neoverse N2 和 Neoverse V1 的 BTB 配置十分类似，从数字来看只有 nano BTB 缩小到了 32-entry(64 branches)，其余是相同的，例如 main BTB 容量也是 8K branches。实测下来，BTB 测试图像和 Neoverse V1 基本一样，只有 nano BTB 容量的区别。因此本文也可以认为是对 Neoverse N2 的 BTB 结构分析。考虑到 Neoverse N2 和 Neoverse V1 的发布时间相同，可以认为它们用的就是相同的前端设计，只是改了一下参数。

至于为啥 Neoverse N2 比 Neoverse V1 出的更晚但 nano BTB 还更小，可能是因为它是 N 系列而不是 V 系列，基于 Cortex-A710，所以容量上做了一些取舍。

各代 Neoverse 处理器的 BTB 结构对比¶

比较一下 Neoverse V1 和 Neoverse N1 的设计：

Neoverse N1 设计了三级 BTB（16+64+6K），分别对应 1-3 的周期的延迟，特别地，main BTB 设计了 fastpath 来实现一定情况下的 2 周期延迟
Neoverse V1 设计了两级 BTB（96+8K），分别对应 1-2 的周期的延迟，并且都支持 2 taken

Neoverse V1 相比 Neoverse N1，在容量和延迟上都有比较明显的提升，还额外给两级 BTB 都引入了 2 taken 的支持，进一步提升了吞吐。

Neoverse N1 是基于 Cortex A76 设计的，Neoverse V1 是基于 Cortex X1 设计的，中间还隔了一代 Cortex A77，根据官方信息，它的 1-cycle latency L1 BTB（即 Nano BTB）容量从 Cortex A76 的 16 变成了 64，main BTB 从 6K 扩到了 8K，而没有提 Micro BTB。同时也没有提到 two taken 的事情。由此推断，Cortex A77 扩大了 Nano BTB 和 Main BTB 的容量，去掉了 Micro BTB，因为 Nano BTB 的容量已经和原来 Neoverse N1 的 Micro BTB 一样大了，其他应该没有变化。再结合 Arm® Cortex®‑A77 Core Technical Reference Manual 可知它的 BTB index 是 [15:4]，每个 entry 是 82 bits，位宽和 Neoverse N1 一致，所以应该只是扩了容量。

再往前找 Cortex A73 和 Cortex A75，根据 Chips and Cheese 的实验数据，Cortex A73 有两级 BTB，第一级 BTB 是 48-entry 2-cycle latency（奇怪的是，官方信息中声称是 64 entry Micro BTAC，容量对不上，但还是更加相信实验数据），第二级 BTB 是 3K-entry 3-cycle latency。根据 Chips and Cheese 的实验数据，Cortex A75 有两级 BTB，第一级 BTB 是 32-entry 1-cycle latency，第二级 BTB 是 3K-entry 3-cycle latency。

下面是一个对比表格：

uArch	Cortex A73	Cortex A75	Neoverse N1	Cortex A77	Neoverse V1	Neoverse N2
Nano BTB size	N/A	32 branches	16 branches	64 branches	48*2 branches	32*2 branches
Nano BTB latency	N/A	1 cycle	1 cycle	1 cycle	1 cycle	1 cycle
Nano BTB throughput	N/A	1 branch	1 branch	1 branch	1-2 branches	1-2 branches
Micro BTB size	48 branches	N/A	64 branches	N/A	N/A	N/A
Micro BTB latency	2 cycles	N/A	2 cycles	N/A	N/A	N/A
Micro BTB throughput	1 branch	N/A	1 branch	N/A	N/A	N/A
Main BTB size	3K branches	3K branches	3K*2 branches	4K*2 branches	4K*2 branches	4K*2 branches
Main BTB latency	3 cycles	3 cycles	2-3 cycles	2-3 cycles	2 cycle	2 cycle
Main BTB throughput	1 branch	1 branch	1 branch	1 branch	1-2 branches	1-2 branches
Main BTB area (bits)	?	?	3K*82=251904	4K*82=335872	4K*92=376832	4K*92=376832
Main BTB area (KiB)	?	?	30.75	41	46	46
Technology Node	10nm	10nm	7nm	7nm	5nm	5nm

由此可以看出 ARM 在 BTB 上的优化脉络：

Cortex A75 相比 Cortex A73：
- 降低第一级 BTB 的延迟，从 2 周期的 Micro BTB 变成 1 周期的 Nano BTB，从而降低无条件分支的延迟，代价是容量变小了一些
Neoverse N1 相比 Cortex A75：
- 把 Nano BTB 拆分成 Nano 和 Micro 两级，从而增加容量
- 通过引入 BTB 压缩优化（即一个 Entry 可以保存 1-2 条分支），使得 Main BTB 能容纳更多的分支
- 针对 Main BTB 引入 fast path，当只有一个 way 匹配时，只需要 2 周期即可提供预测
Cortex A77 相比 Neoverse N1：
- 通过扩大 Nano BTB，去掉了 Micro BTB，让更多分支可以享受 1 周期的延迟
- 继续扩大 Main BTB
Neoverse V1 相比 Cortex A77：
- 在 Nano 和 Main BTB 上引入 two taken 预测，增加吞吐
- 减少 Main BTB 延迟，从 2-3 周期变成固定 2 周期

注：各代 Cortex 与 Neoverse 对应关系以及代号：

Cortex-A73(Artemis)
Cortex-A75(Prometheus)
Cortex-A76(Enyo)/Neoverse-N1(Ares)
Cortex-A77(Deimos)
Cortex-A78(Hercules)/Cortex-X1(Hera)/Neoverse-V1(Zeus, based on Cortex-X1)
Cortex-A710(Matterhorn)/Cortex-X2(Matterhorn ELP)/Neoverse-N2(Perseus, based on Cortex-A710)

在鸿蒙电脑上的虚拟机内启动 Linux

Tue, 10 Jun 2025 00:00:00 +0000

在鸿蒙电脑上的虚拟机内启动 Linux¶

背景¶

最近在研究鸿蒙电脑，群友 @Fearyncess 摸索出了，如何在鸿蒙电脑上的虚拟机内启动 Linux，而不是 Windows。在此做个复现并记录。

方法¶

目前鸿蒙的应用市场上有两家虚拟机，我用 Oseasy 虚拟机，但是理论上铠大师也是可以的。（P.S. @driver1998 反馈：“铠大师测试也能启动，但键盘左右方向键的处理有点问题，虚拟机内收不到按键松开的信号，EFI 和 Linux 里面都是这样。目前建议用 OSEasy。”）

首先需要在 U 盘上，把一个 UEFI arm64 的 Linux 安装盘写进去。我用的是 Ventoy + Debian Installer，理论上直接写例如 Debian 发行版的安装 ISO 也是可以的。

然后把 U 盘插到鸿蒙电脑上，打开 Windows 虚拟机，直通到虚拟机里面，保证虚拟机里面可以看到 U 盘。

接着，进入 Windows 磁盘管理，缩小 Windows 的 NTFS 分区，留出空间。注意 Windows 启动的时候会自动 growpart，所以装 Debian 前，不要回到 Windows。装好以后，可以继续用 Windows。

接着，重启 Windows，同时按住 Escape，进入 OVMF 的界面，然后选择 Boot Manager，从 U 盘启动，然后就进入 Ventoy 的界面了。（注：根据 @quiccat 群友提醒，在 Windows 内，通过设置->系统->恢复->高级启动->UEFI 固件设置也可以进入 OVMF 的设置界面）

剩下的就是正常的 Linux 安装过程了，分区的时候，注意保留 Windows 已有的 NTFS，可以和 Windows 用同一个 ESP 分区。网络的话，配置静态 IP 是 172.16.100.2，默认网关是 172.16.100.1 即可。重启以后，在 grub 界面，修改 linux 配置，在 cmdline 一栏添加 modprobe.blacklist=vmwgfx，这样就能启动了。内核版本是 Debian Bookworm 的 6.1。

各内核版本启动情况：

5.10 from debian：正常
6.1 from debian：正常
6.2/6.3/6.4 from kernel.ubuntu.com: echo simpledrm > /etc/modules-load.d/simpledrm.conf 后正常，否则系统可以启动但是图形界面起不来
6.5 from kernel.ubuntu.com：起不来，需要强制关机
6.12 from debian：起不来，需要强制关机

经过 @Fearyncess 的二分，找到了导致问题的 commit。

最终效果：

主要的遗憾是分辨率：屏幕两侧有黑边，并且由于宽度不同，触摸屏的位置映射会偏中间。

附录¶

Geekbench 6 测试结果：

如果没有 blacklist 的话，vmwgfx 驱动的报错：

vmwgfx 0000:00:04.0: [drm] FIFO at 0x0000000020000000 size is 2048 kiB vmwgfx 0000:00:04.0: [drm] VRAM at 0x0000000010000000 size is 262144 kiB vmwgfx 0000:00:04.0: [drm] *ERROR* Unsupported SVGA ID 0xffffffff on chipset 0x405 vmwgfx: probe of 0000:00:04.0 failed with error -38

blacklist vmwgfx 后用的是 efifb：

[ 0.465898] pci 0000:00:04.0: BAR 1: assigned to efifb [ 1.197638] efifb: probing for efifb [ 1.197705] efifb: framebuffer at 0x10000000, using 7500k, total 7500k [ 1.197708] efifb: mode is 1600x1200x32, linelength=6400, pages=1 [ 1.197711] efifb: scrolling: redraw [ 1.197712] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

虚拟机的 IP 地址，从宿主机也可以直接访问，通过 WVMBr 访问，目测是直接 Tap 接出来，然后建了个 Bridge，外加 NAT，只是没有 DHCP。

终端模拟器的文字绘制

Tue, 10 Jun 2025 00:00:00 +0000

终端模拟器的文字绘制¶

背景¶

最近在造鸿蒙电脑上的终端模拟器 Termony，一开始用 ArkTS 的 Text + Span 空间来绘制终端，后来发现这样性能和可定制性比较差，就选择了自己用 OpenGL 实现，顺带学习了一下终端模拟器的文字绘制是什么样的一个过程。

读取字形¶

文本绘制，首先就要从字体文件中读取字形，提取出 Bitmap 来，然后把 Bitmap 绘制到该去的地方。为了提取这些信息，首先用 FreeType 库，它可以解析字体文件，然后计算出给定大小的给定字符的 Bitmap。但是，这个 Bitmap 它只记录字体非空白的部分（准确的说，是 Bounding Box），如下图的 width * height 部分：

（图源：Managing Glyphs - FreeType Tutorial II）

其中 x 轴，应该是同一行的字体对齐的，这样才会看到有高有低的字符出现在同一行，而不是全部上对齐或者下对齐。得到的 Bitmap 是行优先的，也就是说：

图中左上角，坐标 (xMin, yMax) 对应 Bitmap 数组的下标是 0
图中右上角，坐标 (xMax, yMax) 对应 Bitmap 数组的下标是 width-1
图中左下角，坐标 (xMin, yMin) 对应 Bitmap 数组的下标是 width*(height-1)
图中右下角，坐标 (xMax, yMax) 对应 Bitmap 数组的下标是 width*(height-1)+width-1

得到这个 Bitmap 后，如果我们不用 OpenGL，而是直接生成 PNG，那就直接进行一次 copy 甚至 blend 就可以把文字绘制上去了。但是，我们要用 OpenGL 的 shader，就需要把 bitmap 放到 texture 里面。由于目前我们用的就是单色的字体，所以它对应只有一个 channel 的 texture。

OpenGL 的 texture，里面也是保存的 bitmap，但它的坐标系统的命名方式不太一样：它的水平向右方向是 U 轴，竖直向上方向是 V 轴，然后它的 bitmap 保存个数也是行优先，但是从 (0, 0) 坐标开始保存像素，然后 U 和 V 的范围都是 0 到 1。

所以，如果我们创建一个 width*height 的单通道 texture，直接把上面的 bitmap 拷贝到 texture 内部，实际的效果大概是：

 V  ^  |  C D  |  |  A------B--->U

上图中几个点的坐标以及对应的 bitmap 数组的下标：

A 点：U = 0，V = 0，对应 bitmap 数组下标 0
B 点：U = 1，V = 0，对应 bitmap 数组下标 width-1
C 点：U = 0，V = 1，对应 bitmap 数组下标 width*(height-1)
D 点：U = 1，V = 1，对应 bitmap 数组下标 width*(height-1)+width-1

所以在向 OpenGL 的 texture 保存 bitmap 的时候，相当于做了一个上下翻转，不过这没有关系，后续在指定三角形顶点的 U V 坐标的时候，保证对应关系即可。

逐个字符绘制¶

有了这个基础以后，就可以实现逐个字符绘制：提前把所有要用到的字符，从字体提取出对应的 Bitmap，每个字符对应到一个 Texture。然后要绘制文字的时候，逐个字符，用对应的 Texture，在想要绘制的位置上，绘制一个字符。为了实现这个目的，写一个简单的 Shader：

// vertex shader #version 320 es  in vec4 vertex; // xy is position, zw is its texture coordinates out vec2 texCoors; // output texture coordinates void main() {  gl_Position.xy = vertex.xy;  gl_Position.z = 0.0; // we don't care about depth now  gl_Position.w = 1.0; // (x, y, z, w) corresponds to (x/w, y/w, z/w), so we set w = 1.0  texCoords = vertex.zw; } // fragment shader #version 320 es precision lowp float; in vec2 texCoords; out vec4 color; uniform sampler2D text; void main() {  float alpha = texture(text, texCoords).r;  color = vec4(1.0, 1.0, 1.0, alpha); }

在这里，我们给每个顶点设置四个属性，包在一个 vec4 中：

xy：记录了这个顶点的坐标，x 和 y 范围都是 -1 到 1
zw：记录了这个顶点的 texture 坐标 u 和 v，范围都是 0 到 1

vertex shader 只是简单地把这些信息传递到顶点的坐标和 fragment shader。fragment shader 做的事情是：

根据当前点经过插值出来的 u v 坐标，在 texture 中进行采样
由于这个 texture 只有单通道，所以它的第一个 channel 也就是 texture(text, texCoords).r 就代表了这个字体在这个位置的 alpha 值
然后把 alpha 值输出：(1.0, 1.0, 1.0, alpha)，即带有 alpha 的白色

在绘制文字之前，先绘制好背景色，然后通过设置 blending function：

glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

它使得 blending 采用如下的公式：

final = src * src.alpha + dest * (1 - src.alpha);

这里 dest 就是绘制文本前的颜色，src 就是 fragment shader 输出的颜色，也就是 (1.0, 1.0, 1.0, alpha)。代入公式，就知道最终的结果是：

final.r = 1 * alpha + dest.r * (1 - alpha); final.g = 1 * alpha + dest.g * (1 - alpha); final.b = 1 * alpha + dest.b * (1 - alpha);

也就是以 alpha 为不透明度，把白色和背景颜色进行了一次 blend。

如果要设置字体颜色，只需要修改一下 fragment shader：

#version 320 es precision lowp float; in vec2 texCoords; out vec4 color; uniform sampler2D text; uniform vec3 textColor; void main() {  float alpha = texture(text, texCoords).r;  color = vec4(textColor, alpha); }

此时 src 等于 (textColor.r, textColor.g, textColor.b, alpha)，经过融合后的结果为：

final.r = textColor.r * alpha + dest.r * (1 - alpha); final.g = textColor.g * alpha + dest.g * (1 - alpha); final.b = textColor.b * alpha + dest.b * (1 - alpha);

即最终颜色，等于字体颜色和原来背景颜色，基于 bitmap 的 alpha 值的融合。

解决了颜色，接下来考虑如何设置顶点的信息。前面提到，得到的 bitmap 是一个矩形，而 OpenGL 绘图的基本元素是三角形，因此我们需要拆分成两个三角形来绘图，假如说要绘制一个矩形，它个四个顶点如下：

3-4 | | 1-2

如果确定左下角 3 这个顶点的坐标是 (xpos, ypos)，然后矩形的宽度是 w，高度是 h，考虑到 OpenGL 的坐标系也是向右 X 正方向，向上 Y 正方向，那么这四个顶点的坐标：

顶点 1：(xpos, ypos)
顶点 2：(xpos + w, ypos)
顶点 3：(xpos, ypos + h)
顶点 4：(xpos + w, ypos + h)

接下来考虑这些顶点对应的 uv 坐标。首先，我们知道这些顶点对应的 bitmap 的下标在哪里；然后我们又知道这些 bitmap 的下标对应的 uv 坐标，那就每个顶点找一次对应关系：

顶点 1：(xpos, ypos)，下标是 width*(height-1)，uv 坐标是 (0, 1)
顶点 2：(xpos + w, ypos)，下标是 width*(height-1)+width-1，uv 坐标是 (1, 1)
顶点 3：(xpos, ypos + h)，下标是 0，uv 坐标是 (0, 0)
顶点 4：(xpos + w, ypos + h)，下标是 width-1，uv 坐标是 (1, 0)

为了绘制这个矩形，绘制两个三角形，分别是 3->1->2 和 3->2->4，一共六个顶点的 (x, y, u, v) 信息就是：

3: (xpos , ypos + h, 0, 0)
1: (xpos , ypos , 0, 1)
2: (xpos + w, ypos , 1, 1)
3: (xpos , ypos + h, 0, 0)
2: (xpos + w, ypos , 1, 1)
4: (xpos + w, ypos + h, 1, 0)

把这些数传递给 vertex shader，就可以画出来这个字符了。

最后还有一个小细节：上述的 xpos 和 ypos 说的是矩形左下角的坐标，但是我们画图的时候，实际上期望的是把字符都画到同一条线上。也就是说，我们指定 origin 的 xy 坐标，然后根据每个字符的 bearingX 和 bearingY 来算出它的矩形的左下角的坐标 xpos 和 ypos：

xpos = originX + bearingX
ypos = originY + bearingY - height

至此就实现了逐个字符绘制需要的所有内容。这也是 Text Rendering - Learn OpenGL 这篇文章所讲的内容。

Texture Atlas¶

上面这种逐字符绘制的方法比较简单，但是也有硬伤，比如每次绘制字符，都需要切换 texture，更新 buffer，再进行一次 glDrawArrays 进行绘制，效率比较低。所以一个想法是，把这些 bitmap 拼接起来，合成一个大的 texture，然后把每个字符在这个大的 texture 内的 uv 坐标保存下来。这样，可以一次性把所有字符的所有三角形都传递给 OpenGL，一次绘制完成，不涉及到 texture 的切换。这样效率会高很多。

具体到代码上，也就是分成两步：

bitmap 的拼接，这一步比较灵活，理想情况下是构造一个比较紧密的排布，但也可以留一些空间，直接对齐到最大宽度/高度的整数倍网格上，然后进行 uv 坐标的计算
剩下的，就是在计算顶点信息的时候，用计算好的 uv 坐标，其中 left/right 对应 bitmap 左右两侧的 u 坐标，top/bottom 对应 bitmap 上下两侧的 v 坐标（注意 top 比 bottom 小，因为竖直方向是反的）：
- 3: (xpos , ypos + h, left , top )
- 1: (xpos , ypos , left , bottom)
- 2: (xpos + w, ypos , right, bottom)
- 3: (xpos , ypos + h, left , top )
- 2: (xpos + w, ypos , right, bottom)
- 4: (xpos + w, ypos + h, right, top )

此外，在前面的 shader 代码里，字体颜色用的是 uniform，也就是每次调用只能用同一种颜色。修改的方法，就是把它也变成顶点的属性，从 vertex shader 直接传给 fragment shader，替代 uniform 变量。不过由于 vec4 已经放不下更多的维度了，所以需要另外开一个 attribute：

// vertex shader #version 320 es  in vec4 vertex; // xy is position, zw is its texture coordinates in vec3 textColor; out vec2 texCoors; // output texture coordinates out vec3 fragTextColor; // send to fragment shader void main() {  gl_Position.xy = vertex.xy;  gl_Position.z = 0.0; // we don't care about depth now  gl_Position.w = 1.0; // (x, y, z, w) corresponds to (x/w, y/w, z/w), so we set w = 1.0  texCoords = vertex.zw;  fragTextColor = textColor; }  // fragment shader #version 320 es precision lowp float; in vec2 texCoords; in vec3 fragTextColor; out vec4 color; uniform sampler2D text; void main() {  float alpha = texture(text, texCoords).r;  color = vec4(fragTextColor, alpha); }

背景和光标绘制¶

接下来回到终端模拟器，它除了绘制字符，还需要绘制背景颜色和光标。前面在绘制字符的时候，只把 bounding box 绘制了出来，那么剩下的空白部分是没有绘制的。但是终端里，每一个位置的背景颜色都可能不同，所以还需要给每个位置绘制对应的背景颜色。这里有两种做法：

第一种做法是，把前面每个字符的 bitmap 扩展到终端里一个固定的位置的大小，这样每次绘制的矩形，就是完整的一个位置的区域，这个时候再去绘制背景颜色，就比较容易了：修改 vertex shader 和 fragment shader，在内部进行一次 blend：color = vec4(fragTextColor.rgb * alpha + fragBackgroundColor.rgb * (1.0 - alpha), 1.0)，相当于是丢掉了 OpenGL 的 blend function，自己完成了前景和后景的绘制。

但这个方法有个问题：并非所有的字符的 bitmap 都可以放到一个固定大小的矩形里的。有一些特殊字符，要么长的太高，要么在很下面的位置。后续可能还有更复杂的需求，比如 CJK 和 Emoji，那么字符的宽度又不一样了。所以这个时候导出了第二种做法：

第一轮，先绘制出终端每个位置的背景颜色
第二轮，再绘制出每个位置的字符，和背景进行融合

这时候 shader 没法自己做 blend，所以这考虑怎么用 blend function 来实现这个 blend 的计算。首先，要考虑我们最终需要的结果是：

final.r = textColor.r * alpha + dest.r * (1 - alpha); final.g = textColor.g * alpha + dest.g * (1 - alpha); final.b = textColor.b * alpha + dest.b * (1 - alpha); final.a = 1.0;

由于是 OpenGL 做的 blending，我们需要用 OpenGL 自带的 blending mode 来实现上述公式。OpenGL 可以指定 RGB 的 source 和 dest 的 blending 方式，比如：

GL_ONE：乘以 1 的系数
GL_ONE_MINUS_SRC_ALPHA：乘以 (1 - source.a) 的系数

根据这个，就可以想到，设置 source = vec4(textColor.rgb * alpha, alpha)，设置 source 采用 GL_ONE 方式，dest 采用 GL_ONE_MINUS_SRC_ALPHA 模式，那么 OpenGL 负责剩下的 blending 工作 final = source * 1 + dest * (1 - source.a)（要求 dest.a = 1.0）：

final.r = source.r * 1.0 + dest.r * (1 - source.a) = textColor.r * alpha + dest.r * (1 - alpha); final.g = source.g * 1.0 + dest.g * (1 - source.a) = textColor.g * alpha + dest.g * (1 - alpha); final.b = source.b * 1.0 + dest.b * (1 - source.a) = textColor.b * alpha + dest.b * (1 - alpha); final.a = source.a * 1.0 + dest.a * (1 - source.a) = alpha + 1.0 * (1 - alpha) = 1.0;

正好实现了想要的计算公式。这个方法来自于 Text Rendering - WebRender。有了这个推导后，就可以分两轮，完成终端里前后景的绘制了。

目前 Termony 用的就是这种实现方法：

首先把不同字重的各种字符的 bitmap 拼在一起，放在一个 texture 内部
使用两阶段绘制，第一阶段

注：如果在 source 使用 GL_SRC_ALPHA，设置 source = vec4(textColor.rgb, alpha)，这样 final.r = source.r * source.a + dest.r * (1 - source.a) = textColor.r * alpha + dest.r * (1 - alpha)，结果是上面是一样的，不过这个时候 final 的 alpha 值等于 source.a * source.a + dest.a * (1 - source.a) 是 alpha 和 dest.a 经过 blend 以后的结果，不再是 1.0，如果不用它就无所谓。上面这种 vec4(textColor.rgb * alpha, alpha) 的计算方法，叫做 premultiplied alpha，也就是预先把 alpha 乘到颜色项里，可以方便后续的计算。

在鸿蒙上使用 OpenGL 渲染¶

最后再简单列举一下，在鸿蒙上用 OpenGL 渲染都需要哪些事情：

首先，在 ArkTS 中，插入一个 XComponent，然后在 XComponentController 的回调函数中，通知 native api：

import testNapi from 'libentry.so';  class MyXComponentController extends XComponentController {  onSurfaceCreated(surfaceId: string): void {  hilog.info(DOMAIN, 'testTag', 'onSurfaceCreated surfaceId: %{public}s', surfaceId);  testNapi.createSurface(BigInt(surfaceId));  }   onSurfaceChanged(surfaceId: string, rect: SurfaceRect): void {  hilog.info(DOMAIN, 'testTag', 'onSurfaceChanged surfaceId: %{public}s rect: %{public}s', surfaceId, JSON.stringify(rect));  testNapi.resizeSurface(BigInt(surfaceId), rect.surfaceWidth, rect.surfaceHeight);  }   onSurfaceDestroyed(surfaceId: string): void {  hilog.info(DOMAIN, 'testTag', 'onSurfaceDestroyed surfaceId: %{public}s', surfaceId);  testNapi.destroySurface(BigInt(surfaceId))  } }  @Component struct Index {  xComponentController: XComponentController = new MyXComponentController();   build() {  // ...  XComponent({  type: XComponentType.SURFACE,  controller: this.xComponentController  })  } }

native 部分需要实现至少两个函数：createSurface 和 resizeSurface。其中主要的工作在 CreateSurface 中完成，ResizeSurface 会在窗口大小变化的时候被调用。

CreateSurface 要做的事情：

读取 surface id：

size_t argc = 1; napi_value args[1] = {nullptr}; napi_get_cb_info(env, info, &argc, args, nullptr, nullptr);  int64_t surface_id = 0; bool lossless = true; napi_status res = napi_get_value_bigint_int64(env, args[0], &surface_id, &lossless); assert(res == napi_ok);

创建 OHNativeWindow：

OHNativeWindow *native_window; OH_NativeWindow_CreateNativeWindowFromSurfaceId(surface_id, &native_window); assert(native_window);

创建 EGLDisplay：

EGLNativeWindowType egl_window = (EGLNativeWindowType)native_window; EGLDisplay egl_display = eglGetDisplay(EGL_DEFAULT_DISPLAY); assert(egl_display != EGL_NO_DISPLAY);

初始化 EGL：

EGLint major_version; EGLint minor_version; EGLBoolean egl_res = eglInitialize(egl_display, &major_version, &minor_version); assert(egl_res == EGL_TRUE);

选择 EGL 配置：

const EGLint attrib[] = {EGL_SURFACE_TYPE,  EGL_WINDOW_BIT,  EGL_RENDERABLE_TYPE,  EGL_OPENGL_ES2_BIT,  EGL_RED_SIZE,  8,  EGL_GREEN_SIZE,  8,  EGL_BLUE_SIZE,  8,  EGL_ALPHA_SIZE,  8,  EGL_DEPTH_SIZE,  24,  EGL_STENCIL_SIZE,  8,  EGL_SAMPLE_BUFFERS,  1,  EGL_SAMPLES,  4, // Request 4 samples for multisampling  EGL_NONE};  const EGLint max_config_size = 1; EGLint num_configs; EGLConfig egl_config; egl_res = eglChooseConfig(egl_display, attrib, &egl_config, max_config_size, &num_configs); assert(egl_res == EGL_TRUE);

创建 EGLSurface：

EGLSurface egl_surface = eglCreateWindowSurface(egl_display, egl_config, egl_window, NULL);

创建 EGLContext：

EGLint context_attributes[] = {EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE}; EGLContext egl_context = eglCreateContext(egl_display, egl_config, EGL_NO_CONTEXT, context_attributes);

在当前线程启用 EGL：

eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context);

在这之后就可以用 OpenGL 的各种函数了。OpenGL 绘制完成以后，更新到窗口上：

eglSwapBuffers(egl_display, egl_surface);

在 ResizeSurface 中，主要是更新 glViewport，让它按照新的 surface 大小来绘制。

参考¶

鸿蒙电脑 MateBook Pro 开箱体验

Fri, 06 Jun 2025 00:00:00 +0000

鸿蒙电脑 MateBook Pro 开箱体验¶

购买¶

2025.6.6 号正式开卖，当华为线上商城显示没货的时候，果断去线下门店买了一台回来。购买的是 32GB 内存，1TB SSD 存储，加柔光屏的版本，型号 HAD-W32，原价 9999，国补后 7999。

开箱¶

由于用了国补，需要当面激活，就在店里直接激活了，所以没有体验到鸿蒙系统的扫码激活功能，有点可惜。激活前的第一次开机需要插电，直接按电源键是没有反应的。激活过程也很简单，联网，创建用户，登录华为账号，输入指纹，就可以了。包装盒里还有 140W 单口 Type-C 电源适配器，体积挺小的。此外附赠了一条 Type-C to Type-C 的线，还有一个 Type-C 有线耳机，外加一个 Type-A 母口加 Type-C 公口的线，可以用来接 Type-A 公口的外设。此外还有快速指南和一个超纤抛光布。店家还贴心地提供了一个虚拟机的安装教程。

外形上，就是 MateBook X Pro 加了一个 HarmonyOS 的标识，上手很轻，不愧是不到一公斤的笔记本，对于习惯用 MacBookAir 轻薄本的我来说，是很大的一个亮点。不像 MacBookAir，这台鸿蒙电脑有风扇，有点小小的不习惯，但还算安静。

规格如下：

970g 重量
14.2 寸显示器
3120x2080 分辨率，120 Hz 刷新率
1.8mm 键程键盘
70 Wh 电池

系统体验¶

预装的版本是 HarmonyOS 5.0.1.305，有更新 5.0.1.310 SP9（SP9C00E301R9P2patch02，内核 1.9.5 2025-05-26），首先更新了一下系统。这是我的第一台支持触屏的笔记本，所以用起来还有点新奇。这个柔光屏用起来触感不错，和之前买的柔光屏 MatePad 的触感类似。

底部状态栏的颜色会随着情况变化，比如在桌面的时候，默认壁纸是黑色的，状态栏也就是黑色的。如果打开了设置，设置是白色的，状态栏也就是白色的。之后可以多测试一下它具体的变色逻辑。

系统里预装了 WPS Office，迅雷，亿图，中望 CAD，剪映，好压，抖音等，面向的客户群体很显然了。虽然预装，但都可以卸载。

内置了控制手机屏幕的功能，有略微的不跟手，但由于电脑本身也是触屏，所以体验还是和手机很接近的。下方是经典的三个按钮。这个协同，可以电脑和手机同时操作，还是挺好的，不会说电脑控制了手机，手机就不能用的情况。手机界面左上角会提示协同中。键鼠共享功能不错，可以把手机当屏幕，然后用电脑的键盘和触摸板控制，外接的鼠标也可以。

触摸板手势方面，可以在设置里修改，比如菜单弹出改成双指点按或轻点。触摸板的手感比苹果还是有一定的差距，但是屏幕触摸弥补了这个问题。没有找到三指拖拽的手势，它用的是类似 Windows 的轻点两次，第二次不抬起的做法。

屏幕分辨率 2080 x 3120，14.2 英寸。

2025-06-17 推送了 5.0.1.310 SP9，SP9C00E301R9P2patch05，内核 1.9.5 2025-05-26。

2025-06-24 推送了 5.0.1.315 SP12，SP12C00E302R9P3patch01，内核 1.9.5 2025-06-20。

2025-06-30 推送了 5.0.1.315 SP17，SP17C00E302R9P3，内核 1.9.5 2025-06-24。

应用体验¶

目前（2025 年 6 月 6 日）应用商城有这些软件：

Bilibili
飞书
钉钉
腾讯会议
QQ（在应用尝鲜内）
CodeArts IDE（在应用尝鲜内，需要开发者模式）

暂时还没有微信，可以通过操控手机来发微信，但是在消息栏里按回车是换行，没找到发送按钮对应的电脑按键，需要手动操。但是居然有企业微信。

UPDATE: 2025-06-26 微信正式上架。

UPDATE: 2025-06-13 收到了微信的测试短信，可以体验了，版本是 4.0.1.30。2025-06-14 推送了 4.0.1.31 测试版本。2025-06-19 推送了 4.0.1.32 版本。

支持应用接续，在手机上播放的 B 站视频，可以在电脑上接续继续看。

期待一个功能，当电脑上出现需要扫的二维码的时候，可以通过协同功能，不用操作手机，让手机直接扫电脑的屏幕。不过反过来，如果电脑上有需要输入手机短信验证码的场景，就已经很方便了。

试了一下腾讯会议，声音，视频，共享屏幕都是正常工作的。但是共享的屏幕只有笔记本自己的屏幕，还不能选取共享哪个屏幕的内容，也不能选取共享哪个窗口。

开发者模式¶

开发者模式的打开方式和手机上一样，在设置里狂点软件版本。自带了一个 Terminal App，会提示你如何打开开发者模式。

打开以后就可以访问终端了。shell 是用的 toybox。df 如下：

$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 16G 52K 16G 1% / tmpfs 16G 0 16G 0% /storage/hmdfs /dev/block/dm-4 5.7M 5.7M 0 100% /cust /dev/block/dm-6 3.1G 3.1G 0 100% /preload /dev/block/dm-0 3.0G 3.0G 0 100% /system/variant /dev/block/dm-5 8.0K 8.0K 0 100% /version /dev/block/platform/b0000000.hi_pcie/by-name/userdata 928G 59G 869G 7% /data/service/hnp tmpfs 16G 0 16G 0% /module_update /dev/block/dm-2 9.3G 8.1G 1.1G 88% /sys_prod devfs 15G 104M 15G 1% /dev /data/service/el2/100/hmdfs/non_account 928G 59G 869G 7% /mnt/hmdfs/100/non_account /dev/block/loop0 114M 112M 0 100% /module_update/ArkWebCore tmpfs 1.0G 608K 0.9G 1% /dev/shm

查看 /proc/cpuinfo。四个 0xd42（2.0 GHz），八个 0xd43（2.0 GHz），八个 0xd03（2.3 GHz），共 20 个逻辑核。从 part id 来看，0xd03 和 0xd42 对应麒麟 9010 的大核和中核，但 0xd43 是新的 part id。

使用 https://github.com/jiegec/SPECCPU2017Harmony 性能测试：

X90 P-Core 2.3 GHz 0xd03 Full: INT 4.87 FP 7.42
X90 E-Core 2.0 GHz 0xd43 Full: INT 4.28 FP 6.52
X90 LPE-Core 2.0 GHz 0xd42 Full: INT 3.25 FP TODO
9010 P-Core 2.3 GHz 0xd03 Best: INT 4.18 FP 6.22
9010 P-Core 2.3 GHz 0xd03 Full: INT 3.96 FP 5.86
9010 E-Core 2.2 GHz 0xd42 Full: INT 3.21 FP 4.72

详细数据： https://github.com/jiegec/SPECCPU2017Harmony/tree/master/results。Best 代表每一项单独跑，散热条件好，Full 代表顺着跑一遍，散热条件差。由于编译器和编译选项不同，不能和在其他平台上跑的 SPEC CPU 2017 成绩直接对比，仅供参考。

大概性能排序：X90 P-Core > X90 E-Core > 9010 P-Core > X90 LPE-Core > 9010 E-Core > 9010 LPE-Core。

即使是同样的 2.3 GHz 0xd03 的核，X90 比 9010 快上 20%：可能是散热问题，或者缓存大小和内存带宽的问题，或许连微架构都是不一样的，这些都需要后续进一步测试。而 X90 的中核也比 9010 的大核要快。

CodeArts IDE¶

试了一下从应用商城安装的 CodeArts IDE，显示支持 Java 和 Python 开发，UI 上有点像 JetBrains，但应该是基于 VSCode 做的二次开发。实际测了一下，用它创建 Python 项目后，可以在 CodeArts IDE 的命令行里用 Python3：

$ pwd /storage/Users/currentUser/IDEProjects/pythonProject $ python3 main.py Hello World! $ which python3 /storage/Users/currentUser/IDEProjects/pythonProject/venv/bin/python3o $ /data/app/bin/python --version Python 3.12.5

这里的 /storage/Users/currentUser/ 就是 HOME 目录，对应文件管理器的个人目录。

看了看 /data/app/bin 目录，下面有 git，python，unzip, vi，rg，java（bisheng jdk 8/17），ssh，electron（用来跑 LSP！）等等。

试了试 pip，也是工作的：

(venv) $ python3 -m pip install requests (venv) $ python3 Python 3.12.5 (main, Aug 28 2024, 01:18:17) [Clang 15.0.4 (llvm-project 81cdec3cd117b1e6e3a9f1ebc4695d790c978463)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import requests >>> requests.get("https://github.com").status_code 200 >>>

需要 native 编译的库，比如 numpy 还不行，会提示找不到 make。

终端里的 ssh 是可以用的，实测 ssh 到远程的 linux 上是没问题的。

终端里的括号补全有一些问题，等待修复。CodeArts IDE 的 Python 单步调试功能也是工作的。

似乎没有安装 Remote 开发的插件，也没有安装插件的菜单。

既然可以跑 shell，意味着可以 execve 了，意味着可以做 termux 的类似物了。期待鸿蒙 5 上早日有 Termux 用，直接跑 Linux 发行版。实际测了一下，Popen 确实是工作的。

UPDATE: 开了个坑：https://github.com/jiegec/Termony，目前已经能跑很多命令了，包括在鸿蒙电脑上编译 C/C++ 代码。

试了一下 HOME 目录，发现它里面不能有可执行的文件，所以可能还是得打包到一个 App 里面，通过 /data/app/bin 类似的路径来访问。

在 CodeArts IDE 里，可以访问 /data/storage/el1/bundle 目录，里面有一个 pc_entry.hap 文件，可以通过 cat /data/storage/el1/bundle/pc_entry.hap | ssh hostname "cat - > pc_entry.hap" 拷贝到其他机器上。这个文件有 1.9GB，可以看到在 /data/app 下面的各种文件，其实是来自于这个 pc_entry.hap 的 hnp/arm64-v8a 下面的一系列文件，例如 git.hnp 就是一个 zip 压缩包，里面就是 /data/app/git.org/git_1.2 目录的内容，这个东西叫做 应用包内 Native 包（.hnp）。这些文件在 module.json 里声明，对应 hnpPackages 标签：

{  "module": {  "hnpPackages": [  {  "package": "electron.hnp",  "type": "private"  },  {  "package": "huaweicloud-smartassist-java-ls.hnp",  "type": "private"  },  {  "package": "bishengjdk8.hnp",  "type": "private"  },  {  "package": "rg.hnp",  "type": "private"  },  {  "package": "unzip.hnp",  "type": "private"  },  {  "package": "git.hnp",  "type": "private"  },  {  "package": "bishengjdk17.hnp",  "type": "private"  },  {  "package": "python.hnp",  "type": "private"  }  ],  "name": "pc_entry",  "packageName": "pc_entry"  } }

解压 git.hnp 后，里面的文件会被复制到 /data/app/git.org/git_1.2 目录下，然后有一个 hnp.json 指定了在 /data/app/bin 创建哪些文件的软连接，比如：

{  "install": {  "links": [  {  "source": "bin/expr",  "target": "expr"  },  {  "source": "bin/git",  "target": "git"  }  ]  },  "name": "git",  "type": "hnp-config",  "version": "1.2" }

在 HarmonyOS SDK 里，有一个 hnpcli，可以用来生成 .hnp 文件。

除此之外，就是 VSCode 加各种插件了。

鸿蒙电脑上，可以访问各个 App 的内部目录了，无论是自带的文件浏览器，还是通过 DevEco Studio。这给调试带来了很多便利。

UPDATE: 2025-06-21 推送了 1.0.3 版本。实测在 shell 里面输入括号，不会出现括号补全跑到错误的位置的问题了。

UPDATE: 2025-12-01 尝试 CodeArts 1.0.9 版本，可以创建 C++ 项目了，编译没问题并且有自签名的提示，但是执行编译出来的程序还是会报错，估计还是自签名的机制还有问题。

UPDATE: 2025-12-11 经 @w12101111 群友提醒，在设置->隐私和安全->高级->勾选运行外部来源的扩展程序之后，就可以在 CodeArts IDE 里运行和调试编译出来的 C++ 程序了。至此，鸿蒙电脑自己运行自己编译的 ELF 已经是可行的了。

DevEco Studio¶

2025-12-01 拿到了 DevEco Studio 的内测资格（直接网上申请即可），测试了一下 DevEco Studio 6.0.5.220 鸿蒙预览版。目前能够构建 hap，并且安装在鸿蒙电脑上，通过 USB 连接鸿蒙手机也可以正常安装。

虚拟机¶

目前应用商城有两家虚拟机：Oseasy 和铠大师。两者都是提示安装 ARM64 版本的 Windows，尝试了一下给它一个 Debian 的安装 ISO，它不认。用的 unattended install，不需要进行什么操作。Oseasy 和铠大师的虚拟机不能同时开，但是可以一边安装完，再去安装另一边的 Windows。

试了试在虚拟机里装 WSL，说没有硬件虚拟化，大概是没有打开嵌套虚拟化的功能。

在 6 核 Oseasy 虚拟机里运行 ARM64 Geekbench 6：Single-Core 1436, Multi-Core 5296。Oseasy 8 核：Single-Core 1462, Multi-Core 7043。算上剩下的 12 个逻辑核，考虑虚拟化的开销，多核分数达到网传的 11640 分，感觉是可能的。

Oseasy 虚拟机只允许开到 8 个核心，实测下来，会优先调度到 0xD03 的八个逻辑核中其中四个逻辑核（不同时用一个物理核的两个逻辑核），之后再调度到 0xD43 的八个逻辑核中的四个逻辑核（也不同时用同一个物理核的两个逻辑核）。在 Oseasy 虚拟机里看到的 CPU 信息是 Cortex-A53，没有正确暴露外面的处理器信息，从 cpuinfo 来看，也没有暴露 SVE。

UPDATE: 能跑 Linux 了，见在鸿蒙电脑上的虚拟机内启动 Linux。

外设¶

把 Type-C Hub 接到 MateBook Pro 上，显示器，键盘鼠标都正常工作了。

侧载¶

打开开发者模式后，在设置里，可以打开 USB 调试：把电脑右边的 USB Type-C 接到另一台电脑上，就可以用 hdc 连接了。

然后给自己的项目加上 2in1 的 device type：

diff --git a/entry/build-profile.json5 b/entry/build-profile.json5 index 38bdcc9..ad6fd45 100644 --- a/entry/build-profile.json5 +++ b/entry/build-profile.json5 @@ -30,7 +30,13 @@  ],  "targets": [  { - "name": "default" + "name": "default", + "config": { + "deviceType": [ + "default", + "2in1" + ] + }  },  {  "name": "ohosTest", diff --git a/entry/src/main/module.json5 b/entry/src/main/module.json5 index 7b8532f..76c009c 100644 --- a/entry/src/main/module.json5 +++ b/entry/src/main/module.json5 @@ -5,7 +5,8 @@  "description": "$string:module_desc",  "mainElement": "EntryAbility",  "deviceTypes": [ - "default" + "default", + "2in1"  ],  "requestPermissions": [  {

就可以在鸿蒙电脑上跑了。我编写的两个鸿蒙上的应用：https://github.com/jiegec/SPECCPU2017Harmony 和 https://github.com/jiegec/NetworkToolsHarmony 都能正常在 MateBook Pro 上运行。

测试的过程中，发现用 hdc 传文件到电脑比传手机更快：Pura 70 Pro+ 是 24 MB/s，MateBook Pro 是 31 MB/s。

开源的鸿蒙应用也可以编译 + 运行：

https://gitee.com/smdsbz/moonlight-ohos

目前还没找到怎么让鸿蒙电脑自己调试自己。

卓易通¶

2025-12-15：在应用市场的应用尝鲜里看到了卓易通，目前只能全屏打开 Android 应用。试了一下 Duolinguo，是左右分屏的显示方式，有点类似双折叠手机，左右各一个竖屏。

移植问题¶

ioctl(fd, TCSETS) 会失败，ioctl(fd, TCSETSW) 则成功
libc 缺少一些函数，比如 getspnam，有一些函数不可用，例如 getpwuid
openssl 的 hwcap 检测有问题，可能会导致 sigill
无法访问 /proc/stat

Termony¶

目前通过 https://github.com/jiegec/Termony 运行了一些 benchmark：

$ vkpeak 0 device = Maleoon 916  fp32-scalar = 718.54 GFLOPS fp32-vec4 = 1038.34 GFLOPS  fp16-scalar = 1083.84 GFLOPS fp16-vec4 = 1791.44 GFLOPS fp16-matrix = 0.00 GFLOPS  fp64-scalar = 0.00 GFLOPS fp64-vec4 = 0.00 GFLOPS  int32-scalar = 303.34 GIOPS int32-vec4 = 316.56 GIOPS  int16-scalar = 709.12 GIOPS int16-vec4 = 830.55 GIOPS  int8-dotprod = 0.00 GIOPS int8-matrix = 0.00 GIOPS  bf16-dotprod = 0.00 GFLOPS bf16-matrix = 0.00 GFLOPS

未完待续¶

在 HarmonyOS 5 上运行 Fortran 程序

Fri, 06 Jun 2025 00:00:00 +0000

在 HarmonyOS 5 上运行 Fortran 程序¶

背景¶

前段时间把 SPEC CPU 2017 移植到了鸿蒙 5 上：https://github.com/jiegec/SPECCPU2017Harmony，由于 SPEC CPU 2017 里有不少 Fortran 程序，所以就研究了一下怎么编译 Fortran 代码，最终搞成了，在这里记录一下。

过程¶

HarmonyOS 5 的工具链用的是 LLVM 15，自带的编译器是 clang，那个时候还没有 LLVM flang。但是，经过实际测试，使用新版本的 flang，也是可以的，只是需要做一些额外的操作。例如 flang 有自己的 runtime（类比 libgcc 和 LLVM 的 compiler-rt），需要交叉编译一个 arm64 的版本，下面是仓库中 build-flang.sh 的内容：

#!/bin/sh # build missing libraries for aarch64-linux-ohos target # assume llvm-project is cloned at $HOME/llvm-project set -x -e mkdir -p flang export PATH=~/command-line-tools/sdk/default/openharmony/native/llvm/bin:$PATH DST=$PWD/flang cd $HOME/llvm-project git checkout main # match hash in flang-new-20 --version git reset 7cf14539b644 --hard  cd libunwind rm -rf build mkdir -p build cd build cmake .. -G Ninja \  -DCMAKE_C_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld" \  -DCMAKE_C_COMPILER="clang" \  -DCMAKE_CXX_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld" \  -DCMAKE_CXX_COMPILER="clang++" ninja cp lib/libunwind.a $DST/ cd ../../  cd flang/lib/Decimal rm -rf build mkdir -p build cd build cmake .. -G Ninja \  -DCMAKE_C_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld -fPIC" \  -DCMAKE_C_COMPILER="clang" \  -DCMAKE_CXX_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld -fPIC" \  -DCMAKE_CXX_COMPILER="clang++" ninja cp libFortranDecimal.a $DST/ cd ../../../../  cd flang/runtime rm -rf build mkdir -p build cd build cmake .. -G Ninja \  -DCMAKE_C_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld -fPIC" \  -DCMAKE_C_COMPILER="clang" \  -DCMAKE_CXX_FLAGS="-target aarch64-linux-ohos -fuse-ld=lld -fPIC" \  -DCMAKE_CXX_COMPILER="clang++" ninja cp libFortranRuntime.a $DST/ cd ../../../  ls -al $DST

核心就是以 aarch64-linux-ohos 为 target，编译出三个 .a 文件，之后再链接上就可以了。需要注意的是，runtime 版本和 flang 版本需要一致。为了偷懒，直接用的是 LLVM APT 提供的 flang-new-20 的 binary，那么它是会随着 apt upgrade 而更新的，这个时候就需要重新编译一次 flang runtime，然后链接到程序里。如果版本不对上，可能遇到一些问题：

fatal Fortran runtime error(/home/jiegec/llvm-project/flang/runtime/descriptor.cpp:74): not yet implemented: type category(6)

参考 [flang] fatal Fortran runtime error，就知道是编译器版本和 runtime 不兼容的问题了。

编译好了 fortran runtime 之后，就可以用 flang-new-20 编译 fortran 代码了。这里给出 CMake 的配置方式，主要涉及到需要用的编译选项：

set(CMAKE_Fortran_COMPILER_FORCED TRUE) set(CMAKE_Fortran_COMPILER "flang-new-20") set(CMAKE_Fortran_FLAGS "-target aarch64-linux-ohos -fuse-ld=lld -L ${CMAKE_CURRENT_SOURCE_DIR}/../../../../flang -nostdlib -L ${CMAKE_CURRENT_SOURCE_DIR}/../../../../../command-line-tools/sdk/default/openharmony/native/sysroot/usr/lib/aarch64-linux-ohos -lc -lm -L ${CMAKE_CURRENT_SOURCE_DIR}/../../../../../command-line-tools/sdk/default/openharmony/native/llvm/lib/clang/15.0.4/lib/aarch64-linux-ohos/ -lclang_rt.builtins -lFortranRuntime -lFortranDecimal") enable_language(Fortran)

这里的相对路径，其实就是要找到新编译出来的 flang runtime，以及 HarmonyOS command line tools 里面的一些库，具体路径需要根据实际情况来调整，这里只是一个样例。

到这里，就可以在 HarmonyOS 5 上运行 Fortran 程序了。其实还可以考虑研究一下 GFortran，或许也是能实现的，但目前还没有去做进一步的尝试。

ARM Neoverse N1 (代号 Ares) 的 BTB 结构分析

Thu, 05 Jun 2025 00:00:00 +0000

ARM Neoverse N1 (代号 Ares) 的 BTB 结构分析¶

本文同步发布到本人的知乎。

背景¶

ARM Neoverse N1 是 2019 年发布的比较早的一代 ARM 服务器的处理器，它在很多地方都和 Cortex-A76 类似。它的 BTB 结构比较有意思，所以在这里对它的 BTB 做一些分析。

官方信息¶

首先收集了一些 ARM Neoverse N1 的 BTB 结构的官方信息：

Arm Neoverse N2: Arm’s 2nd generation high performance infrastructure CPUs and system IPs 中对 Neoverse N1 的介绍：
- Branch Prediction Width: 8 instrs
- Nano BTB (0 cyc taken-branch bubble): 16 entry
- Main BTB: 6K entry
The Arm Neoverse N1 Platform: Building Blocks for the Next-Gen Cloud-to-Edge Infrastructure SoC 的介绍：
- 6K entry Main BTB, 3 cycle access latency
- 64-entry Micro BTB
- 16-entry Nano BTB
- 4-way set associative 64KB L1 ICache

简单整理一下官方信息，大概有三级 BTB：

16-entry Nano BTB, 1 cycle latency (0 cycle bubble)
64-entry Micro BTB
6K-entry Main BTB, 3 cycle latency

但是很多细节是缺失的，因此下面结合微架构测试，进一步研究它的内部结构。

微架构测试¶

在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。

stride=4B¶

首先是 stride=4B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB
第二个台阶到 80 条分支，CPI=2，其中 80=16+64，多出来的部分对应了 64-entry 的 Micro BTB，意味着 Micro BTB 相对 Nano BTB 是 Victim BTB 的地位：Nano BTB 被替换出去的 entry 会进入到 Micro BTB，而命中 Micro BTB 的 entry 会被移动到 Nano BTB
第三个台阶到 8192 条分支，CPI=5，大于 Main BTB 的 3 cycle latency，说明此时没有命中 Main BTB，而是要等到取指和译码后，计算出正确的目的地址再回滚，导致了 5 cycle latency；8192 的性能下降原因还需要进一步研究，16384 的性能下降对应了 64KB 的 ICache，因为 4B*16384=64KB

那么 stride=4B 的情况下就遗留了两个问题：为什么没有命中 Main BTB；8192 处为什么出现了性能下降。

stride=8B¶

接下来观察 stride=8B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB，和之前一样
第二个台阶到 80 条分支，CPI=2，其中 80=16+64，多出来的部分对应了 64-entry 的 Micro BTB，和之前一样
第三个台阶到 4096 条分支，CPI=2.75，约等于 Main BTB 的 3 cycle latency，说明此时命中的是 Main BTB，但是它并没有达到宣称的 6144-entry 的 Main BTB 容量；8192 还有一个性能下降，这对应了 64KB 的 ICache：8B*8192=64KB

相比 stride=4B，Nano BTB 和 Micro BTB 的行为没有变化；而 Main BTB 开始能够命中，这代表 Main BTB 在分支特别密集的情况下，会出现性能问题。

那么 stride=8B 的情况下遗留了两个问题：为什么 CPI=2.75 而不是 3？为什么只观察到了 4K 的 Main BTB 容量，而不是 6K？

stride=16B¶

继续观察 stride=16B 的情况：

可以看到，图像上出现了四个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB，和之前一样
第二个台阶到 80 条分支，CPI=2，其中 80=16+64，多出来的部分对应了 64-entry 的 Micro BTB，和之前一样
第三个台阶到 4096 条分支，CPI=2.5，比 Main BTB 的 3 cycle latency 略小，但是大于 2，说明此时命中的是 Main BTB，此时遇到了 64KB ICache 的瓶颈：4096*16B=64KB
第四个台阶到 6144 条分支，CPI=3.5，比 Main BTB 的 3 cycle latency 略大，是因为 64KB ICache 出现了缺失，但这个时候终于显现了宣传的 Main BTB 的 6144 的容量

相比 stride=8B，Nano BTB 和 Micro BTB 的行为没有变化；Main BTB 的 6144 容量开始显现，并且出现地比 64KB ICache 更晚。

那么 stride=16B 的情况下遗留了一个问题：为什么出现了 CPI=2.5 的平台？

stride=32B¶

继续观察 stride=32B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB，和之前一样
第二个台阶到 2048 条分支，CPI=2，此时遇到了 64KB ICache 的瓶颈：2048*32B=64KB，但是这个时候已经超出了 Micro BTB 的容量，而 Main BTB 有 3 cycle 的 latency，为何还能保持 CPI=2 呢
第三个台阶到 6144 条分支，CPI=4，比 Main BTB 的 3 cycle latency 略大，是因为 64KB ICache 出现了缺失，显现的是宣传的 Main BTB 的 6144 的容量，更加说明第二个台阶内 Main BTB 是命中的

那么 stride=32B 的情况下遗留了一个问题：为什么在 Main BTB 的范围内出现了 CPI=2 的平台？

stride=64B¶

继续观察 stride=64B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB，和之前一样
第二个台阶到 1024 条分支，CPI=2，此时遇到了 64KB ICache 的瓶颈：1024*64B=64KB，和之前一样
第三个台阶到 3122 条分支，CPI=6，比 Main BTB 的 3 cycle latency 大，是因为 64KB ICache 出现了缺失，此时 Main BTB 的容量砍半

stride=64B 相比 stride=32B 的 Main BTB 容量砍半，这是组相连的表现：如果 PC[5] 在组相连的 index 当中，那么当 stride=64B 时，PC[5] 恒等于 0，意味着只有一半的 set 可以被用到，那也就只有一半的容量了。

Nano BTB 和 Micro BTB 容量没有变小，意味着它们大概率是全相连的：这也和它们的大小相吻合。

那么 stride=64B 的情况下遗留的问题和 stride=32B 一样：为什么在 Main BTB 的范围内出现了 CPI=2 的平台？

stride=128B¶

继续观察 stride=128B 的情况：

可以看到，图像上出现了三个比较显著的台阶：

第一个台阶到 16 条分支，CPI=1，对应了 16-entry 的 Nano BTB，和之前一样
第二个台阶到 512 条分支，CPI=2，此时遇到了 64KB ICache 的瓶颈：512*128B=64KB，和之前一样
第三个台阶到 1536 条分支，CPI=6.x，比 Main BTB 的 3 cycle latency 大，是因为 64KB ICache 出现了缺失，此时 Main BTB 的容量进一步砍半

stride=128B 相比 stride=64B 的 Main BTB 容量进一步砍半，也是组相连的表现，意味着 PC[6] 也在组相连的 idnex 当中，只有四分之一的 set 可以被用到。

那么 stride=128B 的情况下遗留的问题和 stride=32B 一样：为什么在 Main BTB 的范围内出现了 CPI=2 的平台？

小结¶

测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：

Nano BTB 是 16-entry，1 cycle latency，不随着 stride 变化
Micro BTB 是 64-entry，2 cycle latency，也不随着 stride 变化
Main BTB 是 6K-entry，3 cycle latency，容量随着 stride 变化，大概率是 PC[n:5] 这一段被用于 index，使得 stride=64B 开始容量不断减半
64KB ICache 很多时候会比 Main BTB 更早成为瓶颈

也总结一下前面发现了各种没有解释的遗留问题：

stride=4B 的情况下，Main BTB 没有像预期那样工作：解释见后
stride=4B 的情况下，8192 条分支处出现了性能下降：暂无解释
stride=8B 的情况下，只观察到 4096 的 Main BTB 容量，而不是 6144：解释见后
stride=8B 的情况下，在 Main BTB 命中的范围内，CPI=2.75：解释见后
stride=16B 的情况下，在 Main BTB 命中的范围内，CPI=2.5：解释见后
stride=32B 或 64B 或 128B 的情况下，在 Main BTB 命中的范围内，CPI=2：解释见后

接下来尝试解析一下这些遗留问题背后的原理。部分遗留问题，并没有被解释出来，欢迎读者提出猜想。

解析遗留问题¶

stride=4B 的情况下，Main BTB 没有像预期那样工作¶

对于这种类似 Cache 的结构，当它看起来总是没有命中的时候，其实就是每一个 Set 内要访问的数据超出了 Way，导致每次新访问的都会缺失。上面分析到，Main BTB 的 Index 大概是 PC[n:5] 这一段，那么一个对齐的 32B 范围内，分支指令都会被映射到同一个 set 内。当 stride=4B 的时候，对齐的 32B 范围内有 8 条指令；而 stride=8B 的时候，只有 4 条指令。8 条指令不行，4 条指令可以，暗示了中间跨越了 Way 的数量。

首先来回顾一下 Main BTB 的 6144-entry 是怎么来的：虽然它没说是几路组相连，但因为 6144 有一个 3 的因子，它不是二的幂次，所以一定是在 Way 数量上产生的。这就导致了至少这样几种可能：

3-way set associative, 2048 sets
6-way set associative, 1024 sets
12-way set associative, 512 sets

回顾前面的分析：4 条指令没有超过 Way 数量，8 条指令超过了，那么只能是上述可能里的 6-way set associative，1024 sets 的情况。

翻阅 Arm® Neoverse™ N1 Core Technical Reference Manual，它是这么说的：

L1 BTB data location encoding:

[31:24]: RAMID = 0x02
[23:20]: Reserved
[19:18]: Way
[17:15]: Reserved
[14:5]: Index [14:5]
[4:0]: Reserved

它暗示了 L1 BTB（也就是 Main BTB）的 Index 是 PC[14:5]，这和我们之前的观察一致。这样算出来有 2^(14-5+1)=1024 个 set，和我们前面的 6-way set associative，1024 sets 的猜测是一致的。

但是，这时候又出现一个问题：[19:18] 只能记录两位的 Way 编号，也就是说不能超过 4 个 Way，但实际上有 6 个 Way。这似乎又出现了矛盾。

继续去阅读文档里对从 BTB 读出来的数据的描述：

L1 BTB cache format:

Instruction Register 0 [63:0]: Data [63:0]
Instruction Register 1 [17:0]: Data [81:64]

这暗示了给定一个 Index 和一个 Way，可以读出来 82 bit 的数据，这不太寻常：一个分支的信息，通常不需要这么多 bit 的数据。一个 BTB Entry，通常需要这些信息：

valid
branch type: conditional or unconditional, direct or indirect, call or return, etc.
tag
replacement policy
part of target address

除非保存了完整的 target address 和 tag，是达不到 82 bit 这么多的。但是这样又显得很浪费，可能还有其他的可能性。

考虑到上面出现的两位的 Way 编号，并且有 3 的素数因子，只能是 3-way 组相连了。如果按 3-way 组相连，1024 个 set 来算，只有 3072 个 entry，距离 Main BTB 的容量 6144 个 entry 刚好只有一半。一个想法诞生了：如果一个 BTB entry 可以保存两个分支的信息呢？82 bit 正好是 2 的倍数，除以二是 41 bit，每个分支存 41 bit 的数据是比较合理的数据。这样，就可以推导出来，它 Main BTB 的组织方式是：

Index: PC[14:5]，有 1024 个 set
3-Way 组相连
每个 Entry 是 82 bit，可以记录两条分支的信息

所以 BTB 的 Entry 怎么计算其实会比较复杂，到底是按实际的 Entry 数，还是按分支数，需要深入分析才能理解。

那么，为什么要把两条分支保存在一个 BTB Entry 里呢？Neoverse N1 并没有实现 two taken，似乎并没有放在一起的必要。而且虽然是 3-Way 组相连，匹配的时候还是 6-Way 的，那么这样做的好处是什么呢？

这时候就要提到很多处理器实现的一个优化了：大多数分支，它的目的地址距离它自己是很短的，即使考虑指令支持的最大范围，比如 AArch64 指令里面，B 指令的立即数是 26 位，B.cond 和 CBNZ 的立即数是 19 位，也比完整的虚拟地址空间小很多。针对多数的跳转距离比较短的分支，可以用一个更压缩的表示来保存，使得 BTB 可以保存更多的分支；同时，也保留针对跳转距离比较长的分支的支持。这和前面的这个设计就对上了：对于跳转距离短的分支，每 41 bit 可以保存一条分支的信息；对于跳转距离远的分支，再用 82 bit 来保存一条分支的信息。从另外一个角度来说，41 bit 也确实保存不下完整的虚拟地址，所以需要有一个方案给跳转距离远的分支兜底。

那么如果跳转距离比较远，Main BTB 的容量将会只有一半。感兴趣的读者可以设计实验来验证这一点。

小结：Main BTB 是 1024 set，3 way set associative 的结构，一共 3072 个 entry，每个 entry 可以保存两条分支，Index 是 PC[14:5]。stride=4B 的情况下，会出现一个 set 内 8 条分支的情况，无法在 3 个 entry 内放下，所以总是会出现缺失。一共占用 3072*82=251904 bit 也就是 30.75 KB 的空间。

stride=8B 的情况下，只观察到 4096 的 Main BTB 容量，而不是 6144¶

在 stride=8B 的情况下，只观察到 4096 的 Main BTB 容量，实际上，用刚才分析的 Main BTB 结构，就可以分析出来。

首先，这个测试的构造方法是，给定分支数和 stride，按照这个 stride 在连续的一段虚拟地址上分布这些分支。以 stride=8B 为例，那么分支 i 的地址就是 8*i（实际情况下高位不是 0，但是所有的分支的高位是相同的，例如 0x100000000+8*i，但这不影响分析）。我们来观察一下前几个分支的信息：

Branch 0: addr=0x00, index=0
Branch 1: addr=0x08, index=0
Branch 2: addr=0x10, index=0
Branch 3: addr=0x18, index=0
Branch 4: addr=0x20, index=1

可以看到从分支 5 开始，到了一个新的 set，第一个 set 内出现了 4 条分支，小于一个 set 内可以保存的最多 6 条分支。接下来看从分支 4096 开始的几个分支：

Branch 4096: addr=0x8000, index=0
Branch 4097: addr=0x8008, index=0
Branch 4098: addr=0x8010, index=0
Branch 4099: addr=0x8018, index=0
Branch 4100: addr=0x8020, index=1

可以看到，index=0 这个 set 出现了 8 个 Branch：Branch 0-3 和 Branch 4096-4099，已经大于一个 set 内可以保存的最多 6 条分支。虽然 Main BTB 容量是 6144，但由于分支的排布方式，会首先在一个 set 里出现溢出。然后随着分支继续增加，产生溢出的 set 的比例逐渐上升，直到 8192 条分支的时候，每个 set 都完全溢出了。此时也恰好遇到了 64KB ICache 的瓶颈，如果 ICache 更大，应该会在 8192 的地方观察到一个平台，此时 Main BTB 完全缺失。

继续增加 stride，就没有了这个问题。以 stride=16B 为例子，Branch i 地址是 i*16，那么这些分支的地址是：

Branch 0: addr=0x00, index=0
Branch 1: addr=0x10, index=0
Branch 2: addr=0x20, index=1
Branch 3: addr=0x30, index=1
...
Branch 2048: addr=0x8000, index=0
Branch 2049: addr=0x8010, index=0
Branch 2050: addr=0x8020, index=1
Branch 2051: addr=0x8030, index=1
...
Branch 4096: addr=0x10000, index=0
Branch 4097: addr=0x10010, index=0
Branch 4098: addr=0x10020, index=1
Branch 4099: addr=0x10030, index=1
...
Branch 6144: addr=0x18000, index=0
Branch 6145: addr=0x18010, index=0
Branch 6146: addr=0x18020, index=1
Branch 6147: addr=0x18030, index=1

这个时候，每个 set 会以两个 branch 的粒度来增加，由于 6 是 2 的倍数，所以从 4096 开始，set 逐渐被填满，会等到 6144 条分支才会产生溢出。

小结：由于 Main BTB 的 Index 是 PC[14:5]，所以在 stride=8B 的情况下，每个 set 内以 4 个 branch 的粒度来增加，会有部分 set 已经出现溢出（只能存 6 个分支，但需要存 8 个分支），而另一部分 set 还没有满的情况（能存 6 个分支，但只存了 4 个分支）。这个拐点就是 4096 条分支。

stride=8B 的情况下，在 Main BTB 命中的范围内，CPI=2.75；stride=16B 的情况下，在 Main BTB 命中的范围内，CPI=2.5；stride=32B 或 64B 或 128B 的情况下，在 Main BTB 命中的范围内，CPI=2¶

前面提到，命中 Main BTB 的时候，其实 CPI 并不是 3，而是 2 到 3 之间的一个数，这似乎意味着 Main BTB 并非总是 3 周期提供一个预测。考虑到 Main BTB 容量比较大，很难单周期提供一个预测，猜测 Main BTB 可以两周期或者三周期提供一个预测。那么为什么会在不同的延迟下给出预测结果呢？

首先来分析一下 Main BTB 是如何做预测的：它首先会用传入的 VA 访问 SRAM，得到 3 个 82-bit 的数据，里面最多可以存 6 条分支指令的信息。得到这些数据以后，进行 tag 比较，筛选出其中匹配的部分。如果没有匹配的，或者只有一个匹配的分支，那都好说。但是，如果有多条匹配的分支呢？

例如，这是一个对齐的 32B 块，里面有 8 条 4 字节的指令：

0 4 8 12 16 20 24 28 +-----+-----+-----+-----+-----+-----+-----+-----+ | NOP | NOP | Br | NOP | NOP | NOP | Br | NOP | +-----+-----+-----+-----+-----+-----+-----+-----+

假如要从地址 4 处开始执行，那么 Main BTB 应该要得到的是位于地址 8 的分支的信息；假如要从地址 16 处开始执行，那么 Main BTB 应该要得到的是位于地址 24 的分支的信息。为了实现这个事情，硬件上应该：

首先找到在同一个 32B 块内的所有分支：通过 tag 比对，找到这个 set 内的在该 32B 内的所有分支
接着，找到比输入的 VA 大于或者等于的第一个分支

这个逻辑是比较复杂的，首先要筛选出地址大于或等于输入的 VA 的分支，其次要找到其中 VA 最小的分支。一个思路是保证 BTB 里面的 VA 是排好序的，但是硬件上排序并不好做，而且即使排序了，也需要做类似二分搜索的事情。另一个思路就是不管顺序，用组合逻辑把所有可能性都考虑到，计算出要找的分支。

但是这个组合逻辑比较复杂，本质上就是一个 filter+min 操作，需要比较大的延迟。三个周期能做下来，但是两个周期内，就做不下这么复杂的组合逻辑了。那怎么办呢？

观察一下 CPI 比 3 小的情况：

stride=8B 的 CPI=2.75
stride=16B 的 CPI=2.5
stride=32B 或 64B 或 128B 的 CPI=2

可以看到，随着 stride 增加，CPI 逐渐减少，到 stride=32B 的时候，能够稳定地达到 CPI=2 的情况。设想 Main BTB 有一个 2 周期出结果的 fast path，那么它此时可以稳定地触发；而 stride=16B 只有一半的时候可以触发 fast path：0.5*2+0.5*3=2.5；stride=8B 只有四分之一的时候可以触发 fast path：0.25*2+0.75*3=2.75。这样这些 CPI 都说得通了，其实就是有多大的概率能够触发 fast path。那么 fast path 生效的比例是：

stride=8B 有四分之一的概率走 fast path
stride=16B 有二分之一的概率走 fast path
stride=32B 或 64B 或 128B 一定可以走 fast path

此时你可能已经发现了一些规律：32/4=8，然后 32/2=16。也就是说，当对齐的 32B 块里，有四条分支的时候，平均只有一条分支可以走 fast path；有两条分支的时候，平均也是一条分支可以走 fast path；只有一条分支的时候，它总是可以走 fast path。

再回想一下前面的匹配逻辑：

找到该 32B 块内所有的分支：这一步免不了
找到大于或等于输入 VA 地址的所有分支：这一步也免不了
找到第一个满足要求的分支：如果只有一条分支，那就不用寻找最小值了，这就是 fast path 的条件

这就解释了前面的现象：当 stride=8B 的时候，对齐的 32B 块内部是：

0 4 8 12 16 20 24 28 +-----+-----+-----+-----+-----+-----+-----+-----+ | Br | NOP | Br | NOP | Br | NOP | Br | NOP | +-----+-----+-----+-----+-----+-----+-----+-----+

分支预测的时候，用的地址分别是 0、8、16 和 24。当用 0、8 和 16 的输入 VA 查询的时候，分别能找到 4、3 和 2 条 VA 大于或等于输入 VA 的分支。只有在用 24 的输入 VA 查询的时候，只能找到一条分支，不需要再求 min。

stride=16B 的情况类似，在预测第二条分支的时候，只有一条分支满足要求，可以走 fast path。

stride=32B 或更大的时候，对齐的 32B 块内都只有一条分支，满足走 fast path 的条件。

这就解释了前面看到的各种奇怪的 CPI 现象。

那么，为什么只有 Main BTB 会出现这种现象呢，理论上来说，Nano BTB 和 Micro BTB 也可以做类似的优化？这就涉及到了 BTB 的不同的组织方式：

一种是 Main BTB 这种，每条分支只保存一份，那么为了找到某个 VA 开始的第一条分支，就需要把满足要求的分支都找出来，再寻找地址最小的那一个；具体实现上，也有两种情况：
1. 对于每个可能出现分支指令的地址，都进行一次 BTB 查询（这种结构叫 Instruction BTB）
2. 对于每个对齐的块，记录这个块内的有限条分支的信息（这种结构叫 Region BTB），Main BTB 采用的就是这种，每个对齐的 32B 块内最多保存六条分支
另一种结构，则是直接记录从某个 VA 开始的第一条分支，即给定 VA，查询 BTB 后，匹配到的 entry 里记录的就是从这个 VA 开始的第一条分支（这种结构叫做 Block BTB）；这样一条分支可能会出现在多个 entry 内，此时就不会涉及到上面所述的 fast path 优化

那么猜测 Nano BTB 和 Micro BTB 采用了 Block BTB 的方法，或者因为延迟本身就足够低，即使可以做 fast path，也没有引入 fast path 优化。

详细的 BTB 设计分析，可以参考浅谈乱序执行 CPU（三：前端）的相关内容。

小结：Main BTB 可以在 2 或 3 周期提供预测，其中 2 周期预测的条件是，只找到一条 VA 大于或等于输入 VA 的分支，此时可以跳过求 min 的组合逻辑，在第二个周期给出预测。

模拟¶

既然已经知道了它的 BTB 结构，就写了一段程序来模拟它的工作过程：

// Cortex-A76/Neoverse-N1 BTB model // 16-entry Nano BTB, fully associative, 1 cycle latency. // 64-entry Micro BTB, fully associative, 2 cycle latency. // 3072-entry Main BTB, 3-way set associative, 2-3 cycle latency, each entry at // most 2 branches, index PC[14:5].  #include <assert.h> #include <set> #include <stdint.h> #include <stdio.h> #include <string.h> #include <utility> #include <vector>  struct BTBEntry {  bool valid;  uint64_t pc;  uint64_t target; };  typedef BTBEntry NanoBTBEntry; typedef BTBEntry MicroBTBEntry; typedef BTBEntry MainBTBEntry;  struct Model {  NanoBTBEntry nanoBTB[16];  MicroBTBEntry microBTB[64];  // pretend as 6-way  MainBTBEntry mainBTB[1024][6];  // 64KB ICache, pretend as direct mapped  // index: PC[15:6]  // tag: PC[:16]  uint64_t iCache[64 * 1024 / 64];   // return latency  // use pc to predict a branch at pc, i.e. pva = pc  int match(uint64_t pc, uint64_t target) {  int result = 5; // BTB miss penalty  // Nano BTB at P1  for (int i = 0; i < 16; i++) {  if (nanoBTB[i].pc == pc && nanoBTB[i].target == target) {  // Nano BTB hit  // LRU: move it to head  for (int j = i; j > 0; j--) {  nanoBTB[j] = nanoBTB[j - 1];  }  nanoBTB[0].pc = pc;  nanoBTB[0].target = target;  result = 1;  goto main_btb;  }  }   // Nano BTB miss, check Micro BTB at P1  // like victim cache  for (int i = 0; i < 64; i++) {  if (microBTB[i].pc == pc && microBTB[i].target == target) {  // Micro BTB hit  // Move to Nano BTB  for (int j = i; j > 0; j--) {  microBTB[j] = microBTB[j - 1];  }  microBTB[0].pc = nanoBTB[16 - 1].pc;  microBTB[0].target = nanoBTB[16 - 1].target;   for (int j = 16 - 1; j > 0; j--) {  nanoBTB[j] = nanoBTB[j - 1];  }  nanoBTB[0].pc = pc;  nanoBTB[0].target = target;  result = 2;  goto main_btb;  }  }   // Micro BTB miss  for (int j = 64 - 1; j > 0; j--) {  microBTB[j] = microBTB[j - 1];  }  microBTB[0].pc = nanoBTB[16 - 1].pc;  microBTB[0].target = nanoBTB[16 - 1].target;   for (int j = 16 - 1; j > 0; j--) {  nanoBTB[j] = nanoBTB[j - 1];  }  nanoBTB[0].pc = pc;  nanoBTB[0].target = target;   main_btb:  // check Main BTB  // PC[4:2]  uint64_t offset = pc & 0x1c;  // PC[14:5]  uint64_t index = (pc & 0x7fe0) >> 5;  assert(index < 1024);  // PC[n:15]  uint64_t tag = pc >> 15;  uint64_t min_offset = -1;  int min_i = -1;  int matches = 0;  for (int i = 0; i < 6; i++) {  // find matches  if ((mainBTB[index][i].pc >> 15) == tag && mainBTB[index][i].valid) {  // check offset  if ((mainBTB[index][i].pc & 0x1c) >= offset) {  if (min_i == -1) {  min_i = i;  min_offset = mainBTB[index][i].pc & 0x1c;  } else if ((mainBTB[index][i].pc & 0x1c) < min_offset) {  min_i = i;  min_offset = mainBTB[index][i].pc & 0x1c;  }  matches++;  }  }  }   // hit  if (min_offset == offset) {  if (matches != 0) {  // LRU  MainBTBEntry temp = mainBTB[index][min_i];  for (int i = min_i; i > 0; i--) {  mainBTB[index][i] = mainBTB[index][i - 1];  }  mainBTB[index][0] = temp;  }   if (matches == 1) {  // fast path  if (result == 5) {  result = 2;  goto end;  }  } else if (matches > 1) {  // slow path  if (result == 5) {  result = 3;  goto end;  }  }  }   // miss  for (int i = 6 - 1; i > 0; i--) {  mainBTB[index][i] = mainBTB[index][i - 1];  }  mainBTB[index][0].pc = pc;  mainBTB[index][0].target = target;  mainBTB[index][0].valid = true;   end:  // BTB miss   // compute icache penalty  index = (pc >> 6) % 1024;  tag = pc >> 16;  if (iCache[index] != tag) {  // extra 4 cycle penalty  result += 4;  iCache[index] = tag;  }   return result;  } };  int main() {  FILE *fp = fopen("btb_size.csv", "w");  uint64_t min_size = 2;  uint64_t max_size = 16384;  uint64_t max_product = 1048576;  std::vector<int> mults = {1, 3, 5, 7, 9, 11, 13, 15, 17, 19,  21, 23, 25, 27, 29, 31, 33, 35, 37, 39};   fprintf(fp, "pattern,size,stride,min,avg,max\n");  for (uint64_t stride = 4; stride <= 128; stride *= 2) {  std::set<int> sizes;  for (uint64_t size_base = min_size; size_base <= max_product / stride;  size_base *= 2) {  for (uint64_t mult : mults) {  for (uint64_t size = size_base * mult - 1;  size <= size_base * mult + 1 && size * stride <= max_product &&  size <= max_size;  size++) {  sizes.insert(size);  }  }  }   for (int size : sizes) {  Model model;  memset(&model, 0, sizeof(model));  int cycles = 0;  int branch_count = 1000 * size;  // warmup  for (int i = 0; i < branch_count; i++) {  uint64_t pc = ((i % size) * stride);  uint64_t target = (((i + 1) % size) * stride);  model.match(pc, target);  }   // test  for (int i = 0; i < branch_count; i++) {  uint64_t pc = ((i % size) * stride);  uint64_t target = (((i + 1) % size) * stride);  cycles += model.match(pc, target);  }  float cpi = (float)cycles / branch_count;  fprintf(fp, "0,%d,%d,%.2f,%.2f,%.2f\n", size, stride, cpi, cpi, cpi);  fflush(fp);  }  }  return 0; }

这个模型只评估了 BTB 和 L1 ICache 的性能影响。下面是模拟和实际的对比图，左边是模拟，右边是实际：

stride=4B：

stride=8B：

stride=16B：

stride=32B：

stride=64B：

stride=128B：

可以看到模型和实际的表现是非常一致的。

总结¶

最后总结一下 Neoverse N1 的 BTB：

16-entry Nano BTB, fully associative, 1 cycle latency
64-entry Micro BTB, fully associative, 2 cycle latency, behave as victim BTB of Nano BTB
3072-entry(6144 branches) Main BTB, 3-way(6-branch-way) set associative, 2-3 cycle latency, each entry at most 2 branches, index PC[14:5]

Apple M4 微架构评测

Wed, 21 May 2025 00:00:00 +0000

Apple M4 微架构评测¶

背景¶

最近拿到了 Apple M4 的环境，借此机会测试一下 Apple M4 的微架构，和之前分析的 Apple M1 的微架构做比较。由于 Asahi Linux 尚不支持 Apple M4，所以这里的测试都在 macOS 上进行。

图片来源

使用 Z-Image 生成，提示词： Create a cover iamge for Apple M4 微架构评测, with a proper Apple M4 MacBookAir in the middle with M4 in the background, your text must be accurate

官方信息¶

Apple M4 的官方信息乏善可陈，关于微架构的信息几乎为零，但能从操作系统汇报的硬件信息中找到一些内容。

UPDATE: 后来苹果发布了 Apple Silicon CPU Optimization Guide，算是为数不多的官方信息了。

现有评测¶

网上已经有针对 Apple M4 微架构的评测和分析，建议阅读：

苹果 M4 性能分析：尽力了，但芯片工艺快到头了！

下面分各个模块分别记录官方提供的信息，以及实测的结果。读者可以对照已有的第三方评测理解。官方信息与实测结果一致的数据会加粗。

前端¶

取指带宽¶

P-Core¶

为了测试实际的 Fetch 宽度，参考如何测量真正的取指带宽（I-fetch width） - JamesAslan 构造了测试。

其原理是当 Fetch 要跨页的时候，由于两个相邻页可能映射到不同的物理地址，如果要支持单周期跨页取指，需要查询两次 ITLB，或者 ITLB 需要把相邻两个页的映射存在一起。这个场景一般比较少，处理器很少会针对这种特殊情况做优化，但也不是没有。经过测试，把循环放在两个页的边界上，发现 M4 P-Core 微架构遇到跨页的取指时确实会拆成两个周期来进行。

图中蓝线（cross-page）表示的就是上面所述的第一条指令放一个页，其余指令放第二个页的情况，横坐标是第二个页内的指令数，那么一次循环的指令数等于横坐标 +1。纵坐标是运行很多次循环的总 cycle 数除以循环次数，也就是平均每次循环耗费的周期数。可以看到每 16 条指令会多一个周期，因此 M4 P-Core 的前端取指宽度确实是 16 条指令，和 Apple M1 的 P-Core 是相同的。

随着指令数进一步增加，最终瓶颈在每周期执行的 NOP 指令数，因此两条线重合。

E-Core¶

用相同的方式测试 M4 E-Core，结果如下：

由于两个曲线汇合的点太前（NOP 指令执行得不够快），无法确定 M4 E-Core 的取指宽度，但可以确认的是它每周期取值不少于 10 条指令，比 Apple M1 的 E-Core 要更快。如果读者想到什么办法来确认 M4 E-Core 的取指宽度，欢迎在评论区给出。

测试过程详见测试代码。

L1 ICache¶

官方信息：通过 sysctl 可以看到，P-Core 具有 192KB L1 ICache，E-Core 具有 128KB L1 ICache：

hw.perflevel0.l1icachesize: 196608 hw.perflevel1.l1icachesize: 131072

根据 Apple Silicon CPU Optimization Guide，从 M1 Family 到 M4 Family，A14 Bionic 到 A18 Family，P-Core 的 L1 ICache 的配置都是 192KiB, 6-way, 64B lines；对应处理器的 E-Core 的 L1 ICache 都是 192KiB, 64B lines，其中 M1 Family 和 A14 Bionic 是 8-way，其余处理器（M2 Family 和 A15 Bionic 开始）是 4-way。

延续了从 Apple M1 以来的大小。

P-Core¶

为了测试 L1 ICache 容量，构造一个具有巨大指令 footprint 的循环，由大量的 nop 和最后的分支指令组成。观察在不同 footprint 大小下 M4 P-Core 的 IPC：

可以看到 footprint 在 192 KB 之前时可以达到 10 IPC，之后则快速降到 2.5 IPC，这里的 192 KB 就对应了 M4 P-Core 的 L1 ICache 的容量，和官方信息一致。虽然 Fetch 可以每周期 16 条指令，也就是一条 64B 的缓存行，由于后端的限制，只能观察到 10 的 IPC。

E-Core¶

用相同的方式测试 M4 E-Core，结果如下：

可以看到 footprint 在 128 KB 之前时可以达到 5 IPC，之后则快速降到 2.0 IPC，这里的 128 KB 就对应了 M4 E-Core 的 L1 ICache 的容量，和官方信息一致。

测试过程详见测试代码。

BTB¶

Apple M1 的 BTB 设计相对比较简单：1024 项的组相连 L1 BTB，接着是以 192KB L1 ICache 作为兜底的 3 周期的等效 BTB。但是 M4 上的 BTB 测试图像变化很大，下面进行仔细的分析。

P-Core¶

构造大量的无条件分支指令（B 指令），BTB 需要记录这些指令的目的地址，那么如果分支数量超过了 BTB 的容量，性能会出现明显下降。当把大量 B 指令紧密放置，也就是每 4 字节一条 B 指令时：

可以看到最低的 CPI 能达到接近 0.5（实际值在 0.55），说明 Apple M4 有了一定的每周期执行 2 taken branches 的能力，后面会着重讨论这一点。在经过 CPI 最低点之后，性能出现了先下降后上升再下降的情况，最终在 2048 个分支开始稳定在 2 左右（实际值在 2.10）的 CPI。

这个 2 左右的 CPI 一直稳定维持，一直延续到 49152 个分支。超出 BTB 容量以后，分支预测时，无法从 BTB 中得到哪些指令是分支指令的信息，只能等到取指甚至译码后才能后知后觉地发现这是一条分支指令，这样就出现了性能损失，出现了 2 CPI 的情况。49152 这个拐点，对应的是指令 footprint 超出 L1 ICache 的情况：L1 ICache 是 192KB，按照每 4 字节一个 B 指令计算，最多可以存放 49152 条 B 指令。

这个 2 CPI 的平台在 Apple M1 中是 3 CPI，这是一个巨大的优化，在大多数情况下，通过 L1 ICache 能以每 2 周期一条无条件分支的性能兜底。

接下来降低分支指令的密度，在 B 指令之间插入 NOP 指令，使得每 8 个字节有一条 B 指令，得到如下结果：

图像基本就是 4 字节间距情况下，整体左移的结果，说明各级 BTB 结构大概是组相连，当间距为 8 字节，PC[2] 恒为 0 的时候，只有一半的组可以被用到。

继续降低分支指令的密度，在 B 指令之间插入 NOP 指令，使得每 16 个字节有一条 B 指令，得到如下结果：

每 32 个字节有一条 B 指令：

从间距为 4 字节到间距为 32 字节，整个的图像都是类似的，只是不断在左移。但是当每 64 个字节有一条 B 指令的时候，情况就不同了：

整体的 CPI 有比较明显的下降，最低的 CPI 也在 2 以上，这和 Apple M1 上依然是在 4 字节间距的图像的基础上左移有显著的不同。

前面提到，Apple M4 P-Core 出现了每周期 2 taken branches，但是当分支不在同一个 64B 内的时候，性能会有明显下降；另一方面，以 ARM Neoverse V2 为例，它实现的每周期 2 taken branches，即使分支不在同一个 64B 内，也是可以做到的，下面是在 64B 间距下 ARM Neoverse V2 的测试结果：

根据这些现象，找到了 Apple 的一篇专利 Using a Next Fetch Predictor Circuit with Short Branches and Return Fetch Groups，它提到了一种符合上述现象的实现 2 taken branches 的方法：如果在一个 fetch group（在这里是 64B）内，有一条分支，它的目的地址还在这个 fetch group 内，由于 fetch group 的指令都已经取出来了，所以同一个周期内，可以从这条分支的目的地址开始，继续获取指令。下面是一个例子：

# the beginning of a fetch group nop # the branch b target # some instructions are skipped between branch and its target svc #0 # the branch target resides in the same fetch group target: # some instructions after the branch target add x3, x2, x1 ret

那么在传统的设计里，这段代码会被分成两个周期去取指，第一个周期取 nop 和 b target，第二个周期取 add x3, x2, x1 和 ret；按照这个专利的说法，可以在一个周期内取出所有指令，然后把中间被跳过的 svc #0 指令跳过去，不去执行它。当然了，分支预测器那边也需要做修改，能够去预测第二个分支的目的地址，用于下一个周期。

如果是这种实现方法，是可能在一个 Coupled 前端内，实现这种有限场景的每周期执行 2 taken branches，核心是每周期依然只访问一次 ICache。

E-Core¶

另一方面，M4 E-Core 的 BTB 设计和 Apple M1 的 E-Core 十分接近，当分支间距是 4 字节时：

可以看到 1024 的拐点，1024 之前是 1 IPC，之后增加到 3 IPC。比较奇怪的是，没有看到第二个拐点。

8B 的间距：

拐点前移到 512。

16B 的间距：

第一个拐点前移到 256，第二个拐点出现在 8192，而 M4 E-Core 的 L1 ICache 容量是 128KB，16B 间距下正好可以保存 8192 个分支。

可见 M4 E-Core 的前端设计和 M4 P-Core 有较大的不同。

测试过程详见测试代码。

L1 ITLB¶

官方信息：根据 Apple Silicon CPU Optimization Guide，从 M1 Family 到 M4 Family，A14 Bionic 到 A18 Family，其 P-Core 的 L1 ITLB 配置都是一样的：192 entries，考虑到每个页是 16 KiB，对应 3 MiB 的内存；E-Core 的话，M1 Family 和 A14 Bionic 的 L1 ITLB 是 128 entries，之后的处理器（M2 Family 和 A15 Bionic 开始）则 E-Core 也是 192 entries。

因此，M4 的 P-Core L1 ITLB 是 192 entries，E-Core L1 ITLB 也是 192 entries。

P-Core¶

构造一系列的 B 指令，使得 B 指令分布在不同的 page 上，使得 ITLB 成为瓶颈，在 M4 P-Core 上进行测试：

第一个拐点是由于 L1 BTB 的冲突缺失，之后在 192 个页时从 3 Cycle 快速增加到 12 Cycle，则对应了 192 项的 L1 ITLB 容量，和官方信息一致。这和 M1 P-Core 是一样的。

E-Core¶

在 M4 E-Core 上重复实验：

第一个拐点是由于 L1 BTB 的冲突缺失，之后在 192 个页时从 3 Cycle 快速增加到 10 Cycle，则对应了 192 项的 L1 ITLB 容量，和官方信息一致。相比 M1 E-Core 的 128 项，容量变大了，和 M4 P-Core 看齐。

测试过程详见测试代码。

Decode¶

官方信息：根据 Apple Silicon CPU Optimization Guide，M1 Family 的 Sustained uops Per Cycle 最大值，P-Core 是 8，E-Core 是 4；M2 Family 的 P-Core 不变，E-Core 提升到了 5；M3 Family 的 P-Core 提升到了 9，E-Core 和 M2 持平；M4 Family 的 P-Core 进一步提升到了 10，E-Core 继续和 M2 持平。

从前面的测试来看，M4 P-Core 最大观察到 10 IPC，M4 E-Core 最大观察到 5 IPC，那么 Decode 宽度也至少是这么多，暂时也不能排除有更大的 Decode 宽度，和官方信息一致。相比 M1 的 P-Core 8 IPC，E-Core 4 IPC 都有拓宽。

Return Stack¶

P-Core¶

构造不同深度的调用链，测试每次调用花费的平均时间，在 M4 P-Core 上得到下面的图：

可以看到调用链深度为 60 时性能突然变差，因此 M4 P-Core 的 Return Stack 深度为 60，比 M1 P-Core 的 50 要更大。这里测试的两个 Variant，对应的是 Return 的目的地址不变还是会变化。

E-Core¶

在 M4 E-Core 上测试：

可以看到调用链深度为 40 时性能突然变差，因此 M4 E-Core 的 Return Stack 深度为 40，比 M1 E-Core 的 32 要更大。

测试过程详见测试代码。

后端¶

物理寄存器堆¶

P-Core¶

为了测试物理寄存器堆的大小，一般会用两个依赖链很长的操作放在开头和结尾，中间填入若干个无关的指令，并且用这些指令来耗费物理寄存器堆。M4 P-Core 测试结果见下图：

32b int：测试 speculative 32 位整数寄存器的数量，拐点在 720 左右
64b int：测试 speculative 64 位整数寄存器的数量，拐点在 360 左右，只有 32b 的一半，可见实际的物理寄存器堆有 360 左右个 64 位整数寄存器，但是可以分成两半分别当成 32 位整数寄存器用，这一个优化在 M1 是没有的，即用 32b 或者用 64b 整数，测出来的整数寄存器数量相同
flags：测试 speculative NZCV 寄存器的数量，拐点在 175 左右
32b fp：测试 speculative 32 位浮点寄存器的数量，没有观察到明显的拐点

寄存器堆大小和 M1 P-Core 比较类似，但是多了 32 位整数寄存器的优化。

E-Core¶

在 M4 E-Core 上复现相同的测试，发现性能非常不稳定，不确定是什么原因。

测试过程详见测试代码。

Load Store Unit + L1 DCache¶

L1 DCache 容量¶

官方信息：通过 sysctl 可以看到，M4 P-Core 具有 128KB L1 DCache，M4 E-Core 具有 64KB L1 DCache：

hw.perflevel0.l1dcachesize: 131072 hw.perflevel1.l1dcachesize: 65536

根据 Apple Silicon CPU Optimization Guide，从 M1 Family 到 M4 Family，从 A14 Bionic 到 A18 Family，P-Core 的 L1 DCache 都是 128KiB, 8-way, 64B lines 的配置，E-Core 的 L1 DCache 都是 64KiB, 8-way, 64B lines 的配置。

和 M1 相同。

P-Core¶

构造不同大小 footprint 的 pointer chasing 链，在每个页的开头放一个指针，测试不同 footprint 下每条 load 指令耗费的时间，M4 P-Core 上的结果：

可以看到 128KB 出现了拐点，对应的就是 128KB 的 L1 DCache 容量，和官方信息一致。当 footprint 比较小的时候，由于 Load Address/Value Predictor 的介入，打破了依赖链，所以出现了 latency 小于正常 load to use 的 3 cycle latency 的情况。

E-Core¶

M4 E-Core 上的结果：

可以看到 128KB 出现了明显的拐点，但实际上 M4 E-Core 的 L1 DCache 只有 64KB。猜测这是因为在测试的时候，是在每个 16KB 页的开头放一个指针，但如果 L1 DCache 的 Index 并非都在 16KB 内部，就会导致实际测出来的不是 L1 DCache 的大小。修改测试，使得每 8 字节一个指针，此时测出来的结果就是正确的 64KB 大小：

此时 64KB 对应的就是 64KB 的 L1 DCache 容量，和官方信息一致。L1 DCache 范围内延迟是 3 cycle，之后提升到 14+ cycle。由此可见 M4 E-Core 没有 Load Address/Value Predictor，不能打断依赖链。

测试过程详见测试代码。

L1 DTLB 容量¶

官方信息：根据 Apple Silicon CPU Optimization Guide，对于 P-Core 来说，除了 M2 Family、A14 Bionic 和 A15 Bionic 的 L1 DTLB 是 256 entries 以外，其余的 M1 Family、M3 Family 到 M4 Family，A16 Bionic 到 A18 Family 的 L1 DTLB 都是 160 entries。对于 E-Core 来说，除了 M1 Family 和 A14 Bionic 是 129 entries，其余的从 M2 Family 到 M4 Family，A15 Bionic 到 A18 Family 都是 192 entries。

因此，M4 的 P-Core L1 DTLB 容量是 160，E-Core L1 DTLB 容量是 192。

P-Core¶

用类似的方法测试 L1 DTLB 容量，只不过这次 pointer chasing 链的指针分布在不同的 page 的不同 cache line 上，使得 DTLB 成为瓶颈，在 M4 P-Core 上：

从 160 个页开始性能下降，到 200 个页时性能稳定在 9 CPI，认为 M4 P-Core 的 L1 DTLB 有 160 项，大小和 M1 P-Core 相同，和官方信息一致。9 CPI 包括了 L1 DTLB miss L2 TLB hit 带来的额外延迟。中间有时性能特别快，是 Load Address/Value Predictor 的功劳。

E-Core¶

M4 E-Core 测试结果：

从 192 个页开始性能下降，到 224 个页时性能稳定在 9 CPI，认为 M4 E-Core 的 L1 DTLB 有 192 项，和官方信息一致，比 M1 E-Core 的 128 项更大，甚至大过了 P-Core。9 CPI 包括了 L1 DTLB miss L2 TLB hit 带来的额外延迟，比 M1 E-Core 少了一个周期。

测试过程详见测试代码。

Load/Store 带宽¶

P-Core¶

针对 Load Store 带宽，实测 M4 P-Core 每个周期可以完成：

3x 128b Load + 1x 128b Store
2x 128b Load + 2x 128b Store
1x 128b Load + 2x 128b Store
2x 128b Store

如果把每条指令的访存位宽从 128b 改成 256b，读写带宽不变，指令吞吐减半。也就是说最大的读带宽是 48B/cyc，最大的写带宽是 32B/cyc，二者不能同时达到。和 M1 P-Core 相同。

E-Core¶

实测 M4 E-Core 每个周期可以完成：

2x 128b Load
1x 128b Load + 1x 128b Store
1x 128b Store

如果把每条指令的访存位宽从 128b 改成 256b，读写带宽不变，指令吞吐减半。也就是说最大的读带宽是 32B/cyc，最大的写带宽是 16B/cyc，二者不能同时达到。和 M1 E-Core 相同。

Memory Dependency Predictor¶

为了预测执行 Load，需要保证 Load 和之前的 Store 访问的内存没有 Overlap，那么就需要有一个预测器来预测 Load 和 Store 之前在内存上的依赖。参考 Store-to-Load Forwarding and Memory Disambiguation in x86 Processors 的方法，构造两个指令模式，分别在地址和数据上有依赖：

数据依赖，地址无依赖：str x3, [x1] 和 ldr x3, [x2]
地址依赖，数据无依赖：str x2, [x1] 和 ldr x1, [x2]

初始化时，x1 和 x2 指向同一个地址，重复如上的指令模式，观察到多少条 ldr 指令时会出现性能下降。

P-Core¶

在 M4 P-Core 上测试：

数据依赖没有明显的阈值，但从 72 开始出现了一个小的增长，且斜率不为零；地址依赖的阈值是 39。相比 M1 P-Core 有所减小。

E-Core¶

M4 E-Core:

数据依赖的阈值是 20，地址依赖的阈值是 14。比 M1 E-Core 略大。

Store to Load Forwarding¶

P-Core¶

经过实际测试，M4 P-Core 上如下的情况可以成功转发，对地址 x 的 Store 转发到对地址 y 的 Load 成功时 y-x 的取值范围：

Store\Load	8b Load	16b Load	32b Load	64b Load
8b Store	{0}	[-1,0]	[-3,0]	[-7,0]
16b Store	[0,1]	[-1,1]	[-3,1]	[-7,1]
32b Store	[0,3]	[-1,3]	[-3,3]	[-7,3]
64b Store	[0,7]	[-1,7]	[-3,7]	[-7,7]

从上表可以看到，所有 Store 和 Load Overlap 的情况，无论地址偏移，都能成功转发。甚至在 Load 或 Store 跨越 64B 缓存行边界时，也可以成功转发，代价是多一个周期。

一个 Load 需要转发两个、四个甚至八个 Store 的数据时，也可以成功转发。即使数据跨越缓存行，也可以转发，只是多耗费 1-2 个周期。但在跨 64B 缓存行的时候，代价可能多于一个周期。相比 M1 P-Core，M4 P-Core 在跨越缓存行的情况下也可以得到比较好的性能。

成功转发时 7 cycle 左右。

小结：Apple M4 P-Core 的 Store to Load Forwarding：

1 ld + 1 st: 支持
1 ld + 2 st: 支持
1 ld + 4 st: 支持
1 ld + 8 st: 支持
跨 64B 缓存行边界时，性能略微下降

E-Core¶

在 M4 E-Core 上，如果 Load 和 Store 访问范围出现重叠，当需要转发一个到两个 Store 的数据时，需要 7 Cycle，无论是否跨缓存行。如果需要转发四个 Store 的数据，则需要 8 Cycle；转发八个 Store 的数据需要 11 Cycle。相比 M1 E-Core，多数情况下获得了性能提升。

Load to use latency¶

官方信息：根据 Apple Silicon CPU Optimization Guide，Apple 实现了 fast pointer chasing with a 3-cycle latency，要求后一个 load 的 base register 和前一个 load 的 destination register 相同。

P-Core¶

实测 M4 P-Core 的 Load to use latency 针对 pointer chasing 场景做了优化，在下列的场景下可以达到 3 cycle:

ldr x0, [x0]: load 结果转发到基地址，无偏移
ldr x0, [x0, 8]：load 结果转发到基地址，有立即数偏移
ldr x0, [x0, x1]：load 结果转发到基地址，有寄存器偏移
ldp x0, x1, [x0]：load pair 的第一个目的寄存器转发到基地址，无偏移

如果访存跨越了 8B 边界，则退化到 4 cycle。

在下列场景下 Load to use latency 则是 4 cycle：

load 的目的寄存器作为 alu 的源寄存器（下称 load to alu latency）
ldr x0, [sp, x0, lsl #3]：load 结果转发到 index
ldp x1, x0, [x0]：load pair 的第二个目的寄存器转发到基地址，无偏移

注意由于 Load Address/Value Predictor 的存在，测试的时候需要排除预测器带来的影响。延迟方面，和 M1 P-Core 相同。

E-Core¶

实测 M4 E-Core 的 Load to use latency 针对 pointer chasing 场景做了优化，在下列的场景下可以达到 3 cycle:

ldr x0, [x0]: load 结果转发到基地址，无偏移
ldr x0, [x0, 8]：load 结果转发到基地址，有立即数偏移
ldr x0, [x0, x1]：load 结果转发到基地址，有寄存器偏移
ldp x0, x1, [x0]：load pair 的第一个目的寄存器转发到基地址，无偏移

如果访存跨越了 8B/16B/32B 边界，依然是 3 cycle；跨越了 64B 边界则退化到 7 cycle。

在下列场景下 Load to use latency 则是 4 cycle：

load 的目的寄存器作为 alu 的源寄存器（下称 load to alu latency）
ldr x0, [sp, x0, lsl #3]：load 结果转发到 index
ldp x1, x0, [x0]：load pair 的第二个目的寄存器转发到基地址，无偏移

延迟方面，和 M1 E-Core 相同。

Virtual Address UTag/Way-Predictor¶

Linear Address UTag/Way-Predictor 是 AMD 的叫法，但使用相同的测试方法，也可以在 Apple M1 上观察到类似的现象，猜想它也用了类似的基于虚拟地址的 UTag/Way Predictor 方案，并测出来它的 UTag 也有 8 bit，M4 P-Core 和 M4 E-Core 都是相同的：

VA[14] xor VA[22] xor VA[30] xor VA[38] xor VA[46]
VA[15] xor VA[23] xor VA[31] xor VA[39] xor VA[47]
VA[16] xor VA[24] xor VA[32] xor VA[40]
VA[17] xor VA[25] xor VA[33] xor VA[41]
VA[18] xor VA[26] xor VA[34] xor VA[42]
VA[19] xor VA[27] xor VA[35] xor VA[43]
VA[20] xor VA[28] xor VA[36] xor VA[44]
VA[21] xor VA[29] xor VA[37] xor VA[45]

一共有 8 bit，由 VA[47:14] 折叠而来。和 Apple M1 相同。

Load Address/Value Predictor¶

Apple 从 M2 开始引入 Load Address Predictor，从 M3 开始引入 Load Value Predictor，相关的信息如下：

Load Address Predictor：支持 Constant 和 Striding Address 两种模式，专利是 Early load execution via constant address and stride prediction
Load Value Predictor（也称 Load Output Predictor）：只支持 Constant Value，专利是 Shared learning table for load value prediction and load address prediction

这两个 Predictor 会对已有的基于 Load 的各种 microbenchmark 带来深刻的影响。

网上已有针对这两个 Predictor 的逆向和攻击：SLAP: Data Speculation Attacks via Load Address Prediction on Apple Silicon;FLOP Breaking the Apple M3 CPU via False Load Output Predictions。

苹果还有一个后续的专利：Managing table accesses for tagged geometric length (TAGE) load value prediction，暗示了苹果可能会使用 VTAGE 算法来实现 load value prediction，只是不知道会不会实装，会在哪代处理器上实装，是不是已经实装在已经发布的处理器上了。

P-Core¶

构造依赖链，但是实际测试可以观察到打破依赖链的情况，比串行执行要更快。测试下来，大概可以跟踪 60 条 Load 指令的地址并实现预测。

E-Core¶

M4 E-Core 没有实现 Load Address/Value Predictor。

执行单元¶

官方信息：根据 Apple Silicon CPU Optimization Guide，M4 Family 的 P-Core 包括如下计算单元：

ALU/f, BRc/i
ALU/f, BRc
ALU/f
ALU/f, PRED/f
ALU, MUL, MISC
ALU, DIV
ALU, MUL
ALU, MUL
GENERAL, MOVE2GPR, FCMPf, FCSELf, FDIV, MUL, SHA
GENERAL, MOVE2GPR, FCSELf, MUL
GENERAL, MUL
GENERAL, MUL

从 M3 开始，P-Core 整数计算单元从 6 个增加到 8 个。浮点部分没有变化。

P-Core 访存：

Burst: 3 load uops, 2 store uops (address part), and 2 store uops (data part)
- 即 3 load, 2 sta, 2 std
Sustained: 4 uops, 2 write into the cache

和 M1 E-Core 相同。

M4 Family 的 E-Core 包括如下计算单元：

ALU/f, MUL, MAC, MISC, PRED/f
ALU/F, BRi, DIV
ALU/f, BRc
ALU/f
GENERAL, MOVE2GPR, FCMPf, FCSELf, FDIV, MUL, SHA
GENERAL, MOVE2GPR, FCMPf, FCSELf, MUL
GENERAL

从 M3 开始，E-Core 整数计算单元从 3 个增加到 4 个。从 M3 Max/M4 Family 开始，E-Core 浮点单元从 2 个增加到 3 个。注意 M3/M3 Pro 的 E-Core 依然是 2 个浮点单元。

E-Core 访存：

Burst: 3 load uops, 2 store uops (address part), and 2 store uops (data part)
- 即 3 load, 2 sta, 2 std
Sustained: 4 uops, 2 write into the cache

和 M1 E-Core 相同。

P-Core¶

在 M4 P-Core 上测试如下各类指令的延迟和每周期吞吐：

Instruction	Latency	Throughput
asimd int add	2	4
asimd aesd/aese	2/3	4
asimd aesimc/aesmc	2	4
asimd fabs	2	4
asimd fadd	3	4
asimd fdiv 64b	10	1
asimd fdiv 32b	8	1
asimd fmax	2	4
asimd fmin	2	4
asimd fmla	3	4
asimd fmul	3	4
asimd fneg	2	4
asimd frecpe	3	1
asimd frsqrte	3	1
asimd fsqrt 64b	13	0.5
asimd fsqrt 32b	10	0.5
fp cvtf2i (fcvtzs)	-	2
fp cvti2f (scvtf)	-	3
fp fabs	2	4
fp fadd	2	4
fp fdiv 64b	10	1
fp fdiv 32b	8	1
fp fjcvtzs	-	1
fp fmax	2	4
fp fmin	2	4
fp fmov f2i	-	2
fp fmov i2f	-	3
fp fmul	4	4
fp fneg	2	4
fp frecpe	3	1
fp frecpx	3	1
fp frsqrte	3	1
fp fsqrt 64b	13	0.5
fp fsqrt 32b	10	0.5
int add	1	7.5
int addi	1	8
int bfm	1	1
int crc	3	1
int csel	1	4
int madd (addend)	1	2.8
int madd (others)	4	2.8
int mrs nzcv	-	2
int mul	3	3
int nop	-	10
int sbfm	1	8
int sdiv	7	0.5
int smull	3	3
int ubfm	1	8
int udiv	7	0.5
not taken branch	-	2
taken branch	-	1-2
mem asimd load	-	3
mem asimd store	-	2
mem int load	-	3
mem int store	-	2

从上面的结果可以初步得到的信息：

标量浮点和 ASIMD 吞吐最大都是 4，意味着有 4 个浮点/ASIMD 执行单元，但并非完全对称，例如 fdiv/frecpe/frecpx/frsqrte/fsqrt/fjcvtzs 由于吞吐不超过 1，大概率只能在一个执行单元内执行。但这些指令是不是都只能在同一个执行单元内执行，还需要进一步的测试；这部分和 M1 P-Core 相同，但浮点乘法 fmla/fmul 的延迟从 4 周期降低到了 3 周期
浮点和整数之间的 move 或 convert 指令，fmov i2f/cvti2f 吞吐是 3，fmov f2i/cvtf2i 吞吐是 2，那么这些指令是在哪个执行单元里实现的，是否需要同时占用整数执行单元和浮点执行单元，需要进一步测试；这部分和 M1 P-Core 相同
整数方面，根据吞吐，推断出如下几类指令对应的执行单元数量：
1. ALU: 8
2. CSEL: 4
3. Mul/MAdd: 3
4. Br/MRS NZCV: 2
5. CRC/BFM/Div: 1
6. ALU/CSEL/Mul/MAdd 的执行单元相比 M1 P-Core 有扩充
访存方面，每周期最多 3 Load 或者 2 Store；这部分和 M1 P-Core 相同

首先来看浮点和 ASIMD 单元，根据上面的信息，认为至少有 4 个执行单元，每个执行单元都可以做这些操作：asimd int add/aes/fabs/fadd/fmax/fmin/fmla/fmul/fneg，下面把这些指令称为 basic fp/asimd ops + aes。接下来要判断，fmov f2i/fmov i2f/fdiv/frecpe/frecpx/frsqrte/fsqrt 由哪些执行单元负责执行，方法是把这些指令混合起来测试吞吐（此处的吞吐不代表 CPI，而是每周能够执行多少次指令组合，例如用 2 条指令的组合测试，那么吞吐等于 CPI 除以 2）：

指令	吞吐
fp fdiv + fp frecpe	0.5
fp fdiv + fp frecpx	0.5
fp fdiv + fp frsqrte	0.5
fp fdiv + fp fsqrt	0.33=1/3
fp fdiv + fmov f2i	0.5
fp fdiv + 2x fmov f2i	0.33=1/3
fp fdiv + 3x fmov i2f	1
fp fdiv + 4x fmov i2f	0.75=1/1.33
fmov i2f + 4x fp fadd	1
fmov f2i + 4x fp fadd	0.75=1/1.33

根据以上测试结果，可以得到如下的推论：

fp fdiv/frecpe/frecpx/frsqrte 混合的时候，吞吐只有一半，IPC 不变，说明这些指令在同一个执行单元中，混合并不能带来更高的 IPC；这部分和 M1 P-Core 相同
fp fdiv 和 fp fsqrt 混合时，吞吐下降到 0.33 一个不太整的数字，猜测是因为它们属于同一个执行单元内的不同流水线，抢占寄存器堆写口；这部分和 M1 P-Core 相同
fp fdiv + fmov f2i 的时候吞吐是 0.5，而 fdiv + 2x fmov f2i 时吞吐下降到 0.33，IPC 维持在 1，说明有 1 个执行单元执行 fdiv 或 fmov f2i，但奇怪的是单独执行 fmov f2i 可以达到 2 的 IPC；这部分吞吐比 M1 P-Core 要差
fp fdiv + 3x fmov i2f 的时候吞吐是 1，而 fdiv + 4x fmov i2f 时吞吐下降到 0.75，此时每周期还是执行 3 条 fmov i2f 指令，意味着 fdiv 没有抢占 fmov i2f 的执行单元，它们用的执行单元是独立的；这部分和 M1 P-Core 相同
fmov i2f + 4x fp fadd 的时候吞吐是 1，说明 fmov i2f 没有抢占 fp fadd 的执行单元；这部分和 M1 P-Core 相同

推断这四个执行单元支持的操作：

basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt + fmov f2i + cvtf2i
basic fp/asimd ops + aes + fmov f2i + cvtf2i
basic fp/asimd ops + aes
basic fp/asimd ops + aes

当然还有很多指令没有测，不过原理是一样的。这部分和 M1 P-Core 相同。

访存部分，前面已经在测 LSU 的时候测过了，每周期 Load + Store 不超过 4 个，其中 Load 不超过 3 个，Store 不超过 2 个。虽然从 IPC 的角度来看 LSU 的 Load/Store Pipe 未必准确，比如可能它发射和提交的带宽是不同的，但先暂时简化为如下的执行单元：

load + store
load
load
store

这部分和 M1 P-Core 相同。

最后是整数部分。从 addi 的指令来看，有 8 个 ALU，能够执行基本的整数指令。但其他很多指令可能只有一部分执行单元可以执行：bfm/crc/csel/madd/mrs nzcv/mul/div/branch/fmov i2f。为了测试这些指令使用的执行单元是否重合，进行一系列的混合指令测试，吞吐的定义和上面相同：

指令	吞吐
4x int csel + 3x fmov i2f	1
int csel + 2x fmov f2i	1
2x int csel + 2x fmov f2i	0.80=1/1.25
3x int csel + int bfm	1
4x int csel + int bfm	0.80=1/1.25
4x int csel + int crc	1
3x int csel + int madd	1.33=1/0.75
4x int csel + int madd	1
4x int csel + 2x int madd	1
4x int csel + 3x int madd	0.75=1/1.33
4x int csel + int mul	1
3x int csel + int sdiv	0.5
4x int csel + int sdiv	0.45=1/2.23
3x int csel + mrs nzcv	1
4x int csel + mrs nzcv	0.80=1/1.25
3x int csel + not taken branch	1
4x int csel + not taken branch	0.80=1/1.25
mrs nzcv + not taken branch	1
mrs nzcv + 2x not taken branch	0.67=1/1.50
2x fmov f2i + 2x not taken branch	1
2x fmov f2i + 2x int mul	1
2x int madd + int crc	1
3x int madd + int crc	0.75=1/1.33
2x int madd + int mul	1
3x int madd + int mul	0.75
2x int madd + int sdiv	0.5
3x int madd + int sdiv	0.5
3x int madd + mrs nzcv	1

根据上述结果分析：

吞吐与不混合时相同，代表混合的指令对应的执行单元不重合
2x int madd + int mul 的 IPC 是 3，3x int add + int mul 的 IPC 也是 3，说明有三个执行单元可以执行 madd 和 mul：
1. alu + madd + mul
2. alu + madd + mul
3. alu + madd + mul
2x int madd + int crc 的 IPC 是 3，3x int madd + int crc 的 IPC 也是 3，说明其中一个执行单元可以执行 crc：
1. alu + madd + mul + crc
2. alu + madd + mul
3. alu + madd + mul
4x int csel + 2x int madd 的吞吐是 1，4x int csel + 3x int madd 的吞吐是 0.75，说明它们有一个重合的执行单元，并且由于 4x int csel + int crc 的吞吐是 1，所以重合的执行单元不是 crc 的那一个：
1. alu + madd + mul + crc
2. alu + madd + mul + csel
3. alu + madd + mul
4. alu + csel
5. alu + csel
6. alu + csel
4x int csel + mrs nzcv 的 IPC 等于 4，说明 mrs nzcv 的执行单元被包括在能执行 csel 的四个执行单元当中；而 3x int madd + mrs nzcv 的吞吐等于 1，说明 mrs nzcv 的执行单元和 int madd 不重合：
1. alu + madd + mul + crc
2. alu + madd + mul + csel
3. alu + madd + mul
4. alu + csel + mrs nzcv
5. alu + csel + mrs nzcv
6. alu + csel
因为 mrs nzcv + 2x not taken branch 的吞吐是 0.67，此时 IPC 等于 2，说明它们的执行单元重合：
1. alu + madd + mul + crc
2. alu + madd + mul + csel
3. alu + madd + mul
4. alu + csel + mrs nzcv + branch
5. alu + csel + mrs nzcv + branch
6. alu + csel

得到初步的结果：

alu + madd + mul + crc
alu + madd + mul + csel
alu + madd + mul
alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + branch
alu + csel
alu
alu

还有很多其他的指令没有测试，不过方法是类似的。从上面的结果里，可以看到一些值得一提的点：

fmov f2i 同时占用了浮点执行单元和整数执行单元，这主要是为了复用寄存器堆读写口：fmov f2i 需要读浮点寄存器堆，又需要写整数寄存器堆，那就在浮点侧读寄存器，在整数侧写寄存器。
fmov i2f 既不在浮点，也不在整数，那只能在访存了：而正好访存执行单元需要读整数，写整数或浮点，那就可以复用它的寄存器堆写口来实现 fmov i2f 的功能。
可见整数/浮点/访存执行单元并不是完全隔离的，例如一些微架构，整数和浮点是直接放在一起的。

小结：M4 P-Core 的执行单元如下：

alu + madd + mul + crc
alu + madd + mul + csel
alu + madd + mul
alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + branch
alu + csel
alu
alu
load + store
load
load
store
basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt + fmov f2i + cvtf2i
basic fp/asimd ops + aes + fmov f2i + cvtf2i
basic fp/asimd ops + aes
basic fp/asimd ops + aes

相比 M1 P-Core，只在整数方面有扩充。和官方的信息，除了 store data/address 部分没有探测出来以外都一致。

E-Core¶

接下来用类似的方法测试 M4 E-Core：

Instruction	Latency	Throughput
asimd int add	2	3
asimd aesd/aese	2.5/3	3
asimd aesimc/aesmc	2	3
asimd fabs	2	3
asimd fadd	2.5	3
asimd fdiv 64b	11	0.5
asimd fdiv 32b	9	0.5
asimd fmax	2	3
asimd fmin	2	3
asimd fmla	4	2
asimd fmul	4	2
asimd fneg	2	3
asimd frecpe	4	0.5
asimd frsqrte	4	0.5
asimd fsqrt 64b	15	0.5
asimd fsqrt 32b	12	0.5
fp cvtf2i (fcvtzs)	-	2
fp cvti2f (scvtf)	-	1.5
fp fabs	2	3
fp fadd	2.5	3
fp fdiv 64b	10	1
fp fdiv 32b	8	1
fp fjcvtzs	-	2
fp fmax	2	3
fp fmin	2	3
fp fmov f2i	-	2
fp fmov i2f	-	2
fp fmul	4	2
fp fneg	2	3
fp frecpe	3	1
fp frecpx	3	1
fp frsqrte	3	1
fp fsqrt 64b	13	0.5
fp fsqrt 32b	10	0.5
int add	1	4
int addi	1	3
int bfm	1	1
int crc	3	1
int csel	1	3
int madd (addend)	1	1
int madd (others)	3	1
int mrs nzcv	-	3
int mul	3	1
int nop	-	5
int sbfm	1	3
int sdiv	7	0.125=1/8
int smull	3	1
int ubfm	1	3
int udiv	7	0.125=1/8
not taken branch	-	2
taken branch	-	1
mem asimd load	-	2
mem asimd store	-	1
mem int load	-	2
mem int store	-	1

从上面的结果可以初步得到的信息：

标量浮点和 ASIMD 吞吐最大都是 3，意味着有 3 个浮点/ASIMD 执行单元，但并非完全对称，例如 fdiv/frecpe/frecpx/frsqrte/fsqrt 由于吞吐不超过 1，大概率只能在一个执行单元内执行；fmla/fmul 的吞吐只有 2，只能在其中两个执行单元内执行。但这些指令是不是都只能在同一个执行单元内执行，还需要进一步的测试；相比 M1 E-Core，添加了一个浮点/ASIMD 执行单元
整数方面，根据吞吐，推断出如下几类指令对应的执行单元数量：
1. ALU: 4
2. CSEL/MRS NZCV/SBFM/UBFM: 3
3. Br: 2
4. Mul/CRC/BFM/MAdd/Div: 1
5. 相比 M1 E-Core 增加了 ALU 的数量
虽然 Br 的吞吐可以达到 2，但是每周期只能有一个 taken branch，和 M1 E-Core 相同
访存方面，每周期最多 2 Load 或者 1 Store，和 M1 E-Core 相同

还是先看浮点，基本指令 add/aes/fabs/fadd/fmax/fmin/fneg 都能做到 3 的吞吐，也就是这三个执行单元都能执行这些基本指令。接下来测其余指令的混合吞吐（吞吐定义见上）：

指令	吞吐
fp fdiv + fp frecpe	0.5
fp fdiv + fp frecpx	0.5
fp fdiv + fp frsqrte	0.5
fp fdiv + fp fsqrt	0.31=1/3.25
fp fdiv + fmov f2i	0.5
fp fdiv + 2x fmov f2i	0.66=1/1.50
fp fdiv + 2x fmov i2f	1
fp fdiv + 3x fmov i2f	0.67=1/1.50
fp fdiv + fp fmul	1
fp fdiv + 2x fp fmul	0.6
fp fmul + fmov f2i	1
2x fp fmul + fmov f2i	0.67=1/1.50

可见 fdiv/frecpe/frecpx/frsqrte/fsqrt 都在同一个执行单元内：

basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt
basic fp/asimd ops + aes
basic fp/asimd ops + aes

由于 fp fdiv + 2x fmov f2i 的 IPC 是 2，说明它们有重合的执行单元：

basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt + fmov f2i
basic fp/asimd ops + aes + fmov f2i
basic fp/asimd ops + aes

因为 2x fp fmul + fmov f2i 的 IPC 也只有 2，说明 fp fmul 和 fmov f2i 是重合的：

basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt + fmov f2i + fmul
basic fp/asimd ops + aes + fmov f2i + fmul
basic fp/asimd ops + aes

还有很多指令没有测，不过原理是一样的。访存在前面测 LSU 的时候已经测过了：

load + store
load

最后是整数部分。从 add 的指令来看，有 4 个 ALU，能够执行基本的整数指令。但其他很多指令可能只有一部分执行单元可以执行：bfm/crc/csel/madd/mul/div/branch。为了测试这些指令使用的执行单元是否重合，进行一系列的混合指令测试，吞吐的定义和上面相同：

指令	吞吐
int madd + int mul	0.5
int madd + int crc	0.5
int madd + 2x not taken branch	1

由此可见，madd/mul/crc 是一个执行单元，和 branch 的两个执行单元不重合，因此整数侧的执行单元有：

alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + madd + mul + crc
alu

小结：M4 E-Core 的执行单元如下：

alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + branch
alu + csel + mrs nzcv + madd + mul + crc
alu
load + store
load
basic fp/asimd ops + aes + fdiv + frecpe + frecpx + frsqrte + fsqrt + fmov f2i + fmul
basic fp/asimd ops + aes + fmov f2i + fmul
basic fp/asimd ops + aes

相比 M1 E-Core，整数和浮点方面都有扩充。和官方的信息，除了 store data/address 部分没有探测出来以外都一致，更具体来说，应该更接近：

load + sta
load + sta + std

Scheduler¶

P-Core¶

在 M4 P-Core 上测试，结果如下：

指令	可调度 + 不可调度	可调度
ld	66	51
st addr	66	51
st data	86	70
alu	198	175
fp	266	243
crc	36	23
idiv	36	23
bfm	31	18
fjcvtzs	72	60
fmov f2i	144	121
csel	98	85
mrs nzcv	60	47

首先看浮点：

可调度部分 fp 是 243，fmov f2i 是 121，fjcvtzs 是 60，有明显的 4:2:1 的关系
fp/fmov f2i/fjcvtzs 吞吐刚好也是 4:2:1 的关系
因此四个执行单元前面各有一个独立的 60 entry 的 Scheduler
不可调度部分，266-243=23，144-121=23，72-60=12，猜测有两个 Non Scheduling Queue，每个 Non Scheduling Queue 12 entry，分别对应两个 Scheduler

相比 M1 P-Core 有比较大的扩充：Scheduler 大小从 36 扩大到 60，Non Scheduling Queue 从 6 扩大到了 12。

下面是访存部分，load 和 store addr 一样，但 store data 要更多，可能做了不同的处理。

最后是整数部分，由于有 8 个整数执行单元，情况会比较复杂：

可调度部分 alu 一共是 175，其中 csel 是 85，crc/idiv 都是 23，bfm 是 18，mrs nzcv 是 47，结合 8 个整数执行单元，可以得到这 8 个执行单元对应的 Scheduler 大小关系：
1. alu + madd + mul + crc: 23 entries
2. alu + madd + mul + csel: a entries
3. alu + madd + mul: b entries
4. alu + csel + mrs nzcv + branch: c entries
5. alu + csel + mrs nzcv + branch: 47-c entries
6. alu + csel: 38-a entries
7. alu: d entries
8. alu: 67-b-d entries
alu 不可调度部分是 198-175=23，crc/idiv/bfm/csel/mrs nzcv 不可调度部分都是 13，应该是其中四个执行单元共享一个 12 entry 的 Non Scheduling Queue；另外四个执行单元共享剩下的 12 entry 的 Non Scheduling Queue
最后只差 a 到 d 的取值没有求出来，可以通过进一步测试来更加精确地求出

Scheduler 大小相比 M1 P-Core 有比较大的扩充，Non Scheduling Queue 没有变化。

E-Core¶

在 M4 E-Core 上测试，结果很不稳定，需要进一步研究。

测试过程详见测试代码。

Reorder Buffer¶

P-Core¶

首先用不同数量的 fsqrt 依赖链加 NOP 指令测试 M4 P-Core 的 ROB 大小：

可以看到当 fsqrt 数量足够多的时候，出现了统一的拐点，在 3184 条指令左右。

为了测 Coalesced ROB 的大小，改成用 load/store 指令，可以测到拐点在 313 左右：

3184 除以 313 约等于 10，意味着每个 group 可以保存 10 条指令，一共有 313 左右个 group。相比 M1 P-Core，Group 数量差不多，但是能保存的指令数量有了很大的提升。

E-Core¶

首先用 NOP 指令测试 M4 E-Core 的 ROB 大小：

可以看到拐点是 513 条指令。

为了测 Coalesced ROB 的大小，改成用 load/store 指令，可以测到拐点在 121 左右：

但是 513 除以 121 是 4.24，离 4 或者 5 都有一段距离，比较奇怪，不确定每个 group 可以放多少条指令。容量上比 M1 E-Core 有明显提升。

L2 Cache¶

官方信息：通过 sysctl 可以看到，4 个 M4 P-Core 核心共享一个 16MB L2 Cache，6 个 M4 E-Core 核心共享一个 4MB L2 Cache：

hw.perflevel0.l2cachesize: 16777216 hw.perflevel0.cpusperl2: 4 hw.perflevel1.l2cachesize: 4194304 hw.perflevel1.cpusperl2: 6

根据 Apple Silicon CPU Optimization Guide，L2 Cache 配置如下：

M1 Family/A14 Bionic: P-Core cluster 12MiB, 12-way, 128B lines; E-Core cluster 4MiB, 16-way, 128B lines
M2/M3/M4 Family/A16 Bionic/A17 Pro/A18 Pro: P-Core cluster 16MiB, 16-way, 128B lines; E-Core cluster 4MiB, 16-way, 128B lines
A14 Bionic/A18: P-Core cluster 8MiB, 16-way, 128B lines; E-Core cluster 4MiB, 16-way, 128B lines

Memory Cache¶

官方信息：根据 Apple Silicon CPU Optimization Guide，Memory Cache（在别的处理器也叫 System Level Cache，就是 Last Level Cache）的配置如下：

M1/M2/M3/M4: 8MiB, 16-way, 128B lines
M3 Pro/A18: 12MiB, 16-way, 128B lines
A14 Bionic: 16MiB, 16-way, 128B lines
M1 Pro/M2 Pro/M4 Pro/A16 Bionic/A17 Pro/A18 Pro: 24MiB, 12-way, 128B lines
A15 Bionic: 32MiB, 16-way, 128B lines
M1 Max/M2 Max/M3 Max/M4 Max: 48MiB, 12-way, 128B lines
M1 Ultra/M2 Ultra/M3 Ultra: 96MiB, 12-way, 128B lines

L2 TLB¶

官方信息：根据 Apple Silicon CPU Optimization Guide，P-Core 的 L2 TLB 容量，从 M1 Family 到 M4 Family，从 A14 Bionic 到 A18 Family，都是 3072 entries；E-Core 的 L2 TLB 容量，M1 Family 和 A14 Bionic 是 1024 entries，M2 Family 到 M4 Family 和 A15 Bionic 到 A18 Family 都是 2048 entries。

P-Core¶

沿用之前测试 L1 DTLB 的方法，把规模扩大到 L2 Unified TLB 的范围，就可以测出来 L2 Unified TLB 的容量，下面是 M4 P-Core 上的测试结果：

可以看到拐点是 3072 个 Page，说明 M4 P-Core 的 L2 TLB 容量是 3072 项，和官方信息一致。这和 M1 P-Core 是一样的。

E-Core¶

在 M4 E-Core 上测试：

可以看到拐点是 1024 个 Page，说明 M4 E-Core 的 L2 TLB 容量是 1024 项，和官方信息不一致，官方信息写的是 2048 项。这和 M1 E-Core 测出来是一样的。

测试过程详见测试代码。

总结¶

M4 相比 M1，在很多方面做了迭代：

P-Core 的前端有较大改进，尤其是 BTB 部分
各种结构相比 M1 有了容量的增加
寄存器堆增加了对 32 位整数寄存器的优化
引入了 Load Address/Value Predictor
扩充了执行单元，P-Core 主要扩充了整数，E-Core 则是整数和浮点都做了扩充
添加了 SME 指令集

但也有一些遗憾，例如访存方面没有每周期带宽上的增加，P-Core 的浮点也没有增加。

分析 Rocket Chip 中 Diplomacy 系统

Wed, 14 May 2025 00:00:00 +0000

分析 Rocket Chip 中 Diplomacy 系统¶

背景¶

Rocket Chip 大量使用了 Diplomacy 系统来组织它的总线、中断和时钟网络。因此，如果想要对 Rocket Chip 进行定制，那么必须要对 Rocket Chip 中 Diplomacy 系统的使用有充分的了解，而这方面的文档比较欠缺。本文是对 Rocket Chip 中 Diplomacy 系统的使用的分析。阅读本文前，建议阅读先前的分析 Diplomacy 系统文章，对 Diplomacy 系统的设计和内部实现获得一定的了解。

Rocket Chip 总线结构概要¶

Rocket Chip 主要有以下几个总线：

sbus: System Bus
mbus: Memory Bus
cbus: Control Bus
pbus: Periphery Bus
fbus: Frontend Bus

图示可以见参考文档中的链接，不过链接中的结构和实际的有一些区别。目前的 Rocket Chip 的总线结构大致是这样：

fbus -> sbus -> mbus tile --/ \-> cbus -> pbus

主要是 pbus 的位置从连接 sbus 移动到了连接 cbus。

根据配置不同，总线结构也不同，例如在有 coh(coherence manager) 的时候，是：

fbus -> sbus -> coh -> mbus tile --/ \-> cbus -> pbus

深入分析 Rocket Chip 总线结构¶

下面是一个双核 Rocket Chip 的 GraphML 导出来用 yED 绘制的架构图：

接下来深入分析图中的各个连接关系以及对应的代码。

TileLink 和 AXI 总线¶

这个图比较复杂，混合了多个 Diplomacy 网络，首先是总线的部分，包括 TileLink 和 AXI：

两个 Tile，对应一个双核的系统；每个 Tile 内部有一个 dcache 和 icache，连接到一个 tlMasterXbar 上，再通过 coupler_from_rockettile 连接到 fixer 再到 system_bus_xbar
从 system_bus_xbar 分出来三路 Slave：
1. 第一路是 cbus，通过 out_xbar，连接到多个 slave：debug，error device，plic，clint，l2 control，bootrom
2. 第二路是 mmio，通过 tl2axi4，转成 AXI4 连接到外部的 MMIO 外设
3. 第三路是 coh，连接到 InclusiveCache，再连接到 mbus，通过 tl2axi4，转成 AXI4 连接到外部的内存
system_bus_xbar 除了每个 tile 对应一个 master 以外，还有一个 master：fbus，它从外部的 AXI4 进来，通过 axi42tl 转换，接到 fbus，提供一个有缓存一致性的 AXI 访问接口，用于 DMA

简化后的结构如图：

flowchart TD subgraph tile0 dcache0[dcache] icache0[icache] tlMasterXbar0[tlMasterXbar] dcache0 --> tlMasterXbar0 icache0 --> tlMasterXbar0 end subgraph tile1 dcache1[dcache] icache1[icache] tlMasterXbar1[tlMasterXbar] dcache1 --> tlMasterXbar1 icache1 --> tlMasterXbar1 end sbus tlMasterXbar0 --> sbus tlMasterXbar1 --> sbus axi_fbus --> axi42tl --> fbus --> sbus sbus --> cbus --> out_xbar out_xbar --> debug out_xbar --> error out_xbar --> plit out_xbar --> clint out_xbar --> l2_ctrl out_xbar --> bootrom cbus --> pbus sbus --> tl2axi4_mmio[tl2axi4] --> axi_mmio sbus --> coh --> mbus --> tl2axi4_mem[tl2axi4] --> axi_mem

那么这些连接关系在代码中是怎么搭建的呢：

首先是 tile 内部，dcache 和 icache 分别通过一个 widget 连到一个 tlMasterXbar 上：

class Frontend(val icacheParams: ICacheParams, tileId: Int)(implicit p: Parameters) extends LazyModule {  lazy val module = new FrontendModule(this)  // icache resides in frontend  val icache = LazyModule(new ICache(icacheParams, tileId))  val masterNode = icache.masterNode  val slaveNode = icache.slaveNode  val resetVectorSinkNode = BundleBridgeSink[UInt](Some(() => UInt(masterNode.edges.out.head.bundle.addressBits.W))) }  trait HasICacheFrontend extends CanHavePTW { this: BaseTile =>  val frontend = LazyModule(new Frontend(tileParams.icache.get, tileId))  // tlMasterXbar.node <-- TLWidthWidget <-- frontend.masterNode(i.e. icache.masterNode)  tlMasterXbar.node := TLWidthWidget(tileParams.icache.get.rowBits/8) := frontend.masterNode }  trait HasHellaCache { this: BaseTile =>  lazy val dcache: HellaCache = LazyModule(p(BuildHellaCache)(this)(p))  tlMasterXbar.node := TLWidthWidget(tileParams.dcache.get.rowBits/8) := dcache.node }

2. 其次是每个 tile 的 tlMasterXbar 连接到 coupler_from_rockettile，再连到 sbus(system_bus_xbar)

// in HasTiles.scala /** Connect the port where the tile is the master to a TileLink interconnect. */ def connectMasterPorts(domain: TilePRCIDomain[TileType], context: Attachable): Unit = {  implicit val p = context.p  // crossingParams.master.where defaults to SBUS, see below  // so dataBus is system_bus_xbar  val dataBus = context.locateTLBusWrapper(crossingParams.master.where)  // coupler_from_rockettile (val baseName = "rockettile" in RocketTileParams)  dataBus.coupleFrom(tileParams.baseName) { bus =>  // crossMasterPort is defined below  bus :=* crossingParams.master.injectNode(context) :=* domain.crossMasterPort(crossingParams.crossingType)  } }  // in HierarchicalElementPRCIDomain.scala def crossMasterPort(crossingType: ClockCrossingType): TLOutwardNode = {  val tlMasterResetXing = this { DisableMonitors { implicit p =>  element { element.makeMasterBoundaryBuffers(crossingType) } :=*  // masterNode is defined below  element_reset_domain.crossTLOut(element.masterNode)  } }  val tlMasterClockXing = this.crossOut(tlMasterResetXing)  tlMasterClockXing(crossingType) }  // in RocketTile.scala tlOtherMastersNode := tlMasterXbar.node masterNode :=* tlOtherMastersNode  // crossingParams defaults to RocketCrossingParams() // in RocketSubsystem.scala case class RocketCrossingParams(  crossingType: ClockCrossingType = SynchronousCrossing(),  master: HierarchicalElementPortParamsLike = HierarchicalElementMasterPortParams(),  slave: HierarchicalElementSlavePortParams = HierarchicalElementSlavePortParams(),  mmioBaseAddressPrefixWhere: TLBusWrapperLocation = CBUS,  resetCrossingType: ResetCrossingType = NoResetCrossing(),  forceSeparateClockReset: Boolean = false ) extends HierarchicalElementCrossingParamsLike  // default crossingParams.master.where is SBUS(System Bus) case class HierarchicalElementMasterPortParams(  buffers: Int = 0,  cork: Option[Boolean] = None,  where: TLBusWrapperLocation = SBUS ) extends HierarchicalElementPortParamsLike {  def injectNode(context: Attachable)(implicit p: Parameters): TLNode = {  (TLBuffer.chainNode(buffers) :=* cork.map { u => TLCacheCork(unsafe = u) } .getOrElse { TLTempNode() })  } }

接着是 sbus 连接到 coh，coh 连接到 mbus：

// in BusTopology.scala /** Parameterization of a topology containing a banked coherence manager and a bus for attaching memory devices. */ case class CoherentBusTopologyParams(  mbus: MemoryBusParams,  coherence: BankedCoherenceParams,  sbusToMbusXType: ClockCrossingType = NoCrossing,  driveMBusClockFromSBus: Boolean = true ) extends TLBusWrapperTopology(  // instantiate mbus and coherence manager  instantiations = (if (coherence.nBanks == 0) Nil else List(  (MBUS, mbus),  (COH, CoherenceManagerWrapperParams(mbus.blockBytes, mbus.beatBytes, coherence.nBanks, COH.name)(coherence.coherenceManager)))),  connections = if (coherence.nBanks == 0) Nil else List(  // (master, slave, parameters)  // coh := sbus  (SBUS, COH, TLBusWrapperConnection(driveClockFromMaster = Some(true), nodeBinding = BIND_STAR)()),  // mbus := coh  (COH, MBUS, TLBusWrapperConnection.crossTo(  xType = sbusToMbusXType,  driveClockFromMaster = if (driveMBusClockFromSBus) Some(true) else None,  nodeBinding = BIND_QUERY))  ) )  // in BusWrapper.scala class TLBusWrapperTopology(  val instantiations: Seq[(Location[TLBusWrapper], TLBusWrapperInstantiationLike)],  val connections: Seq[(Location[TLBusWrapper], Location[TLBusWrapper], TLBusWrapperConnectionLike)] ) extends CanInstantiateWithinContextThatHasTileLinkLocations  with CanConnectWithinContextThatHasTileLinkLocations {  def instantiate(context: HasTileLinkLocations)(implicit p: Parameters): Unit = {  instantiations.foreach { case (loc, params) => context { params.instantiate(context, loc) } }  }  def connect(context: HasTileLinkLocations)(implicit p: Parameters): Unit = {  connections.foreach { case (master, slave, params) => context { params.connect(context, master, slave) } }  } }

为了让 Rocket Chip 可以访问外部的 AXI MMIO 设备，在 sbus 下面添加了 tl 到 axi 的一条路径：

/** Adds a AXI4 port to the system intended to master an MMIO device bus */ trait CanHaveMasterAXI4MMIOPort { this: BaseSubsystem =>  private val mmioPortParamsOpt = p(ExtBus)  private val portName = "mmio_port_axi4"  private val device = new SimpleBus(portName.kebab, Nil)   val mmioAXI4Node = AXI4SlaveNode(  mmioPortParamsOpt.map(params =>  AXI4SlavePortParameters(  slaves = Seq(AXI4SlaveParameters(  address = AddressSet.misaligned(params.base, params.size),  resources = device.ranges,  executable = params.executable,  supportsWrite = TransferSizes(1, params.maxXferBytes),  supportsRead = TransferSizes(1, params.maxXferBytes))),  beatBytes = params.beatBytes)).toSeq)   // in BaseSubsystem.scala:  // def viewpointBus: TLBusWrapper = tlBusWrapperLocationMap(p(TLManagerViewpointLocated(location)))  // case class TLManagerViewpointLocated(where: HierarchicalLocation) extends Field[Location[TLBusWrapper]](SBUS)  // so viewpointBus points to sbus by default  mmioPortParamsOpt.map { params =>  viewpointBus.coupleTo(s"port_named_$portName") {  (mmioAXI4Node  := AXI4Buffer()  := AXI4UserYanker()  := AXI4Deinterleaver(viewpointBus.blockBytes)  := AXI4IdIndexer(params.idBits)  := TLToAXI4()  := TLWidthWidget(viewpointBus.beatBytes)  := _)  }  }   val mmio_axi4 = InModuleBody { mmioAXI4Node.makeIOs() } }

类似地，为了让 Rocket Chip 可以访问外部的 AXI Memory，在 mbus 下面添加了 tl 到 axi 的一条路径：

/** Adds a port to the system intended to master an AXI4 DRAM controller. */ trait CanHaveMasterAXI4MemPort { this: BaseSubsystem =>  private val memPortParamsOpt = p(ExtMem)  private val portName = "axi4"  private val device = new MemoryDevice  private val idBits = memPortParamsOpt.map(_.master.idBits).getOrElse(1)  private val mbus = tlBusWrapperLocationMap.get(MBUS).getOrElse(viewpointBus)   val memAXI4Node = AXI4SlaveNode(memPortParamsOpt.map({ case MemoryPortParams(memPortParams, nMemoryChannels, _) =>  Seq.tabulate(nMemoryChannels) { channel =>  val base = AddressSet.misaligned(memPortParams.base, memPortParams.size)  val filter = AddressSet(channel * mbus.blockBytes, ~((nMemoryChannels-1) * mbus.blockBytes))   AXI4SlavePortParameters(  slaves = Seq(AXI4SlaveParameters(  address = base.flatMap(_.intersect(filter)),  resources = device.reg,  regionType = RegionType.UNCACHED, // cacheable  executable = true,  supportsWrite = TransferSizes(1, mbus.blockBytes),  supportsRead = TransferSizes(1, mbus.blockBytes),  interleavedId = Some(0))), // slave does not interleave read responses  beatBytes = memPortParams.beatBytes)  }  }).toList.flatten)   for (i <- 0 until memAXI4Node.portParams.size) {  val mem_bypass_xbar = mbus { TLXbar() }   // Create an incoherent alias for the AXI4 memory  memPortParamsOpt.foreach(memPortParams => {  memPortParams.incohBase.foreach(incohBase => {  val cohRegion = AddressSet(0, incohBase-1)  val incohRegion = AddressSet(incohBase, incohBase-1)  val replicator = tlBusWrapperLocationMap(p(TLManagerViewpointLocated(location))) {  val replicator = LazyModule(new RegionReplicator(ReplicatedRegion(cohRegion, cohRegion.widen(incohBase))))  val prefixSource = BundleBridgeSource[UInt](() => UInt(1.W))  replicator.prefix := prefixSource  // prefix is unused for TL uncached, so this is ok  InModuleBody { prefixSource.bundle := 0.U(1.W) }  replicator  }  viewpointBus.coupleTo(s"memory_controller_bypass_port_named_$portName") {  (mbus.crossIn(mem_bypass_xbar)(ValName("bus_xing"))(p(SbusToMbusXTypeKey))  := TLWidthWidget(viewpointBus.beatBytes)  := replicator.node  := TLFilter(TLFilter.mSubtract(cohRegion))  := TLFilter(TLFilter.mResourceRemover)  := _  )  }  })  })   mbus.coupleTo(s"memory_controller_port_named_$portName") {  (memAXI4Node  := AXI4UserYanker()  := AXI4IdIndexer(idBits)  := TLToAXI4()  := TLWidthWidget(mbus.beatBytes)  := mem_bypass_xbar  := _  )  }  }   val mem_axi4 = InModuleBody { memAXI4Node.makeIOs() } }

类似地，为了让外部的 AXI Master 可以访问一致的内存，在 fbus 上面添加了从 axi 到 tl 的一条路径，而 fbus 是连到 sbus 上的：

/** Adds an AXI4 port to the system intended to be a slave on an MMIO device bus */ trait CanHaveSlaveAXI4Port { this: BaseSubsystem =>  private val slavePortParamsOpt = p(ExtIn)  private val portName = "slave_port_axi4"  private val fifoBits = 1  private val fbus = tlBusWrapperLocationMap.get(FBUS).getOrElse(viewpointBus)   val l2FrontendAXI4Node = AXI4MasterNode(  slavePortParamsOpt.map(params =>  AXI4MasterPortParameters(  masters = Seq(AXI4MasterParameters(  name = portName.kebab,  id = IdRange(0, 1 << params.idBits))))).toSeq)   slavePortParamsOpt.map { params =>  fbus.coupleFrom(s"port_named_$portName") {  ( _  := TLBuffer(BufferParams.default)  := TLFIFOFixer(TLFIFOFixer.all)  := TLWidthWidget(params.beatBytes)  := AXI4ToTL()  := AXI4UserYanker(Some(1 << (params.sourceBits - fifoBits - 1)))  := AXI4Fragmenter()  := AXI4IdIndexer(fifoBits)  := l2FrontendAXI4Node )  }  }   val l2_frontend_bus_axi4 = InModuleBody { l2FrontendAXI4Node.makeIOs() } }  case class HierarchicalBusTopologyParams(  pbus: PeripheryBusParams,  fbus: FrontBusParams,  cbus: PeripheryBusParams,  xTypes: SubsystemCrossingParams,  driveClocksFromSBus: Boolean = true ) extends TLBusWrapperTopology(  instantiations = List(  (PBUS, pbus),  (FBUS, fbus),  (CBUS, cbus)),  connections = List(  // (master, slave, params)  // cbus := sbus  (SBUS, CBUS, TLBusWrapperConnection .crossTo(xTypes.sbusToCbusXType, if (driveClocksFromSBus) Some(true) else None)),  // pbus := cbus  (CBUS, PBUS, TLBusWrapperConnection .crossTo(xTypes.cbusToPbusXType, if (driveClocksFromSBus) Some(true) else None)),  // sbus := fbus  (FBUS, SBUS, TLBusWrapperConnection.crossFrom(xTypes.fbusToSbusXType, if (driveClocksFromSBus) Some(false) else None))) )

上一段代码中，在 sbus 的下游挂载了 cbus，在 cbus 下游挂载了 pbus；那么 debug/plic/clint 等设备都是挂载在 cbus 下的：

// in HasPeripheryDebug of Periphery.scala // default to cbus private lazy val tlbus = locateTLBusWrapper(p(ExportDebug).slaveWhere) val tlDM = LazyModule(new TLDebugModule(tlbus.beatBytes)) tlDM.node := tlbus.coupleTo("debug"){ TLFragmenter(tlbus.beatBytes, tlbus.blockBytes, nameSuffix = Some("Debug")) := TLBuffer() := _ }  // in CanHavePeripheryCLINT of CLINT.scala // default to cbus val tlbus = locateTLBusWrapper(p(CLINTAttachKey).slaveWhere) val clintDomainWrapper = tlbus.generateSynchronousDomain("CLINT").suggestName("clint_domain") val clint = clintDomainWrapper { LazyModule(new CLINT(params, tlbus.beatBytes)) } clintDomainWrapper { clint.node := tlbus.coupleTo("clint") { TLFragmenter(tlbus, Some("CLINT")) := _ } }  // in CanHavePeripheryPLIC of Plic.scala // default to cbus val tlbus = locateTLBusWrapper(p(PLICAttachKey).slaveWhere) val plicDomainWrapper = tlbus.generateSynchronousDomain("PLIC").suggestName("plic_domain") val plic = plicDomainWrapper { LazyModule(new TLPLIC(params, tlbus.beatBytes)) } plicDomainWrapper { plic.node := tlbus.coupleTo("plic") { TLFragmenter(tlbus, Some("PLIC")) := _ } } plicDomainWrapper { plic.intnode :=* ibus.toPLIC }

至此就把前面提到的 Rocket Chip 的总线结构在源码中的对应关系都找到了。

除了这一组大的总线结构，实际上调试模块内部还有一个小的总线，主要是把 RISC-V Debug 的 DMI 转化为 TileLink，然后访问内部的一些寄存器。

中断¶

除了总线，中断也是通过 Diplomacy 管理的。首先可以看到，每个 Tile 有一个中断的 SinkNode：

// Use diplomatic interrupts to external interrupts from the subsystem into the tile trait SinksExternalInterrupts { this: BaseTile =>  val intInwardNode = intXbar.intnode :=* IntIdentityNode()(ValName("int_local"))  protected val intSinkNode = IntSinkNode(IntSinkPortSimple())  intSinkNode := intXbar.intnode   // go from flat diplomatic Interrupts to bundled TileInterrupts  def decodeCoreInterrupts(core: TileInterrupts): Unit = {  val async_ips = Seq(core.debug)  val periph_ips = Seq(  core.msip,  core.mtip,  core.meip)   val seip = if (core.seip.isDefined) Seq(core.seip.get) else Nil   val core_ips = core.lip   val (interrupts, _) = intSinkNode.in(0)  (async_ips ++ periph_ips ++ seip ++ core_ips).zip(interrupts).foreach { case(c, i) => c := i }  } }  class TileInterrupts(implicit p: Parameters) extends CoreBundle()(p) {  val debug = Bool()  val mtip = Bool()  val msip = Bool()  val meip = Bool()  val seip = usingSupervisor.option(Bool())  val lip = Vec(coreParams.nLocalInterrupts, Bool())  val nmi = usingNMI.option(new NMI(resetVectorLen)) }

它通过 Diplomacy 的 intXbar 输入多路的中断，然后按照顺序，还原出对应的 debug/mtip/msip/seip 等中断信号。从前面的图中，也可以看到 intXbar 的第一个输入 debug（经过 intsink）来自 dmOuter 也就是调试模块，第二个和第三个输入 msip 和 mtip（经过 intsink_1）来自 clint（负责时钟 mtimer 和软件中断），最后的 meip 和 seip（经过 intsink_2/3）来自 plic（负责外部中断）。为了处理外部中断，从外面接了 6 位的中断信号到 plic。

时钟¶

最后，时钟（时钟加上复位）也是由 Diplomacy 管理的：从前面的图中，从 aggregator 进来，首先到 sbus，然后分出来多路的时钟信号：第一路到 cbus，用于 cbus 的各个外设（plic/clint 等），进一步也从 cbus 引到 pbus；第二路到各个 tile；第三路到 coh（coherence wrapper）；第四路到 fbus。默认配置下，这些时钟都是同一个信号，没有额外的处理，但是通过配置，可以把它们区分开，放到不同的时钟域，并在跨时钟域的时候，添加合适的跨时钟域的处理。

那么这些时钟是怎么分出来的呢：

aggregator 把时钟暴露到 IO 上，然后内部暴露一个 allClockGroupsNode，连接到 sbus 上：

// in BaseSubsystem.scala trait HasConfigurablePRCILocations { this: HasPRCILocations =>  val ibus = LazyModule(new InterruptBusWrapper)  val allClockGroupsNode = ClockGroupIdentityNode()  val io_clocks = if (p(SubsystemDriveClockGroupsFromIO)) {  val aggregator = ClockGroupAggregator()  val source = ClockGroupSourceNode(Seq(ClockGroupSourceParameters()))  allClockGroupsNode :*= aggregator := source  Some(InModuleBody {  val elements = source.out.map(_._1.member.elements).flatten  val io = IO(Flipped(RecordMap(elements.map { case (name, data) =>  name -> data.cloneType  }:_*)))  elements.foreach { case (name, data) => io(name).foreach { data := _ } }  io  })  } else {  None  } }  abstract class BaseSubsystem(val location: HierarchicalLocation = InSubsystem)  (implicit p: Parameters)  extends BareSubsystem  with HasDTS  with Attachable  with HasConfigurablePRCILocations  with HasConfigurableTLNetworkTopology {   // viewpointBus points to sbus by default  viewpointBus.clockGroupNode := allClockGroupsNode }

前面提到，通过 CoherentBusTopologyParams，实现 mbus := coh := sbus 的连接，通过 HierarchicalBusTopologyParams，实现 pbus := cbus := sbus := fbus 的连接，与此同时，时钟也被接上了：

// in BusTopology.scala // (master, slave, parameters) // from CoherentBusTopologyParams // coh := sbus, use sbus's clock for coh (SBUS, COH, TLBusWrapperConnection(driveClockFromMaster = Some(true), nodeBinding = BIND_STAR)()), // mbus := coh, use coh's clock for mbus by default (COH, MBUS, TLBusWrapperConnection.crossTo(  xType = sbusToMbusXType,  driveClockFromMaster = if (driveMBusClockFromSBus) Some(true) else None,  nodeBinding = BIND_QUERY))  // from HierarchicalBusTopologyParams // cbus := sbus, use sbus's clock for cbus by default (SBUS, CBUS, TLBusWrapperConnection .crossTo(xTypes.sbusToCbusXType, if (driveClocksFromSBus) Some(true) else None)), // pbus := cbus, use cbus's clock for pbus by default (CBUS, PBUS, TLBusWrapperConnection .crossTo(xTypes.cbusToPbusXType, if (driveClocksFromSBus) Some(true) else None)), // sbus := fbus, use sbus's clock for fbus by default (FBUS, SBUS, TLBusWrapperConnection.crossFrom(xTypes.fbusToSbusXType, if (driveClocksFromSBus) Some(false) else None)))

具体地，每个 bus 有一个自己的 clockGroupNode，bus 之间的 clockGroupNode 按照上面所属的方式连接，然后 bus 下面的设备再挂到 fixedClockNode 下面：

abstract class TLBusWrapper(params: HasTLBusParams, val busName: String)(implicit p: Parameters)  extends ClockDomain  with HasTLBusParams  with CanHaveBuiltInDevices {  private val clockGroupAggregator = LazyModule(new ClockGroupAggregator(busName){ override def shouldBeInlined = true }).suggestName(busName + "_clock_groups")  private val clockGroup = LazyModule(new ClockGroup(busName){ override def shouldBeInlined = true })  val clockGroupNode = clockGroupAggregator.node // other bus clock groups attach here  val clockNode = clockGroup.node  val fixedClockNode = FixedClockBroadcast(fixedClockOpt) // device clocks attach here  private val clockSinkNode = ClockSinkNode(List(ClockSinkParameters(take = fixedClockOpt)))   clockGroup.node := clockGroupAggregator.node  fixedClockNode := clockGroup.node // first member of group is always domain's own clock  clockSinkNode := fixedClockNode   def clockBundle = clockSinkNode.in.head._1 }  // in ClockDomain.scala abstract class Domain(implicit p: Parameters) extends LazyModule with HasDomainCrossing {  def clockBundle: ClockBundle   lazy val module = new Impl  class Impl extends LazyRawModuleImp(this) {  childClock := clockBundle.clock  childReset := clockBundle.reset  override def provideImplicitClockToLazyChildren = true   // these are just for backwards compatibility with external devices  // that were manually wiring themselves to the domain's clock/reset input:  val clock = IO(Output(chiselTypeOf(clockBundle.clock)))  val reset = IO(Output(chiselTypeOf(clockBundle.reset)))  clock := clockBundle.clock  reset := clockBundle.reset  } }

TileLink Widgets¶

Rocket Chip 中用 Diplomacy 实现 TileLink 总线的连接。涉及到的相关结构如下：

TLBundle：代表 TileLink 总线的接口，根据 TLBundleParameters 例化
TLMasterPortParameters：信息 TileLink Master 的信息，从 Upstream 向 Downstream 传递
TLSlavePortParameters：信息 TileLink Slave 的信息，从 Downstream 向 Upstream 传递
TLEdgeOut：记录 Outward 边，也就是 Master 侧的 TileLink 的信息
TLEdgeIn：记录 Inward 边，也就是 Slave 侧的 TileLink 的信息
TLImp: extends NodeImp[TLMasterPortParameters, TLSlavePortParameters, TLEdgeOut, TLEdgeIn, TLBundle]，基于这个类型来导出各种类型的 TileLink Node
TLXBar：TileLink 的 Crossbar，生成一个继承 NexusNode 的 TLNexusNode，它的信息传递方式是，把下游的各个 Slave 信息拼起来传给上游，使得 Master 可以看到所有 Slave 的信息；把上游的各个 Master 信息拼起来传给下游，使得 Slave 可以看到所有 Master 的信息
TLToAXI4：生成一个继承 AdapterNode 的 TLToAXI4Node，把 TileLink Master 转成 AXI4 Master，把上游的 TileLink Master 信息转换为 AXI Master 传递给下游，把下游的 AXI Slave 信息转换为 TileLink Slave 传递给上游

参考文档¶

Intel Redwood Cove 微架构评测

Wed, 23 Apr 2025 00:00:00 +0000

Intel Redwood Cove 微架构评测¶

背景¶

之前我们测试了 Intel 的微架构 Redwood Cove，这次就来测一下 Redwood Cove，它被用到了 Meteor Lake 以及 Granite Rapids 上。这次就以阿里云 g9i 实例的 Granite Rapids 机器来测试一下 Redwood Cove 微架构的各项指标。

官方信息¶

Intel 关于 Redwood Cove 微架构有这些官方的信息：

现有评测¶

网上已经有较多针对 Redwood Cove 微架构的评测和分析，建议阅读：

下面分各个模块分别记录官方提供的信息，以及实测的结果。读者可以对照已有的第三方评测理解。官方信息与实测结果一致的数据会加粗。

Benchmark¶

Intel Redwood Cove 的性能测试结果见 SPEC。

前端¶

L1 ICache¶

官方信息：

Larger instruction cache: 32K→64K.

为了测试 L1 ICache 容量，构造一个具有巨大指令 footprint 的循环，由大量的 4 字节 nop 和最后的分支指令组成。观察在不同 footprint 大小下的 IPC：

可以看到 footprint 在 64 KB 之前时可以达到 6 IPC，之后则降到 3.2 IPC，这里的 64 KB 就对应了 L1 ICache 的容量。容量相比 Golden Cove 翻倍，终于和 ARM 看齐。

L1 ITLB¶

构造一系列的 jmp 指令，使得 jmp 指令分布在不同的 page 上，使得 ITLB 成为瓶颈：

可以看到 256 个 Page 出现了明显的拐点，对应的就是 256 的 L1 ITLB 容量。注意要避免 ICache 和 BTB 的容量成为瓶颈，把 jmp 指令分布在不同的 Cache Line 和 BTB entry 上。

超过 256 个 Page 以后，如图有周期数突然下降后缓慢上升的情况（例如横坐标 288->289、320->321、352->353、384->385 等，以 32 为周期），背后的原理需要进一步分析，猜测和 Linux 的 Huge Page 机制相关。

Redwood Cove 的 L1 ITLB 容量和 Golden Cove 是一样的。

Instruction Decode Queue (IDQ) + Loop Stream Detector (LSD)¶

官方信息：

Improved LSD coverage: the IDQ can hold 192 μops per logical processor in single-thread mode or 96 μops per thread when SMT is active.

为了测试 Instruction Decode Queue 的大小，构造不同大小的循环，循环体是复制若干份的 inc %rsi 指令，最后是 dec + jnz 作为循环结尾，通过 LSD.UOPS 性能计数器统计每次循环有多少个 UOP 来自于 Loop Stream Detector 机制，发现其最大值为 191，说明 Redwood Cove 的 Loop Stream Detector 可以识别最多 191 个 uop 的循环。此时每个循环要执行 192 条指令，最后的 dec + jnz 被融合成了一个 uop。相比 Golden Cove 的 144 uops IDQ 容量有所增加。

循环体中，如果用 nop 指令来填充，会得到 39 左右的比 192 小得多的容量，猜测是进入了低功耗模式。

Instruction Prefetch Instruction¶

官方信息：

Code Software Prefetch x86 architecture extension (Granite Rapids only).
PREFETCHIT0: (temporal code)—prefetch code into all levels of the cache hierarchy.
PREFETCHIT1: (temporal code with respect to first level cache misses)—prefetch code into all but the first-level of the cache hierarchy.

Conditional Branch Predictor¶

参考 Half&Half: Demystifying Intel’s Directional Branch Predictors for Fast, Secure Partitioned Execution 论文的方法，可以测出 Redwood Cove 的分支预测器采用的历史更新方式为：

使用 388 位的 Path History Register，每次执行 taken branch 时更新
更新方式为：PHRnew = (PHRold << 2) xor footprint
footprint 共有 16 位，其中 B 代表分支指令的地址，T 代表分支跳转的目的地址：
- footprint[0] = B[3] xor T[0]
- footprint[1] = B[4] xor T[1]
- footprint[2] = B[5]
- footprint[3] = B[6]
- footprint[4] = B[7]
- footprint[5] = B[8]
- footprint[6] = B[9]
- footprint[7] = B[10]
- footprint[8] = B[0] xor T[2]
- footprint[9] = B[1] xor T[3]
- footprint[10] = B[2] xor T[4]
- footprint[11] = B[11] xor T[5]
- footprint[12] = B[12]
- footprint[13] = B[13]
- footprint[14] = B[14]
- footprint[15] = B[15]

和 Golden Cove 是一样的。各厂商处理器的 PHR 更新规则见 jiegec/cpu。

后端¶

L1 DCache¶

构造不同大小 footprint 的 pointer chasing 链，测试不同 footprint 下每条 load 指令耗费的时间：

0KB-48KB: 5 cycle，对应 L1 DCache
48KB-384KB: 16 cycle，对应 L2 Cache，且命中了 L1 DTLB；说明 L1 miss L2 hit 带来了 11 cycle 的损失

L1 DCache 大小和 Golden Cove 相同。

L1 DTLB¶

用类似测 L1 DCache 的方法测试 L1 DTLB 容量，只不过这次 pointer chasing 链的指针分布在不同的 page 上，使得 DTLB 成为瓶颈：

可以看到 96 Page 出现了明显的拐点，对应的就是 96 的 L1 DTLB 容量。没有超出 L1 DTLB 容量前，Load to use latency 是 5 cycle；超出 L1 DTLB 容量后，Load to use latency 是 12 cycle，说明 L1 DTLB miss 带来了 7 cycle 的损失。

L1 DTLB 大小和 Golden Cove 相同。

执行单元¶

官方信息：

EXE: 3-cycle Floating Point multiplication.

LSU¶

Load Store 带宽¶

针对 Load Store 带宽，实测每个周期可以完成：

3x 256b Load
2x 256b Load + 2x 256b Store
1x 256b Load + 2x 256b Store
2x 256b Store
2x 512b Load
1x 512b Load + 1x 512b Store
1x 512b Store

Store to Load Forwarding¶

经过实际测试，Redwood Cove 上如下的情况可以成功转发，对地址 x 的 Store 转发到对地址 y 的 Load 成功时 y-x 的取值范围：

Store\Load	8b Load	16b Load	32b Load	64b Load
8b Store	{0}	{}	{}	{}
16b Store	[0,1]	{0}	{}	{}
32b Store	[0,3]	[0,2]	{0}	{}
64b Store	[0,7]	[0,6]	[0,4]	{0}

可以看到，Redwood Cove 在 Store 完全包含 Load 的情况下都可以转发，没有额外的对齐要求。但当 Load 和 Store 只有部分重合时，就无法转发。两个连续的 32 位的 Store 和一个 64 位的 Load 重合也不能转发。

特别地，在 y=x 且不跨越缓存行边界且满足下列要求的情况下，Store Forwarding 不会或只带来很小的性能损失：

8b Store -> 8b Load
32b Store -> 8b Load
64b Store -> 8b Load
32b Store -> 32b Load
64b Store -> 32b Load
64b Store -> 64b Load

考虑到 y 必须等于 x，也就是地址要一样，猜测 Redwood Cove 使用了类似 Memory Renaming 的技术来实现这个效果。如果是连续两个对同一个地址的 Store 对一个 Load 的转发，效果和只有一个 Store 是一样的。

除了上述情况以外，Store Forwarding 成功时的延迟在 5 个周期，失败则要 19 个周期。

和 Golden Cove 是一样的。

小结：Redwood Cove 的 Store to Load Forwarding：

1 ld + 1 st: 要求 st 包含 ld，特别地，地址相同时，性能最好
1 ld + 2+ st: 不支持

Prefetcher¶

官方信息：

New HW data prefetcher to recognize and prefetch the “Array of Pointers” pattern.

Intel Redwood Cove 的处理器通过 MSR 1A4H 可以配置各个预取器（来源：Software Developers Manual，Additional MSRs Supported by the Intel® Core™ Ultra 7 Processors Supporting Performance Hybrid Architecture）：

MSR_1A4H[0]: the L2 hardware prefetcher, which fetches additional lines of code or data into the L2 cache.
MSR_1A4H[1]: the L2 adjacent cache line prefetcher, which fetches the cache line that comprises a cache line pair (128 bytes). 这和 AMD 的 Up/Down Prefetcher 应该是一个意思
MSR_1A4H[2]: the L1 data cache prefetcher, which fetches the next cache line into L1 data cache. 这个应该属于 Next Line Prefetcher
MSR_1A4H[3]: the L1 data cache IP prefetcher, which uses sequential load history (based on instruction pointer of previous loads) to determine whether to prefetch additional lines.
MSR_1A4H[4]: Next page prefetcher，当访问快走到一个页的结尾的时候，从下一个页的开头开始 prefetch，提前进行可能的 TLB refill
MSR_1A4H[5]: the L2 Adaptive Multipath Probability (AMP) prefetcher. 这个应该属于 Spatial Prefetcher
MSR_1A4H[6]: LLC page prefetcher，类似 Next page prefetcher 的思路，但是把虚拟地址上连续的两个 4KB 的页，一共 8KB 的数据预取到 LLC 缓存上
MSR_1A4H[7]: Array of pointers prefetcher，针对指针数组 T *arr[] 的场景进行预取
MSR_1A4H[8]: Stream prefetch code fetch

ReOrder Buffer¶

为了测试 ROB 的大小，设计了一个循环，循环开始和结束是长延迟的 long latency load。中间是若干条 NOP 指令，当 NOP 指令比较少时，循环的时候取决于 load 指令的时间；当 NOP 指令数量过多，填满了 ROB 以后，就会导致 ROB 无法保存循环末尾的 load 指令，性能出现下降。测试结果如下：

当 NOP 数量达到 512 时，性能开始急剧下滑，说明 Redwood Cove 的 ROB 大小是 512。这和 Golden Cove 是一样的。

总结¶

Redwood Cove 相比 Golden Cove 是比较小的一个迭代，更新的部分主要有：

扩大了 L1 ICache 容量
扩大了分支预测器的容量（通过 MPKI 看出）
增加了更多预取器

因此性能提升也比较小，希望 Intel 可以更加给力一些，给 AMD 一些竞争压力。