2025-12-25 08:00:00
经常看我博客的读者应该能看出来，我研究的主要是计算机系统结构方向，特别是处理器的微架构，几乎没有涉及到 AI 的内容，我也确实不喜欢 AI 研究，仅关注但不参与。但今年，因为各种 AI 技术尤其是 LLM 的发展，我确实成为了很多 AI 技术的用户，可以说 2025 年是我正经大规模用 AI 的元年，所以在年末做一个简单的总结。
我不想在这里给大模型厂商打广告，所以相关的名字我都会按照某 PDF 的方法进行打码，有需要的朋友可以自行查看实际的内容。
首先的一个冲击来自于 Vibe Coding。我写代码也有大概十五年了，一直都是坚持自己写代码，但今年从一些朋友那里了解到一些 Vibe Coding 的效果以后，也自己尝试了一下，确实能够感受到 Vibe Coding 对写代码的巨大冲击，我的心态也出现了一定的变化。Vibe Coding 并不复杂，其实就是用一些 Coding 客户端，配上 LLM 加一些 Tool Call，使得 LLM 可以自己编写、测试和运行代码。目前随着 LLM 能力的变强，Vibe Coding 逐渐成为了一个可以负担得起且效果不错的东西。结合实际的使用，以及受朋友们的一些启发，我目前已经用它进行了一些 Vibe Coding 尝试，例如：
目前给我的感觉是，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 使用总结。总的下来，就是感叹自己也到了感慨科技进步的年纪了，十几年前学技术，虽然也能感觉到科技进步，但因为自己是从零开始，学的就是最新的科技，所以没有啥感觉。但这几年，不断地把新的输入和已有的积累进行对比，就能感觉明显到技术潮流和技术栈的移动，也能感觉到自己对新技术的接受度开始有了略微的下降，这值得让我警醒。以前，我们总是嘲笑大人不追求潮流，不去学习手机等新技术，我们在这个时代长大的人，可也不能犯这样的错误呀。
2025-10-28 08:00:00
去年我完成了针对 Apple 和 Qualcomm 条件分支预测器（Conditional Branch Predictor）的逆向工程研究，相关论文已发表在 arXiv 上，并公开了源代码。考虑到许多读者对处理器逆向工程感兴趣，但可能因其复杂性而望而却步，本文将以 Apple M1 Firestorm 为例，详细介绍条件分支预测器的逆向工程方法，作为对原论文的补充说明。
首先介绍一些背景知识。要逆向工程条件分支预测器，需要先了解其工作原理。条件分支预测器的基本思路是：
为了在硬件上实现这一算法，处理器会维护一个预测表，表中每一项包含一个 2 位饱和计数器，用于预测跳转方向。查表时，系统会对条件分支地址以及近期执行的分支历史进行哈希运算，使用哈希结果作为索引读取表项，然后根据计数器的值来预测分支的跳转方向。
（图源：CMU ECE740 Computer Architecture: Branch Prediction）
目前主流处理器普遍采用 TAGE 预测器，它在上述基础查表方法的基础上进行了重要改进：
（图源：Half&Half: Demystifying Intel's Directional Branch Predictors for Fast, Secure Partitioned Execution）
因此，要逆向工程处理器的条件分支预测器，需要完成以下工作：
第一步是逆向工程处理器记录分支历史的方式。传统教科书方法使用一个寄存器，每当遇到条件分支时记录其跳转方向（跳转记为 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}\) 能够记录多少条最近分支的历史。具体方法是构建一个分支历史序列：
接下来分析两种情况：
通过构造上述程序，调整中间无条件分支的数量，并使用性能计数器统计分支预测错误率，可以找到一个临界点。当无条件分支数量超过这个阈值时，第二个条件分支的错误预测率会从 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 的针对条件分支的预测错误次数的隐藏性能计数器，用于后续的实验。
接下来需要推测 \(\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}\) 的计算：
对应的代码如下：
// 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。所以一定还有其他的信息。
刚刚测试了 \(B\)，接下来测试 \(T\) 各位对 \(\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 上测试，得到如下结果：
是的，所以这里在测试的时候，采用的是类似 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{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 表与缓存结构类似，也是一个多路组相连的结构，通过 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 如何参与到 index 或 tag 计算中。通常，TAGE 只会采用一部分 PC 位参与 index 或 tag 计算。换句话说，如果两个分支在 PC 上不同的部分没有参与 index 或 tag 计算，那么 TAGE 无法区分这两条分支。如果这两个分支跳转方向相反，并且用相同的 PHR 进行预测，那么一定会出现错误的预测。思路如下：
d % 2 到 PHRT，并移动到高位（例如 \(PHRT[99]\)），使用前面所述的方法；对应代码类似于：
// 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 输入。这是因为这两部分是紧密耦合的：只有知道相连度，才能知道预测出来的分支数对应几个 set；但不知道 index 函数，又无法控制分支被分配到几个 set 中。首先，为了避免 PHR 的干扰，还是只注入一个随机数到 \(PHRT[99]\) 上（事实上，\(PHRT[99]\) 不是随便选择的，而是需要在 index 函数中，但通过测试可以找到满足要求的位）。其次，构造一系列分支，它们的地址满足：第 i 条分支（i 从 0 开始）的分支地址是 \(i2^k\)，其中 \(k\) 是接下来要遍历的参数。当 \(k=3\) 时，分支会被放到 0x0, 0x8, 0x10, 0x18, 0x20 等地址，涉及的 PC 位数随着分支数的增加而增加。接下来，我们分类讨论：
实验结果如下图：
纵坐标就是上面的 \(k\)，横坐标是测试的条件分支数，颜色表示预测的错误率。当颜色从深色变浅，就说明出现了预测错误。观察：
这就说明它是四路组相连，PC[6] 和 PC[9] 参与到了 index 函数中。
下面给读者一个小练习，下面是在 Qualcomm Oryon 上测得的结果，可以看到噪声比较大，你能推断出它是几路组相连，有哪些 PC 参与到了 index 计算吗？
四路组相连，\(PC[6]\) 和 \(PC[7]\) 参与到了 index 函数。
那么，这种测试是怎么构造的呢？即需要用相同的 PHR 去预测 \(PC=i2^k\) 的多条分支。思路比较复杂：
可见经过两步以后，PHRT 是保持不变的。针对 PHRB，只要 \(i2^{k-1}\) 没有涉及 \(PC[5:2]\)，就能保证相同。那么如果 \(k\) 足够小，也有办法：
因此我们总是可以通过两次分支，实现用相同的 PHR 预测不同 PC 上的多条分支。
接下来，进行 tag 函数的逆向工程。为了逆向工程 tag 函数，我们希望找到两个位在 tag 函数中有异或关系，那么如果这两个位同时设为 0，或者同时设为 1，其异或结果都等于 0，使得计算出来的 tag 函数相同，如果此时 index 还相同，那么预测器就无法区分这两种情况。
为了利用这一点，生成两个 0 到 1 的随机数 \(k\) 和 \(l\)，分别把它们注入到 PC、PHRB 或者 PHRT 中，去预测一个条件分支，其跳转与否取决于 \(k\) 的值（论文中有个小 typo）。如果 \(k\) 和 \(l\) 在 tag 函数中有异或关系，那么预测器总会预测错误。
实验结果大致如下，横纵坐标表示注入哪一个位，颜色代表预测错误率，深色意味着预测错误，也就是找到了一组异或关系：
其中有一些异或关系，因为对应的位在 index 中出现的缘故，导致没有显现出来。根据已知的异或关系外推，可以得到如下的 tag 计算公式：
那么，这里是怎么实现针对 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\)，我们需要进行三次分支的跳转：
经过计算，可以发现前两次跳转对 PHRT 的抵消，第二次跳转的 \(B[2]\) 与第三次跳转的 \(B[3]\) 抵消，最后相当于只有最后一次跳转的 \(B[2]=k\) 对 PHRB 产生了贡献。
最复杂的是 PC 的注入，这次需要分情况讨论：
第一种情况是，要注入的 PC 位比较高，具体来说，是 \(PC[7]\) 或者更高的位数，此时我们可以很容易地避免引入对 PHRB 的贡献，因为它只考虑 \(B[5:2]\)：
那么两次跳转完以后，PHRB 不变，PHRT 的贡献被抵消掉，同时实现了 \(PC[7]=k\) 的注入。
第二种情况是，要注入的正好是 \(PC[6]\)，继续用上面的方法会发现 PHRB 无法抵消，这时候，需要引入第三次跳转：
验算可以发现，PHRB 和 PHRT 的贡献全都被抵消，成功注入 \(PC[6]=k\)。
最后来看要注入的 PC 更低的情况，例如要注入 \(PC[3]=k\)，还是用三次跳转：
这样就成功注入 \(PC[3]=k\)。
那么 PC 的注入就完成了，只有 \(PC[2]\) 没有找到合适的方法来注入。
相连度和 tag 函数已知，接下来，让我们逆向工程最后的 index 函数。逆向工程的思路如下：
k xor l；注入 \(PC[9]\) 和 \(PHRT[i]\) 的实验结果如下：
结合上面的讨论，可以知道：
实际上还有 PHRT[7] 和 PHRT[48] 也在 index 中，但实际上测试的时候为了保证历史最长的表提供预测，还额外注入了 PHRT[99]，它与 PHRT[7] 和 PHRT[48] 有异或关系，所以在上图没有显现出来。
用类似的方法，去测试 PHRT 与 PHRT、PHRT 与 PHRB、PHRB 与 PHRB 之间的异或关系，就可以找到最终的 index 函数：
至此使用分支历史最长的表的逆向就完成了。接下来讨论一下，如何逆向工程分支历史更短的表。
前面提到，TAGE 在预测时，会选取提供预测的多个表中使用历史最长的那个表。那么，如果要测试使用历史第二长的表，应该怎么办呢？我们尝试了以下方法：
通过这些方法，我们成功地逆向出了 Firestorm 的剩下的 TAGE 表的信息：
有兴趣的读者可以试着自己复现一下，看看能不能得到对应的实验结果，然后从结果中分析出硬件的参数。有意思的是，我们逆向出来 Qualcomm Oryon 的分支预测器的大小（6 个表一共 80KB 的空间），与官方在 Hot Chips 上公开的是一致的。
我们通过一系列方法，实现了对 Apple M1 Firestorm 的条件分支预测器的逆向，并且成功地把它应用到了设计基本一样的 Qualcomm Oryon 处理器上，为后续的研究提供了基础。
2025-10-09 08:00:00
这个博客自 2014 年更新至今，已走过近十一个年头，累计发布了四百多篇文章。出于好奇，我一直想了解哪些内容更受读者欢迎。五年前，我曾配置过 Google Analytics，但使用体验并不理想，于是转而自行部署了 rybbit 实例来收集访问数据。如今三个月过去，是时候与大家分享一些有趣的发现。
P.S. 如果你对数据收集有所顾虑，可以屏蔽对应的 analytics 脚本。
首先来看这三个月内的整体访问情况与趋势：
访问量比我的预期要高一些。虽然这些年写了不少内容，但并没有刻意宣传，主要依赖搜索引擎推荐和读者的订阅与转发。从时间趋势上可以看出两个明显特点：
由此推测，学生读者占比较高。结合国庆假期访问量的下降来看，国内读者仍是主力。下面是各国家与地区的访问分布：
值得一提的是，也有不少海外读者访问，看来近年来有意识地撰写英文内容确实产生了效果。
以 UTC+8 时区为基准，从访问时间分布中可以看出大家的作息习惯：
尽管大家可能习惯熬夜，但深夜阅读博客的并不多，多数访问集中在工作时间。
接下来是基于 User Agent 的统计。首先是浏览器分布：
不出所料，Chrome 及基于 Chromium 内核的浏览器占据主流，Firefox 和 Safari 占比不高。我本人目前也在使用 Firefox，希望它能持续发展，避免 Chrome 一家独大。
操作系统分布如下：
Windows 占比最高，macOS 次之。考虑到博客内容主要涉及计算机技术，这也大致反映了相关从业人员的偏好。
以下是访问次数较多的几篇文章：
这个排名有些出乎我的意料。这几篇文章在撰写时并未特别考虑入门读者的理解难度或内容的丰富性。或许是因为它们涉及的领域资料较少，因此在相关关键词搜索中容易被找到。这一点在 Google Search Console 中也得到了印证：
相比之下，一些精心准备的文章阅读量并不高，可能是因为所在领域已有较多优质内容，新文章难以脱颖而出。这也说明文章质量与阅读量之间并非简单的正比关系。
我还注意到一些重度用户，他们不仅阅读多篇文章，且停留时间较长：
类似的例子还有不少，在此不一一列举。尽管 CPU 相关文章的阅读量不及软件类内容，但能得到这么多同行的关注，确实令人欣慰——毕竟这本身就是一个小众领域，不能奢求过高的阅读量。
通过这次数据分析，我收获了不少有趣的观察。未来可能会不定期更新类似内容，看看随着时间推移，是否会有新的发现。
最后，如果你对访问数据的收集感到不适，可以直接屏蔽 analytics 脚本（或许你的浏览器插件已经这样做了）。根据 rybbit 的官方说明，其信息收集方法较为尊重用户隐私，我也没有对代码进行任何修改，不放心的读者可以阅读 rybbit 的源码来审计。
P.S. 你能看出这篇文章是，我先写了一遍，然后让大模型润色的结果吗？
2025-09-10 08:00:00
ARM 公版核微架构的演进频繁，型号又比较多，相关信息散落在各种地方，为了方便查阅，在这里做一个收集。
>2x increase in SIMD/FP issue queuesI$, 8 instrs Mop$)I$, 9 cycles Mop$)i$, 5 instr from MOP$, Up to 1.5x improvement2025-07-08 08:00:01
在之前，我们分析了 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 的信息，例如：
在查询从 entrypoint2 开始的第一条分支指令的时候，如果使用当前 fetch block，就是用 entrypoint2 的地址去查询，那就必须等到前面 jmp entrypoint2 指令的目的地址被计算得出；如果使用之前 fetch block，就是用 entrypoint1 的地址去查询，不用等到 jmp entrypoint2 指令的目的地址被计算得出。因此，如果用之前 fetch block，可以更早地进行 BTB 的访问，从而减少 BTB 的延迟，或者在相同延迟下获得更大的容量。但是，代价是：
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：
相比 Zen 1 和 Zen 2 有比较大的不同：去掉了原来很小的 L0 BTB，扩大了 L1 BTB，同时延迟缩短了一个周期；虽然 L2 BTB 有所缩小，但是延迟也变短了一个周期。
下面结合微架构测试，进一步研究它的内部结构。
在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。
考虑到 Zen 3 的 BTB 可能出现一个 entry 保存两条分支的情况，并且还对分支的类型有要求，因此下面的测试都会进行四组，分别对应四种分支模式：
虽然 Zen 3 使用 previous fetch block 来访问 BTB，但在这几种分支模式中，使用 previous fetch block 还是访问 current fetch block，结果都是唯一的，所以并不会对结果带来影响。
首先是 stride=4B 的情况：
可以看到，图像上出现了三个比较显著的拐点：
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 的情况：
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=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=16B，L1 BTB 的行为没有变化，但是出现了一些性能波动。所有分支模式下，L2 BTB 的拐点都出现在 5120，但性能波动比较大，mix (cond + uncond) 模式下的 CPI 达到了 4.6。通过 BpDeReDirect 性能计数器的变化，可以确认这个拐点确实是来自于 L2 BTB 的缺失。
前面提到，译码器的纠正能力可能会给出错误的答案，在 stride=32B 时，就会出现一个很有意思的现象：
解释起来也并不复杂：stride=32B 的情况下，一个 64B cacheline 只有两条分支，那么：
顺带一提，uncond 模式下的 BpDeReDirect 占分支数量的接近 100%，cond 模式下的 BpDeReDirect 占分支数量的 0%，都是符合预期的。
继续观察 stride=64B 的情况：
相比 stride=32B，L1 BTB 的容量减半，达到了 512。之后出现了比较明显的性能波动，但四种分支模式下，拐点依然都是出现在 5120 条分支的位置。通过 BpDeReDirect 性能计数器的变化，可以确认这个拐点确实是来自于 L2 BTB 的缺失。由于 uncond 模式下，BTB sharing 不会工作，意味着 L2 BTB 至少有 5120 个 entry。
继续观察 stride=128B 的情况：
相比 stride=64B，L1 BTB 的容量进一步减小，达到了 256；L2 BTB 的性能依然波动剧烈，但四种分支模式下，拐点依然都是出现在 5120 条分支的位置。
考虑到 5120 这个拐点频繁出现，认为 L2 BTB 在不考虑 BTB entry sharing 的情况下，实际容量应该是 5120。那么剩下的 1536 个分支就是来自于压缩。
测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：
下面是对比表格：
| 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 都是在 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。
2025-07-08 08:00:00
在之前，我们分析了 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：
从表述来看，除了容量以外基本和 Zen 1 一致，猜测是在 Zen 1 的基础上扩大了容量。
下面结合微架构测试，进一步研究它的内部结构。
在之前的博客里，我们已经测试了各种处理器的 BTB，在这里也是一样的：按照一定的 stride 分布无条件直接分支，构成一个链条，然后测量 CPI。
考虑到 Zen 2 的 BTB 可能出现一个 entry 保存两条分支的情况，并且还对分支的类型有要求，因此下面的测试都会进行四组，分别对应四种分支模式：
首先是 stride=4B 的情况：
可以看到，图像上出现了三个比较显著的台阶：
和 Zen 1 不同，Zen 2 的 L1 BTB 出现了不同模式下容量不同的情况，原因未知，后续还会看到类似的情况。
Zen 2 的 L2 BTB 依然是带有压缩的，只有在 mix (cond + uncond) 模式下才可以尽可能地用上所有的容量，而其余的三种模式都有容量上的损失。
接下来观察 stride=8B 的情况：
现象和 stride=4B 基本相同，L1 BTB 从 256 到 512 部分的变化斜率有所不同，其余部分一致。
继续观察 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=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=32B，L0 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量进一步减到了 32，符合组相连的预期，但 cond 模式下依然保持了 512 的容量；L2 BTB 在 mix (cond + uncond) 模式下只能体现出 4096 的容量，此时每个 64B cacheline 都只有一条分支，不满足两条分支共享一个 entry 的条件。
继续观察 stride=128B 的情况：
相比 stride=64B，L0 BTB 的行为没有变化；除了 cond 模式以外，L1 BTB 的容量进一步减到了 16，符合组相连的预期，而 cond 模式下 L1 BTB 容量也减少到了 256；L2 BTB 的容量减半到了 2048，意味着 L2 BTB 也是组相连结构。
测试到这里就差不多了，更大的 stride 得到的也是类似的结果，总结一下前面的发现：
下面是对比表格：
| 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 都是在 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 上做了压缩，但是压缩的方法和目的不同：
二者都没有实现一个周期预测两条分支，即 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 允许这两个分支毫无关系。这就是不同厂商的取舍了。
