1.3 指令集在软硬件分层中的坐标
1.3 指令集在软硬件分层中的坐标
本节摘要：本节回答"契约管到哪一层"：把软硬件栈从应用到晶体管摊开，标注 ISA 的管辖边界，并引入"架构行为与实现细节"这对全册反复出现的区分。读完你应当能在分层图上指出任意一个技术名词（缓存、寄存器重命名、虚拟内存）属于契约内还是契约外。
契约管到哪一层
一台计算机从上到下可以摊成许多层：应用程序、运行库、操作系统、编译器、指令集、处理器微架构、逻辑电路、晶体管。每一层都向上一层提供服务，向上层隐藏细节。ISA 恰好卡在正中间——它之下的一切被总称为"实现"，之上的一切被总称为"软件"。这个位置决定了指令集的根本性格：对下，它是硬件必须兑现的验收标准；对上，它是软件可以信赖的稳定地面。
用一张 ASCII 分层图把坐标钉死：
┌─────────────────────────────┐ │ 应用程序（浏览器/数据库/游戏） │ 只看见系统调用与库 ├─────────────────────────────┤ │ 运行库与编译器 │ 直接产出机器指令 ← 契约的使用方 ├─────────────────────────────┤ │ 操作系统 │ 管理特权级与内存映射 ← 契约的系统侧 ├═════════════════════════════┤ ◄ ISA 契约线：线以上只需认格式与语义 │ 处理器微架构（流水线/缓存/分支预测）│ 契约外的自由发挥区 ├─────────────────────────────┤ │ 逻辑电路与物理实现 │ 契约外 └─────────────────────────────┘
契约线以上的一切，只依赖两样东西：指令的编码格式，以及每条指令的语义承诺（做了什么、动了哪些状态、异常如何上报）。契约线以下怎么折腾——流水线几级、缓存多大、乱序窗口多深——软件一个比特都感知不到。理论上感知不到；实际上，性能差异和某些安全漏洞恰恰来自"理论上不可见"的那一侧，这个话题 5.4 节和 7.4 节会严肃对待。
架构行为与实现细节：一对关键区分
**架构行为（architectural state）**指契约承诺可见的东西：寄存器内容、内存内容、PC、标志位、异常响应。程序正确性只取决于架构行为。**实现细节（microarchitecture）**指兑现承诺的手段：你写 add rax, rbx，契约只承诺"下一条指令读到的 rax 是两者之和"，至于是组合电路一拍算完、还是拆成微操作排队三拍算完，架构不管。
这个区分直接解释了一个行业现象：同一条 x86-64 指令，在不同代际的处理器上性能天差地别。比如 popcnt（统计二进制位里 1 的个数）在某些代际的实现里与另一条指令共享执行单元，混排执行会意外减速；而契约完全相同的另一款芯片上它快如闪电。软件没变、语义没变，变的只是实现。反过来说，正因为实现可以自由演进，一份 1978 年定型的 8086 指令集才能在几十年间被重写了无数遍内部，性能翻了数千倍而旧程序照跑。
再看 RISC-V 的例子。RV32I 契约总共只有 47 条基础指令，但同一份契约上的实现从几十门的微型软核到乱序执行的高端核心都有。契约越小，实现的自由度越大——"最小契约 + 可选扩展"的思路在 8.3 节还会展开。
契约内外的边界案例
边界并不总是泾渭分明，几个著名案例值得专门记住。
**缓存是契约外的，缓存一致性是契约内的。**单核系统里，缓存对软件完全透明，写没写进去、何时写回主存，架构一概不答。可一旦多核共享内存，"我写了你何时能看见"就成了程序正确性问题，所以缓存一致性协议和内存序必须写进契约——第 6 章整章处理这件事。同一个部件（缓存），一侧在契约外、一侧在契约内。
分支预测器在契约外，分支的语义在契约内。"跳转指令必然改写 PC"是契约；"处理器偷偷猜方向"是实现。预测错了会怎样？架构必须保证结果与没猜过一样——这叫精确异常与序贯一致性的兜底。猜错造成的性能损失可以接受，猜错留下的微架构状态残留（比如缓存里多了几行被预测路径碰过的数据）本也该无人知晓，直到侧信道攻击证明"无人知晓"的高墙可以翻越。7.4 节的安全扩展，一半是为了重新砌墙。
**性能计数器在契约边缘。**很多处理器提供读取周期数、命中率的指令（如 x86 的 RDTSC），把它们摆上架构可见面。但计数器的精度、是否被虚拟化拦截、跨代如何变化，各家差异很大，所以严格说它们是"半契约"——存在格式化接口，语义却留了后门。写跨平台基准测试的人对此深有体会。
契约本身也会长大：扩展如何越线
坐标不是画完就一劳永逸的——契约本身会演化，而每次演化都要同时惊动契约线两侧。以 x86 加入 AVX-512 为例：新增 32 个 512 位寄存器，意味着架构可见状态凭空多出一大块。硬件先行支持了新寄存器还不够，操作系统必须在任务切换时把它们一并保存恢复，否则进程 A 用过的向量寄存器残留会被进程 B 读到——这是正确性事故，不是性能瑕疵。所以你会在 Linux 内核的提交记录里看到"为某扩展增加保存逻辑"的补丁：扩展加一组寄存器，内核就要跟一次。ARM 的 SVE、RISC-V 的 V 扩展同样如此。
这个现象反过来给了我们一把新的量尺：扩展越重，落地越慢。只加纯计算指令（比如几条加密加速指令）不需要动操作系统的状态管理，随驱动和应用更新就能普及；动架构状态的扩展（新寄存器、新模式、新异常级别）则要求固件、内核、虚拟机监控器全链条跟进，周期以年计。读 8.3 节 RISC-V 扩展生态时你会看到，哪些扩展遍地开花、哪些扩展蹒跚难行，背后多半是这把量尺在起作用。判定一条新指令是"轻扩展"还是"重扩展"，先问一句：它有没有把新的状态摆上契约可见面？
顺手排一个真实的排错场景。某团队的数值程序在两代处理器上输出不一致，第一反应是"撞上了硬件缺陷"。用坐标一查：两边编译选项不同，新机器上编译器默认启用了融合乘加（FMA），把两次舍入合并成一次，浮点结果自然不同。这不是实现出错，而是软件站在了不同的契约延伸面上——语义层面开启与关闭 FMA，结果就应一致。遇到"同程序不同跑"的问题，先分层归位：契约内的差异是缺陷，契约外的差异是配置，契约延伸面的差异是版本。三个筐一套，大半玄学立刻现形。
为什么这个坐标重要
判定边界的能力，会在三种场合直接变现。写高性能代码时：知道指令吞吐由契约外的实现决定，你就明白为什么"换一代 CPU 不改代码也能提速"，也会明白为什么指令数少不等于跑得快。排查诡异缺陷时：数据竞争、内存序问题属于契约内的正确性范畴，不能靠重试掩盖，必须按第 6 章的规则修；而缓存命中率低属于契约外的性能范畴，重试无害。读芯片手册时：标着"编程参考"的章节在讲契约，标着"优化建议"的章节在讲实现——把优化建议当正确性依赖写进代码，就是没分清坐标的典型事故。
问自己两个问题 → 定位任何技术名词 ┌───────────────────┬───────────────────┐ │ 问题一：程序能否直 │ 能 → 契约内（格式 │ │ 接观察或依赖它？ │ 与语义，跨实现不变） │ │ ├───────────────────┤ │ │ 否 → 契约外（实现 │ │ │ 细节，可随代际变化） │ └───────────────────┴───────────────────┘
本节要点回顾
- ISA 卡在软硬件栈正中：对上是稳定地面，对下是验收标准；契约线以上只认格式与语义。
- 架构行为与实现细节是全册的主轴区分：程序正确性只依赖前者，性能差异主要来自后者。
- 同一契约可以长出性能迥异的实现——这正是 x86 生态兼容与演进的全部秘密，也是 RISC-V 最小契约的立意。
- 边界案例要记牢：缓存透明但一致性入约；预测器入约外、分支语义入约内；性能计数器半契约。
- 判定口诀：程序能否直接观察或依赖？能则契约内，否则契约外。