AI 时代的本科 CS 教育随想¶

背景¶

前几天参加了系里的关于 AI 时代的 CS 教育的研究生论坛，在论坛上我分享了一些小的思考，也在论坛上得到了许多不同的想法，于是把一些想法记录下来，过一段时间再回来看看，到底 CS 教育应该怎么办。

叠甲¶

本文仅代表本人观点，不代表本系或本校的观点，请勿扩大解读！请不要让我上 AI 三大顶会（机、量、新），谢谢！但欢迎大家参与到这个讨论当中，因为目前谁也不知道未来应该怎么做。

现状¶

为了让读者了解背景，首先要知道前 AI 时代的 CS 教育大概是怎样的：本科的时候先上编程课，教大家各种编程语言，然后逐渐深入到各个领域，课上讲授知识点，课下通过工程训练来夯实，由于计算机是工科，这里面通过不断的工程实践来获取经验，是很重要的一个部分。这一部分学习过程很辛苦，但是确实很有效果，可以说几乎每一位系友都是这么锻炼过来的。

下面这一段，如果你还在读本科，请不要点开，点开了也请忘掉，按照老师的要求去做：

但是，现在 AI 时代来临，很多事情都发生了变化。首先，AI 编程能力很强，大一同学辛辛苦苦学完一年，然后发现自己写的代码还不如 AI 写得好写得快，内心的挫败感和对这种古法编程的学习方法的质疑是无与伦比的。这对课程的教学产生了很大的冲击，因为人很难克制自己的懒惰，面对巨大的诱惑，其实很难静下心去学习这些已经由 AI 掌握的基础课程。论坛上有同学做了个比喻，计算器被发明了以后，人类没有失去心算的能力，因为你为了去用好计算器，还是要知道这些基础知识，从小学起，然后到某一个年级告诉你可以用计算器，然后各种考试还可以出计算器没法解决的题目。但是，AI 的能力边界太大了，它能解决从简单到困难的各种问题，只是有一定的概率解决出来是错的。其次，即使是前几年我们还会觉得，专业核心课的大作业还很难由 AI 完成，似乎还能通过大作业的难度来倒逼大家学习，但在今年也纷纷沦陷，对于学生来说，只要愿意，完全可以自己不写一行代码，纯让 AI 写一个能通过所有测试的作业，自己完全不了解内部是怎么实现的，用很短的时间完成作业。而且还不好去举证，说这一定是 AI 写的。这一点在这次论坛上，不同课程的助教都做了类似的实验，证明了这一点。虽然发这篇博客可能会让一些本科同学看到，然后不好好写大作业，但还是希望更多教育工作者可以看到并参与讨论。如果你是正在上课的同学，就自觉忘记吧。

怎么办¶

那么，应该怎么办呢？在这里阐述一些我的观点。一个大的前提是，肯定不能完全禁止 AI，也不能完全依赖 AI，需要辩证地把 AI 引入到 CS 教育当中。

首先是关于 CS 教育要培养出什么样的人才。之前，我们要培养的一方面是工程师，在长时间的工程实践当中积累经验，通过自己的经验，可以打造出一个很完备的系统，功能完善，可靠安全。但其实细分看来，在系统的搭建当中，其实有偏向于顶层设计的架构师，也有偏向于具体实现的工程师。目前 AI 已经可以很快地针对一个给定的 Plan 去做实现，并且实现得还不错，但是从需求到 Plan 的这一步，其实还需要人类的专家知识，因为实际的需求往往很复杂，会有许多大模型没有学过的假设与背景，这需要架构师脑子里把架构想清楚，知道哪里应该怎么做，然后把一部分的工程实现外包给 AI，自己再保证它的实现质量，确保它忠实地实现了所设计的架构，并且实现的系统是可靠安全的。用 AI 写代码很容易，但是写出来复杂可靠的软硬件系统，依然不是容易的事情。另一方面是科学家，在科研方面，科研的品味（Taste）变得更加重要，因为许多科研，其工程量本来就很小，完全可以由 AI 代劳，那么谁能够找到正确的路径，谁才能更好地与 AI 协作，完成科研。换句话说，以后的每个科研工作者，可能自己都是通讯作者，手下是一堆 AI 博士生在做实验，自己提出研究的思路，由 AI 实现和写作，然后自己来保证整个过程的正确性和学术伦理。无论是哪个方向，重点都从以前的知道某个东西“是什么”，变成了“为什么”，进而能够判断“对不对”。论坛上有同学总结得好，人类会更多地变成一个鉴别器（Discriminator）。

那么，具体到课程上，应该怎么做呢？其实我也没有想太明白，需要在未来几年里通过实践来不断修正。目前的一些初步的想法主要有下面这几点：

首先，作业已经不再能区分同学，不能代表同学对知识的掌握情况，只能代表 AI 对知识的掌握情况。所以作业已经完全沦为 AI 的课后送分小练习，在目前这个卷绩点的氛围下，让大家都开开心心地拿作业满分，也是越来越普遍了。如果真的想要通过作业来督促同学进行学习，那就必须回归作为人类的基本功，就是通过更多的线下的口语、展示和对话，以最“人味”的方式对抗 AI 的“机味”。事实上，在目前这个时代，其实如何扩大自己的影响力，也是很重要的技能，真的是酒香也怕巷子深，如何能够让大家看到你，抓住大家的注意力（Attention），很多时候会比你做出来的东西有多好更重要。这些能力，其实是值得通过作业的设计来培养的。我在本科的时候，尝试选了一次演讲的课程，当时看到作业要求，人直接麻了：需要每个人在班级所有人面前做演讲，这对于当时还比较社恐的我，由于太过害怕直接退课了。现在想想，其实都是小意思，当你迈出那一步以后，会发现懂得大大方方展示自己，真的是很重要的能力，是 AI 暂时还无法取代的能力。

既然作业沦陷了，那么，怎么打分呢？难道让每个人都能拿到满绩点？几年前，我在和大一新生聊天，他们就对这个打分的事情感到困惑，因为在目前这个绩点膨胀的时代里，好像很多课程拿满绩点都是天经地义的事情，如果你这个课不给我满绩点，我就要给你打教评低分。但是，又有不少东西和绩点挂钩，奖学金，保研等等。老师当然可以撒手不管，让所有人满绩点，但这只是让竞争延后、转化为其他领域了而已，不比绩点，那就比谁更能在本科的时候做科研，打比赛等等。另一方面，打分也是一个很重要的督促学习的手段，还是一样的前提，人类是很难抵抗自己的懒惰的，如果不是为了毕业以后有更好的发展，可能会有很多人放弃毕业、放弃学习。以前，为了能够顺利毕业，还会咬咬牙做一些比较困难的学习，甚至可能是自己不喜欢的；现在可以用 AI 糊弄了，那就糊弄过去，反正分数不错，能给父母交差，大环境也不好，然后就陷入了虚无主义，一泻千里。所以，似乎考试成为了最后的防线，还能在一定程度上督促学习。

但其实考试也受到了巨大的冲击。第一个问题就是，考试是否允许使用 AI 呢？许多 CS 课程，未来都会或多或少地引入一些 AI，那么学生对 AI 的掌握程度，也是一个需要考核的能力。但目前不同厂商的 AI 的可用性与性能差距过大，“AI 平权”会成为一个新的问题，我们希望比的是谁更会用 AI，而不是谁能用上更好的 AI。就像高考作文要考虑贫富差距一样，本科课程的考试也会面临类似的问题。一种可能性是在考试的时候提供统一的 AI 访问，但目前 AI 生态还是比较混乱，指定一个 AI 让大家用，其实也很容易出现与学生平时使用工具或生态不兼容的问题，而且学校自己部署一个同时几百上千人同时用的 AI 服务，也不是一件容易的事情，希望未来有云厂商可以提供类似的服务，并且能够控制住成本，其实就是一个持续两小时的上百 QPS 的专属推理服务。如果要类比的话，其他一些学科允许使用计算器，出题的时候可以规避，但 AI 能做的事情太杂了，其实很难针对。

另一方面，如果禁止 AI 的话，也有很多问题。首先是没法考察学生的 AI 使用能力，这个在未来会更加重要。其次，学生自己会比较难接受，先给了 AI 这么方便的工具，结果期末考试又要古法做一遍，最后结果可能就是学期中都在用 AI，只有考试前一周突击一下，考完就忘了，当然，好像现在很多人也是这样呢。而且课程很容易被贴上“不与时俱进”的标签，就如那些用十几年前课件的课程一样。现在这个过渡时期，大家都知道会变，但是怎么变并没有达成共识，所以一定会有一个阵痛期。如果你是刚上本科，或者马上要上本科的高中同学，那就要做好成为小白鼠的准备了。此外，随着本地模型的发展，如果让学生带电脑，即使不给联网，有更好的独立显卡的同学，事实上可以通过电脑配置的优势转化为分数，这也会带来新的不公平性。

当然，也不是毫无希望，比如前面说的，加一些有“人味”的考核，唯一的缺点是人力需求较大，难以扩展；或者允许使用 AI，但是必须提交完整的 AI 使用记录，这一点很多地方已经在实践；出题的时候，可能也要想办法去考察学生的思路，一些可以由 AI 完成的作业，不如就直接让学生用 AI 做，变成考察 AI 使用能力的题目。

讨论¶

以上基本是我在论坛上所展示的内容，下面也分享一些我在论坛上了解到的一些情况，以及所引发的思考。

首先，这次论坛不仅有大量的研究生助教参与，也有许多一线的教学老师参与了讨论。其实老师们感受到的冲击也很直接，因为可能就是从 2025-2026 开始，就有一批学生可以完全不接触古法编程，直接上手写代码，用一种完全不同的学习方法来学习各种课程内容。有的人可以很好地利用 AI 加速自己的学习，比如之前需要花费很多时间做的工程实践，现在可以在相同时间内用 AI 做更多的实践，一样可以获得很多甚至更多的实践经验。有的人就完全依赖 AI，可以糙快猛地完成很多事情，但对内部工作一概不知，能做的事情完全取决于 AI 的能力边界，同时自己又缺乏很多基础知识，可以说上知天文下知地理，但是四体不勤五谷不分。现在大家心里没底的就是，AI 的能力是否可以无限扩展，自己只需要站在 AI 的肩膀上，坐等 AI 发火箭上月球就行；还是需要脚踏实地，踩着地月天梯去月球。

咱也不知道答案，就在实践中前行吧。

AI 时代的本科（非 CS）教育随想¶

也顺带聊聊 CS 以外的教育吧，其实它们受到的冲击并不比 CS 少。但从某种意义来说，对于很多学科而言，AI 给每个人都带来了特别强大的工具，而且由于本来也不是学 CS 的，用 AI 能写出以前自己写不出来的代码，一下就把能力范围拓宽了。即便受到 AI 能力的限制，但反正自己也不是干这行的，本来也达不到那个上限，自然也就无所谓了。所以其实在 AI 时代，CS 以外的学科，都很值得学会怎么用 AI，给自己的学科赋能。比如论坛上有同学举了个例子，像写网站这种事，几天之内就能由来自不同学科、可能完全没有基础的同学，各自写出不同的校内交友相亲网站，而且还能让大模型帮忙做运维。好的想法、合适的商机、宣传和包装，这些才是更重要的，不用担心自己做不出来。

记一次软 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 分区缩容，这就需要：

1. 首先用 fsck -f /dev/md0 && resize2fs /dev/md0 newsize 对根分区进行缩容
2. 用 mdadm --grow --size=newsize /dev/md0 对 RAID 进行缩容
3. 停止 RAID：mdadm --stop /dev/md0
4. 重新分区，缩小 RAID 分区大小：cfdisk /dev/sda
5. 重新启动 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。

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

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

IBM POWER9 微架构评测¶

背景¶

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

官方信息¶

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

• IBM POWER9 processor core
• IBM Power9 Processor Architecture

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

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：

测试过程详见测试代码。

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 尝试，例如：

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

背景¶

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

背景知识¶

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

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

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

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

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

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

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

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

1. 确定分支历史的记录方式：通常涉及分支地址和目的地址，通过一系列移位和异或操作，将结果存储在寄存器中；
2. 确定 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}\) 能够记录多少条最近分支的历史。具体方法是构建一个分支历史序列：

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

接下来分析两种情况：

1. 如果在预测最后一个条件分支时，分支历史 \(\mathrm{PHR}\) 仍然包含第一个条件分支的信息，预测器应该能够准确预测最后一个条件分支的方向；
2. 如果中间的无条件分支数量足够多，使得第一个条件分支的跳转信息对预测最后一个条件分支时的 \(\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 条分支的历史信息。

分支地址 B 的贡献¶

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

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

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

对应的代码如下：

// 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}\) 的贡献，方法类似：

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

对应的代码如下：

// 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 上测试，得到如下结果：

// 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\) 的移位次数。这有两种可能：

1. 硬件上只有一个 \(\mathrm{PHR}\) 寄存器，\(T[31:2]\) 被异或到 \(\mathrm{PHR}\) 的低位，而 \(B[5:2]\) 被异或到 \(\mathrm{PHR}\) 的中间位置；
2. 硬件上有两个 \(\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 进行预测，那么一定会出现错误的预测。思路如下：

1. 用 100 个无条件分支，保证 PHR 变成一个确定的值；
2. 注入随机数 d % 2 到 PHRT，并移动到高位（例如 \(PHRT[99]\)），使用前面所述的方法；
3. 执行两个条件分支，它们在分支地址上只有一位 \(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 计算吗？

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

1. 首先执行一条间接分支，目的地址是 \(i2^{k-1}\)，那么它对 PHRT 的贡献是 \(\mathrm{PHRT}_1 = (\mathrm{PHRT}_0 \ll 1) \oplus (i2^{k-3})\)；
2. 接下来，在 \(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\) 足够小，也有办法：

1. 首先执行一条间接分支，目的地址是 \(i2^{k-1}\)；
2. 接下来执行大量的 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\)，我们需要进行三次分支的跳转：

1. 第一次跳转，\(B\) 相同，\(T[2]=k\)；
2. 第二次跳转，\(B[2]=k\)，\(T[3]=k\)；
3. 第三次跳转，\(B[2]=B[3]=k\), \(T\) 相同。

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

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

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

1. 第一次跳转，\(B\) 相同，\(T[6]=k\)；
2. 第二次跳转，\(B[6]=k\) 但对 PHRB 没有贡献，\(T[7]=k\)。

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

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

1. 第一次跳转，\(B\) 相同，\(T[3]=k\)；
2. 第二次跳转，\(B[3]=k\)，\(T[5]=T[4]=k\)；
3. 第三次跳转，\(B[4]=k\)，\(T[6]=k\)。

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

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

1. 第一次跳转，\(B\) 相同，\(T[2]=k\)；
2. 第二次跳转，\(B[2]=k\)，\(T[2]=T[3]=k\)；
3. 第三次跳转，\(B[3]=k\)，\(T[3]=k\)。

这样就成功注入 \(PC[3]=k\)。

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

逆向工程 index 函数¶

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

1. 通过前面的逆向工程，发现 \(PC[5:2]\) 是独立出现在 tag 函数中，并且没有出现在 index 中，所以我们可以构造出多个分支，它们的 tag 不同；
2. 进一步，构造两组条件分支，每组都有四个条件分支，因为是四路组相连，如果这两组分别映射到两个 set 中，就可以正确预测；反之，如果被映射到同一个 set 中，就会预测错误；
3. 和之前类似，向 PC、PHRB 或 PHRT 注入两个随机数 \(k\) 和 \(l\)，然后预测两组共八个条件分支，这些条件分支的跳转方向都是 k xor l；
4. 如果 \(k\) 和 \(l\) 注入的位同时出现在 index 函数中，但是没有异或关系，那么这八个条件分支可以正确地被预测；
5. 如果 \(k\) 和 \(l\) 注入的位同时出现在 index 函数中，并且有异或关系，那么这八个条件分支会被映射到同一个 set 内，最多只能正确预测其中四个分支；
6. 如果 \(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 处理器上，为后续的研究提供了基础。

引用文献¶

• Dissecting Conditional Branch Predictors of Apple Firestorm and Qualcomm Oryon for Software Optimization and Architectural Analysis
• Half&Half: Demystifying Intel’s Directional Branch Predictors for Fast, Secure Partitioned Execution

ARM 公版核微架构演进¶

背景¶

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

2025 年¶

C1¶

• 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 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
  • 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
• 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
• Arm® Cortex-X4 Core Technical Reference Manual

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¶

• Cortex X2: Arm Aims High
• Arm® Cortex®‑X2 Core Technical Reference Manual
• Arm Announces Mobile Armv9 CPU Microarchitectures: Cortex-X2, Cortex-A710 & Cortex-A510

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
• Arm Cortex-X1: The First From The Cortex-X Custom Program
  • 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 Core Technical Reference Manual

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 结构分析¶

背景¶

在之前，我们分析了 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 的对比¶

下面是对比表格：

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 发布的处理器，下面对它们进行一个对比：

虽然 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 结构分析¶

背景¶

在之前，我们分析了 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 的对比¶

下面是对比表格：

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

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

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

可见 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 允许这两个分支毫无关系。这就是不同厂商的取舍了。

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 的情况下就遗留了如下问题：

1. nano BTB 没表现出 96 的容量，只表现出接近 64 的容量
2. 没有观察到 2 predicted branches per cycle
3. 没有命中 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 的情况下就遗留了如下问题：

1. 没有命中 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 的情况下就遗留了如下问题：

1. 从 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 的情况下就遗留了如下问题：

1. 从 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 的情况下就遗留了如下问题：

1. 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 的情况下就遗留了如下问题：

1. 从 1024 条分支开始性能有略微的下降
2. 性能明显下降的点在 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。

下面是一个对比表格：

由此可以看出 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¶

背景¶

最近在研究鸿蒙电脑，群友 @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 测试结果：

• 6 核：Windows Single-Core 1436, Multi-Core 5296, Linux Single-Core 1500, Multi-Core 5699
• 8 核：Windows Single-Core 1462, Multi-Core 7043, Linux Single-Core 1489, Multi-Core 6076, Linux Single-Core 1503, Multi-Core 6289

如果没有 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。

融合开发引擎¶

2026/04/01 更新：《融合开发引擎》App 在应用市场的应用尝鲜上架，可以获得一个 Linux 环境，Linux 6.6.0 内核的 openeuler。使用可见网络上的视频 鸿蒙电脑官方欧拉虚拟机上线。想用 Debian 的话，也可以按照 HarmonyOS 6 Linux 容器替换成 debian trixie 换成 Debian。

终端模拟器的文字绘制¶

背景¶

最近在造鸿蒙电脑上的终端模拟器 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 大小来绘制。

参考¶

• Text Rendering - Learn OpenGL
• Text Rendering - WebRender

鸿蒙电脑 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。

融合开发引擎¶

2026/04/01 更新：《融合开发引擎》App 在应用市场的应用尝鲜上架，可以获得一个 Linux 环境，Linux 6.6.0 内核的 openeuler。使用可见网络上的视频 鸿蒙电脑官方欧拉虚拟机上线。想用 Debian 的话，也可以按照 HarmonyOS 6 Linux 容器替换成 debian trixie 换成 Debian。

外设¶

把 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 

未完待续¶

Intel Golden Cove 微架构评测¶

背景¶

前段时间测试了 AMD/Apple/Qualcomm/ARM 的处理器的微架构，自然不能漏了 Intel。虽然 Intel 已经出了 Redwood Cove 和 Lion Cove，但手上没有设备，而且 Golden Cove 也是“相对比较成功”（“缩缸的是 Raptor Cove，和我 Golden Cove 有什么关系，虽然其实 Raptor Cove 是 Golden Cove Refresh”）的一代微架构，用在了 Alder Lake 和 Sapphire Rapids 上，因此就来分析它，后续有机会也会分析一下对应的 E 核架构 Gracemont。

官方信息¶

Intel 关于 Golden Cove 微架构有这些官方的信息：

• Intel Alder Lake CPU Architectures
• Alder Lake Architecture on Hot Chips 33
• Sapphire Rapids on Hot Chips 33
• Intel 64 and IA-32 Architectures Optimization Reference Manual Volume 1

现有评测¶

网上已经有较多针对 Golden Cove 微架构的评测和分析，建议阅读：

• Popping the Hood on Golden Cove
• Golden Cove
• Golden Cove’s Vector Register File: Checking with Official (SPR) Data
• 4th Gen Intel Xeon Scalable Sapphire Rapids Leaps Forward
• Intel Details Golden Cove: Next-Generation Big Core For Client and Server SoCs
• Sapphire Rapids: Golden Cove Hits Servers
• Golden Cove’s Lopsided Vector Register File
• Indirector: High-Precision Branch Target Injection Attacks Exploiting the Indirect Branch Predictor

下面分各个模块分别记录官方提供的信息，以及实测的结果。读者可以对照已有的第三方评测理解。官方信息与实测结果一致的数据会加粗。

Benchmark¶

Intel Golden Cove 的性能测试结果见 SPEC。

前端¶

Fetch¶

官方信息：

• Legacy decode pipeline fetch bandwidth is increased from 16 to 32 bytes/cycle

Decode¶

官方信息：

• The number of decoders is increased from 4 to 6

DSB/uOP Cache¶

官方信息：

• The micro-op cache size is increased to hold 4,000 (注：应该是 4096) micro-ops,
• and its bandwidth is increased to deliver up to 8 micro-ops per cycle.

Intel 的 uOP(Micro-OP) Cache 称为 Decode Stream Buffer (DSB): Decode Stream Buffer (DSB) is a Uop-cache that holds translations of previously fetched instructions that were decoded by the legacy x86 decode pipeline (MITE).。

uOP Cache 的组织方式通常是组相连，每个 entry 保存了几条 uOP，这些 uOP 对应了原来指令流中连续的几条指令。

为了测试 uOP Cache 的大小，构造不同大小的循环，循环体是复制若干份的 add %%rsi, %%rdx 指令，最后是 dec + jnz 作为循环结尾，通过 IDQ.DSB_UOPS 性能计数器统计每次循环有多少个 uOP 来自于 DSB 也就是 uOP Cache，发现其最大值为 2800 左右，距离 4K 还有一定的距离。目前还没有找到一个可以稳定跑出 4K uOP 的指令模式，不知道遇到了什么瓶颈。

考虑到 taken branch 在典型的 uOP Cache 设计中会结束一个 entry，把循环体改成若干条 jmp 指令，并且每个 64B 缓存行只有一条 jmp 指令，此时每个 uOP entry 只记录一条 jmp 指令。观察到每次循环最多 512 个 uOP 来自 uOP Cache，那么 Golden Cove 的 uOP Cache 大概就是 512 个 entry。如果改成每 128B 缓存行只有一条 jmp 指令，uOP Cache 容量减少到 256 个 entry；继续增加间距，256B 间距对应 128 个 entry，512B 间距对应 64 个 entry，1024B 间距对应 32 个 entry，2048B 间距对应 16 个 entry，4096B 间距对应 8 个 entry，继续增大间距后，entry 数维持中 8 不再减少，意味着 Golden Cove 的 uOP Cache 是 8 Way 64 Set 一共 512 Entry，Index 是 PC[11:6]。

那么按照官方信息所说的 4K 容量，一共 512 个 Entry，那么每个 Entry 应该能够记录最多 8 个 uOP，这正好也对应上了 8 uOP 的吞吐。

根据前人在 Intel 比较老的微架构上的测试结果（见 The microarchitecture of Intel, AMD, and VIA CPUs）以及 Intel 的官方文档 Software Optimization Manual（这个文档把 uOP Cache 叫做 Decoded ICache），Intel 之前很多代微架构的 uOP Cache Entry 的构造条件是：

1. 每个 Entry 能记录的 uOP 个数有上限，最多 6 uOP/Entry
2. Entry 不能跨越 32B 边界，反过来，一个对齐的 32B 区间只能对应最多 3 个 Entry，结合第一条，就是对齐的 32B 块中不能超过 3*6=18 个 uOP（The Decoded ICache can hold only up to 18 micro-ops per each 32 byte aligned memory chunk）；如果指令跨了 32B 边界，它被算在后面那个 32B 里面
3. 指令需要完整地出现在一个 Entry 中：如果一条指令需要的空间太多，在当前 Entry 的剩余空间内放不下，就需要另起一个 Entry
4. 无条件跳转（或者被预测为要跳转）的指令会结束一个 Entry（each unconditional branch is the last micro-op occupying a Decoded ICache Way）
5. 比较大的立即数也会占用 uOP 空间，减少了实际能存放的 uOP 数量
6. 比较复杂的需要微码（Microcoded uops）的指令会占用一整个 Entry

下面来分析 Golden Cove 上这些构造条件是否有变化。参考 I See Dead µops: Leaking Secrets via Intel/AMD Micro-Op Caches 的方法，构造了一个循环，循环体由 4x 15-byte-nop + 1x 4-byte-nop 组成，这样的 5 条指令填满了对齐的 64B。在 Golden Cove 上测试，发现依然可以用满 512 个 Entry，假如 Entry 不能跨越 32B 边界，那么这 5 条指令至少就要 2 个 Entry，但实际上只用了 1 个 Entry。这说明 Golden Cove 上 uOP Cache Entry 的第一条限制中，Entry 不能跨越的边界，从 32B 扩大到了 64B，毕竟每个 Entry 能存的 uOP 数量也增多了，如果继续限制 32B，每个 Entry 就很难存满 8 个 uOP 了。接下来测试对齐的 64B 内可以最多有多少个 entry。

把循环体改成每对齐的 64B 就有四条 jmp 指令，前一条 jmp 指令跳转到后一条 jmp 指令，模拟每 64B 有四个 Entry 的情况：

1. 第 1 个 jmp 放在 64B 内的 0B 偏移处，跳转到 64B 内 16B 偏移处
2. 第 2 个 jmp 放在 64B 内的 16B 偏移处，跳转到 64B 内 32B 偏移处
3. 第 3 个 jmp 放在 64B 内的 32B 偏移处，跳转到 64B 内 48B 偏移处
4. 第 4 个 jmp 放在 64B 内的 48B 偏移处，跳转到下一个 64B 的开头

测试发现这个情况下能达到 512 个 Entry。说明对齐的 64B 内至少可以存 4 个 Entry。

进一步测试，如果每对齐的 64B 有五条 jmp 指令，模拟每 64B 有五个 Entry 的情况：

1. 第 1 个 jmp 放在 64B 内的 0B 偏移处，跳转到 64B 内 8B 偏移处
2. 第 2 个 jmp 放在 64B 内的 8B 偏移处，跳转到 64B 内 16B 偏移处
3. 第 3 个 jmp 放在 64B 内的 16B 偏移处，跳转到 64B 内 24B 偏移处
4. 第 4 个 jmp 放在 64B 内的 24B 偏移处，跳转到 64B 内 32B 偏移处
5. 第 5 个 jmp 放在 64B 内的 32B 偏移处，跳转到下一个 64B 的开头

发现最高的 Entry 数只有 480 左右，不确定是遇到了什么限制，如果对齐的 64B 内不能存 5 个 Entry，也不应该得到 480 这个结果。

如果单独去测试每个对齐的 64B 能缓存多少个 uOP，比如每个对齐的 64B 里由若干条 nop 加最后一条跳到下一个 64B 开头的 jmp 指令组成，会发现当对齐的 64B 内的 uOP 个数从 36 个变成 37 个时，uOP Cache 命中率急剧下降。这意味着，每对齐的 64B 内依然不能存超过 36 个 uOP。这类似于原来的每对齐的 32B 内不能存超过 18 个 uOP，但粒度更粗，实际上更加宽松，比如对齐的 64B 内的前 32B 可以全是 NOP 指令，只要 64B 内总数不超过 36 就可以。但比较奇怪的是，36 uOP per 64B 不能整除 8 uOP/Entry，不像原来的 18 per 32B 可以整除 6 uOP/Entry。

L1 ITLB¶

官方信息：

• the iTLBs is doubled to hold 256 entries for 4-KB pages and 32 entries for 2/4 million pages

构造一系列的 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 为周期），背后的原理需要进一步分析。

扩大 jmp 指令的距离再测试：

• 如果每 2/4 个 page 放一条 jmp 指令，容量不变还是 256 个 Page
• 如果改成每 8 个 page 一条 jmp 指令，容量下降到 32 个 Page
• 每 16 个 page 一条 jmp，容量下降到 16 个 Page
• 每 32/64/128 个 page 一条 jmp 指令，容量是 8 个 Page

从这个结果来看，L1 ITLB 对于 4K 页应该是 32 Set 8 Way。

L1 ICache¶

官方信息：

• 32KB

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

可以看到 footprint 在 32 KB 之前时可以达到 6 IPC，之后则降到 4 IPC，这里的 32 KB 就对应了 L1 ICache 的容量。

Return Stack¶

构造不同深度的调用链，测试每次调用花费的平均时间，得到下面的图：

可以看到调用链深度为 20 时性能突然变差，因此 Return Stack 深度为 20。

Instruction Decode Queue (IDQ) + Loop Stream Detector (LSD)¶

官方信息：

• The IDQ can hold 144 uops per logical processor in single thread mode, or 72 uops per thread when SMT is active.

Golden Cove 架构针对循环做了优化，Loop Stream Detector（简称 LSD）会检测当前指令流是否在一个循环当中，并且循环的 uop 不超出 Instruction Decode Queue(IDQ) 的容量，那么 LSD 会把 Legacy decode pipeline(MITE) 和 Decode stream buffer(DSB) 关掉，不再让 IDQ 的指令出队，而是直接在 IDQ 的内部循环提供指令，这个时候就节省了很多处理器前端的功耗。

为了测试 Instruction Decode Queue 的大小，构造不同大小的循环，循环体是复制若干份的 inc %rsi 指令，最后是 dec + jnz 作为循环结尾，通过 LSD.UOPS 性能计数器统计每次循环有多少个 UOP 来自于 Loop Stream Detector 机制，发现其最大值为 144，说明 Golden Cove 的 Loop Stream Detector 可以识别最多 144 个 uop 的循环。此时每个循环要执行 145 条指令，最后的 dec + jnz 被融合成了一个 uop。

循环体中，如果用 nop 指令来填充，会得到 40 左右的比 144 小得多的容量，猜测是进入了低功耗模式。

Conditional Branch Predictor¶

参考 Half&Half: Demystifying Intel’s Directional Branch Predictors for Fast, Secure Partitioned Execution 论文的方法，可以测出 Golden Cove 的分支预测器采用的历史更新方式为：

1. 使用 388 位的 Path History Register，每次执行 taken branch 时更新
2. 更新方式为：PHRnew = (PHRold << 2) xor footprint
3. 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]

这个结果和论文是一致的。各厂商处理器的 PHR 更新规则见 jiegec/cpu。

后端¶

Rename¶

官方信息：

• Rename/allocation width grows from 5 to 6 wide

Execution Units¶

官方信息：

• The number of execution ports goes from 10 to 12
• five LEA units as well as five integer ALUs
• three-cycle fast adders, with two cycles bypass between back-to-back floating-point ADD operations
• five alu/simd ports: 0/1/5/6/10
  • P0: ALU/LEA/Shift/JMP/FMA/ALU/Shift/fpDIV
  • P1: ALU/LEA/Mul/iDIV/FMA/ALU/Shift/Shuffle/FADD
  • P5: ALU/LEA/MulHi/FMA512/ALU/AMX/Shuffle/FADD
  • P6: ALU/LEA/Shift/JMP
  • P10: ALU/LEA
• 3 load ports: 2/3/11
• 2 store address ports: 7/8
• 2 store data ports: 4/9

LSU¶

官方信息：

• Port 11 provides a third load port with a dedicated address-generation unit
• Load 64Bx2 or 32Bx3 per cycle
• Store 64Bx2 or 32Bx3 per cycle
• The L1 load to use latency is 5 cycles

Load Store 带宽¶

针对 Load Store 带宽，实测每个周期可以完成：

• 3x 256b Load
• 2x 256b Load + 2x 256b Store
• 1x 256b Load + 2x 256b Store
• 2x 256b Store

因为测试环境是 Client 而非 Server，所以 AVX512 被屏蔽了，无法测试 AVX512 的读写带宽。此时最大的读带宽是 96B/cyc，最大的写带宽是 64B/cyc，二者不能同时达到。

Store to Load Forwarding¶

官方信息：

• Partial store forwarding allowing forwarding data from store to load also when only part of the load was covered by the store (in case the load's offset matches the store's offset)

经过实际测试，Golden Cove 上如下的情况可以成功转发，对地址 x 的 Store 转发到对地址 y 的 Load 成功时 y-x 的取值范围：

可以看到，Golden 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，也就是地址要一样，猜测 Golden Cove 使用了类似 Memory Renaming 的技术来实现这个效果。如果是连续两个对同一个地址的 Store 对一个 Load 的转发，效果和只有一个 Store 是一样的。

除了上述情况以外，Store Forwarding 成功时的延迟在 5 个周期，失败则要 19 个周期。

小结：Golden Cove 的 Store to Load Forwarding：

• 1 ld + 1 st: 要求 st 包含 ld，特别地，地址相同时，性能最好
• 1 ld + 2+ st: 不支持

L1 DCache¶

官方信息：

• 48KB

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

可以看到 48KB 出现了明显的拐点，对应的就是 48KB 的 L1 DCache 容量。第二个拐点在 384KB，对应的是 L1 DTLB 的容量。

L1 DTLB¶

官方信息：

• 96-entry 6-way 4-KB-page TLB
• 32-entry 4-way 2-MB/4-MB-page TLB
• 8-entry 1-GB-page TLB for loads
• A 16-entry TLB for stores serves all page sizes

用类似测 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 的损失。

L2 TLB¶

官方信息：

• 2,048-entry second level TLB (STLB)
• 4 page table walkers

沿用之前测试 L1 DTLB 的方法，把规模扩大到 L2 Unified TLB 的范围，就可以测出来 L2 Unified TLB 的容量，下面是 Golden Cove 上的测试结果：

第一个拐点是 96 个 Page，对应 L1 DTLB，此时 CPI 从 5 提升到 12；第二个拐点是 768，对应 L1 DCache，此时 CPI 从 12 提升到 23；第三个拐点是 1600 左右，而没有到 2048，猜测有 QoS 限制了数据对 L2 TLB 的占用。

L2 Cache¶

官方信息：

• 1.25MB(Client)/2MB(Server)
• 64 bytes/cycle
• 15 cycle latency

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

• 第一个拐点在 48KB，对应 L1 DCache 的容量，CPI 从 5 提升到 16
• 第二个拐点在 384KB，对应 L1 DTLB 的容量，CPI 从 16 提升到 23
• 第三个拐点在 1280KB，对应 L2 Cache 的容量

Prefetcher¶

官方信息¶

Intel Golden Cove 的处理器通过 MSR 1A4H 可以配置各个预取器（来源：Software Developers Manual，MSRs Supported by 12th and 13th Generation Intel® Core™ Processor P-core）：

• 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[5]: the L2 Adaptive Multipath Probability (AMP) prefetcher. 这个应该属于 Spatial 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.

预取延迟¶

在 Golden Cove 上按 64B 的跳步进行访存，测量每次访存的延迟，得到如下结果：

可以观察到在 48KB 之内是 5 cycle latency，在 L2 Cache 范围内是 5-8 cycle latency。

如果通过 wrmsr -p 0 0x1a4 0x8 把 DCU_IP_PREFETCHER_DISABLE 设为 1，即关闭 L1 data cache IP prefetcher，再在 0 号核心上重新跑上面的测试，得到如下结果：

就可以看到 L2 Cache 的范围内的性能退化到了 16 Cycle，和随机 pointer chasing 一样。关闭其他的 prefetcher 则没有这个现象，说明正是 L1 data cache IP prefetcher 实现了针对 L1 的 Stride Prefetcher。

预取距离¶

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

首先是只访问一个 cache line 的时候，可以看到，除了已经访问过的 cache line，其他 cache line 都出现了缓存缺失，说明此时预取器没有在工作：

接下来，按照固定的 stride 访问各个缓存行，发现当访问了五个 cache line 时，预取器会比较稳定地预取第六个 cache line：

继续增加访问次数，可以看到预取器总是会预取将要访问的下一个 cache line：

如果通过 wrmsr -p 0 0x1a4 0x8 把 DCU_IP_PREFETCHER_DISABLE 设为 1，即关闭 L1 data cache IP prefetcher，就会观察到上述 Stride 预取的行为消失，不会预取将要访问的下一个 cache line。

把相同的代码放到 Gracemont 上运行，会看到它的预取器会预取将要访问的未来两个 cache line：

可见不同微架构的预取器的策略是不同的。

ReOrder Buffer¶

官方信息：

• 512-entry reorder buffer
• 8 wide retirement

为了测试 ROB 的大小，设计了一个循环，循环开始和结束是长延迟的 long latency load。中间是若干条 NOP 指令，当 NOP 指令比较少时，循环的时候取决于 load 指令的时间；当 NOP 指令数量过多，填满了 ROB 以后，就会导致 ROB 无法保存循环末尾的 load 指令，性能出现下降。测试结果如下：

当 NOP 数量达到 512 时，性能开始急剧下滑，说明 Golden Cove 的 ROB 大小是 512。