💡 本文是《STM32内核精讲》栏目的第十五篇，也是第一阶段的收官之作。前十四篇我们深入学习了寄存器模型、异常处理、AAPCS、启动文件、低功耗、调试跟踪、内存屏障以及内核选型。本篇将聚焦于内核性能指标——CoreMark、DMIPS 的由来与测试方法，中断延迟的定义与实测，以及代码密度的对比。理解这些指标，你才能真正看懂芯片数据手册上的数字，做出有依据的选型决策。

---

📌 一、引言：数字背后的陷阱

当你翻开任何一款 Cortex‑M 芯片的数据手册，总会看到这样一串数字：“1.25 DMIPS/MHz”、“3.42 CoreMark/MHz”。这些数字看似客观，实则暗藏玄机——同一个内核，在不同编译器、不同优化选项、不同测试配置下，跑出来的分数可以相差数倍。

不懂这些指标的来历和测试方法，选型时就只能“比大小”，很容易被厂商宣传误导。本章将带你穿透这些数字，理解它们真正代表的含义。

---

📌 二、Dhrystone 与 DMIPS：一个 40 岁的“老将”

2.1 Dhrystone 的起源

Dhrystone 是由 Reinhold P. Weicker 在 1984 年 提出的一个基准测试程序，其主要目的是测试处理器的整数运算和逻辑运算性能。Dhrystone 程序最初用 Ada 语言发布，后来 Rick Richardson 为 Unix 开发了用 C 语言编写的 Version 1.1，这个版本推动了 Dhrystone 的广泛应用。Dhrystone 程序的最新版本是 1988 年更新的 Version 2.1。

2.2 DMIPS 的含义

Dhrystone 标准的测试方法很简单：单位时间内跑了多少次 Dhrystone 程序，其指标单位为 DMIPS/MHz。

• MIPS = Million Instructions Per Second（每秒百万条指令）
• DMIPS = Dhrystone MIPS，即在 Dhrystone 测试标准下的 MIPS 数值

DMIPS/MHz 这个比值消除了频率的影响，使得不同主频的处理器可以在同一尺度下比较。

2.3 Dhrystone 的局限性

Dhrystone 虽然历史悠久、应用广泛，但存在几个公认的缺陷：

1. 代码量小：整个测试程序规模有限，无法充分体现现代处理器的缓存、流水线等微架构特性。
2. 容易被“优化”：编译器可以通过内联、循环展开等手段大幅“优化”Dhrystone 的得分，使得同一硬件在不同编译器下分数差异巨大。
3. 与实际应用脱节：Dhrystone 的测试负载与真实嵌入式应用场景差异较大，高分不一定代表实际性能好。

正因如此，CoreMark 在 2009 年应运而生，逐渐取代 Dhrystone 成为嵌入式领域的主流性能基准。

---

📌 三、CoreMark：更现代的嵌入式性能基准

3.1 CoreMark 的诞生

CoreMark 由 EEMBC（嵌入式微处理器基准评测协会） 的 Shay Gal-On 开发，1.0 版本于 2009 年 6 月 1 日正式发布。EEMBC 是一个非营利性组织，目前共发布了 46 个性能测试基准，CoreMark 被认为是比陈旧的 Dhrystone 标准更有实际价值的测试基准。

CoreMark 的源代码可以从 www.coremark.org 免费下载，EEMBC 鼓励所有用户在网站上提交他们的分数和平台配置。

3.2 CoreMark 的测试内容

CoreMark 程序使用 C 语言编写，包含以下四种核心算法：

算法	说明
列举（List）	寻找并排序，测试链表操作性能
矩阵运算（Matrix）	普通矩阵运算，测试数学计算性能
状态机（State Machine）	确定输入流中是否包含有效数字
CRC（循环冗余校验）	测试数据校验和计算性能

这些算法涵盖了嵌入式系统中常见的数据结构操作、数学计算、状态管理和数据校验，比 Dhrystone 更贴近实际应用场景。

3.3 CoreMark 的测试方法

CoreMark 标准的测试方法很简单：在某配置参数组合下单位时间内跑了多少次 CoreMark 程序，其指标单位为 CoreMark/MHz。CoreMark 数字越高，意味着性能更高。

移植要点：如果将 CoreMark 移植到 ARM Cortex-M 平台下裸系统运行，一般只需要修改 \barebones 目录下的文件即可（仅需改动三个函数：portable_init()、barebones_clock()、uart_send_char() 以及 core_portme.h 中的若干宏定义）。

3.4 CoreMark 与 DMIPS 的对比

维度	Dhrystone (DMIPS)	CoreMark
提出时间	1984 年	2009 年
测试内容	整数/逻辑运算	链表/矩阵/状态机/CRC
代码规模	较小	较大
抗优化能力	较弱	较强
与实际应用相关性	较低	较高
当前地位	历史标准，仍在用	主流标准

---

📌 四、Cortex‑M 各内核的典型性能数据

以下是 ARM 官方和各厂商公布的 Cortex‑M 各内核典型性能数据：

内核	架构	DMIPS/MHz（典型值）	CoreMark/MHz（典型值）
M0	ARMv6‑M	0.96	2.33
M0+	ARMv6‑M	0.95	2.46
M3	ARMv7‑M	1.25	3.32
M4	ARMv7E‑M	1.25	3.42
M7	ARMv7E‑M	2.14	5.29
M23	ARMv8‑M BL	0.87	2.5
M33	ARMv8‑M ML	1.5	4.2
M55	ARMv8.1‑M	1.6	4.3
M85	ARMv8.1‑M	3.13	6.28

数据说明：

• M0：ARM 官方公布为 0.96/1.19/1.91 DMIPS/MHz（三组不同编译配置），表格取典型值 0.96。
• M0+：ARM 官方公布为 0.99/1.30/2.58 DMIPS/MHz（三组不同编译配置），表格取典型值 0.95。
• M7：ST 官方公布为 2.14 DMIPS/MHz 和 5.29 CoreMark/MHz。
• M23：ARM 官方公布为 0.87/1.13/2.32 DMIPS/MHz（三组不同编译配置），表格取典型值 0.87。
• M85：ARM 官方公布为 3.13/4.52/8.76 DMIPS/MHz（三组不同编译配置）和 6.28 CoreMark/MHz。
• M55：ARM 官方公布为 1.69/2.16/5.32 DMIPS/MHz（三组不同编译配置），表格取典型值 1.6。

⚠️ M33 的重要说明：M33 的 CoreMark 得分受 TrustZone 配置 影响。不使能 TrustZone 时约为 4.2 CoreMark/MHz；使能 TrustZone 时可能降至约 3.8-4.0，与 M4 的差距缩小。选型时需根据实际安全配置评估性能。

关于 DMIPS 的多组数据：ARM 官方为每个内核提供了三组 DMIPS 数据：

• 第一组：严格遵守 Dhrystone 文档的所有规则
• 第二组：允许函数内联（inline）
• 第三组：允许多文件同时编译（multi‑file compilation）

这三组数据对应不同的编译优化策略，差异可达数倍。这就是为什么你在不同地方看到的同一内核 DMIPS 数值可能完全不同——它们使用的是不同的编译配置。

---

📌 五、中断延迟：实时系统的生命线

5.1 中断延迟的定义

中断延迟（Interrupt Latency） 是指从中断请求（IRQ）信号置起开始，到内核进入执行该中断 ISR 第一条指令时的时钟周期数。

IRQ 信号置起 → 硬件压栈 → 取向量 → 执行 ISR 第一条指令
|<-------------- 中断延迟 ---------------->|

在实际系统中，中断延迟通常以时钟周期为单位测量，也可以根据系统时钟频率换算为微秒（μs）。

5.2 影响中断延迟的因素

中断延迟并不是一个固定值，它受多个因素影响：

1. 当前执行的指令：如果中断发生时正在执行一条长指令（如除法指令），处理器可能需要等待当前指令完成才能响应。不过 Cortex‑M 会放弃正在执行的除法指令去响应中断，返回后再重新执行。
2. 中断嵌套：如果已经有一个中断正在执行，新来的低优先级中断必须等待。
3. 存储器等待状态：如果 Flash 或 RAM 有等待周期，压栈和取向量会增加延迟。
4. 尾链（Tail‑Chaining）和晚到（Late‑Arriving） ：这些机制可以减少连续中断的处理延迟。

5.3 Cortex‑M 各内核的中断延迟

在零等待存储器系统中，Cortex‑M 各内核的典型中断延迟如下：

内核	中断延迟（周期）	说明
M0	15 周期	最高优先级中断，零等待系统
M0+	15 周期	最高优先级中断，零等待系统
M3	12 周期	零等待系统
M4	12 周期	零等待系统
M7	12 周期（缓存命中时）	缓存未命中时可能增加至 14 周期或更多

尾链（Tail‑Chaining） 可以将连续中断的处理延迟降低到 6 周期。当两个中断连续发生时，硬件跳过出栈和重新压栈，直接进入下一个中断处理程序。

5.4 中断延迟的实测方法

在实际硬件上测量中断延迟，常用的方法有：

1. 使用 DWT 性能计数器：在 ISR 入口读取 DWT_CYCCNT（地址 0xE0001004），与触发中断前记录的值相减。
2. 使用 GPIO 翻转法：在 ISR 入口翻转 GPIO 引脚，用示波器测量从触发到翻转的时间。
3. 使用 SysTick 定时器：在中断发生前启动 SysTick，ISR 中读取当前值。

注意：Cortex‑M 的某些仿真模型（如 FVP）不支持 DWT，此时需要使用 SysTick 或其他计时手段。

---

📌 六、代码密度：Thumb vs ARM 的持久战

6.1 Thumb 诞生的背景

早期的 ARM 处理器（如 ARM7、ARM9）使用 32 位固定长度指令（ARM 指令集），功能强大但代码密度低——嵌入式系统的 Flash 空间有限，32 位指令浪费存储资源。

为了提升代码密度，ARM 在 1990 年代中期推出了 Thumb 指令集：将大部分指令压缩为 16 位。Thumb 代码相比等效的 ARM 代码，可以减少约 30% 的代码体积。

6.2 Thumb‑2：16/32 位混合的折中方案

Cortex‑M 处理器只支持 Thumb 指令，不支持原始的 32 位 ARM 指令集。但 Thumb 本身经历了演进：

• 原始 Thumb：全部 16 位指令，功能有限。
• Thumb‑2：16/32 位混合指令，没有模式切换，处理器自动识别指令宽度。

Thumb‑2 的设计目标是在保持 Thumb 代码密度的同时，达到接近 ARM 指令集的性能。事实证明这个目标基本达成——Thumb‑2 代码体积远小于 ARM 32 位代码，性能损失控制在 1-2% 以内。

6.3 代码密度对比的实际意义

对于嵌入式系统，代码密度直接影响：

• Flash 容量需求：更高的代码密度意味着可以用更小的 Flash 完成同样的功能，降低芯片成本。
• 功耗：更少的 Flash 访问意味着更低的功耗。
• 缓存效率：在带缓存的 Cortex‑M7 上，更高的代码密度意味着缓存命中率更高。

实际对比：ARM 的研究数据显示，Thumb 指令集的平均代码体积比 ARM 32 位指令集 小约 30%。这正是 Cortex‑M 在嵌入式领域占据主导地位的重要原因之一——用更少的 Flash 空间实现更多的功能。

6.4 为什么 Cortex‑M 不支持原始 ARM 指令？

• 硬件简化：只实现 Thumb 解码器，节省芯片面积和功耗。
• 代码密度：Thumb‑2 的性能已经足够，且代码密度更高。
• 模式统一：无需在 ARM 和 Thumb 状态之间切换（早期的 ARM 处理器需要通过 BX 指令切换状态）。

---

📌 七、总结

7.1 本篇核心要点

1. DMIPS 来自 1984 年的 Dhrystone 基准测试，单位为 DMIPS/MHz。优点是历史悠久、数据丰富；缺点是代码量小、容易被优化、与实际应用脱节。
2. CoreMark 由 EEMBC 的 Shay Gal-On 开发，1.0 版本于 2009 年 6 月 1 日正式发布，单位为 CoreMark/MHz。测试内容包括链表、矩阵、状态机、CRC 四种算法，更贴近嵌入式实际应用，已成为主流性能基准。
3. DMIPS 的多组数据：ARM 官方为每个内核提供三组 DMIPS 数据（严格规则、允许内联、多文件编译），差异可达数倍。看到 DMIPS 数值时，务必确认其编译配置。
4. 中断延迟 是实时系统的关键指标。Cortex‑M3/M4 在零等待系统中可达 12 周期，M0/M0+ 为 15 周期，尾链可将连续中断延迟降至 6 周期。M7 在缓存命中时同样为 12 周期，缓存未命中时可能增加至 14 周期或更多。
5. 代码密度：Thumb 相比 ARM 32 位指令集可减少约 30% 代码体积。Cortex‑M 只支持 Thumb/Thumb‑2，性能损失控制在 1-2% 以内，这是嵌入式领域的明智选择。

7.2 下篇预告：《第二阶开启 —— 深入运行机制》

从下一篇开始，我们将进入专栏的第二阶段——进阶原理。我们将深入 NVIC 的高级话题、HardFault 故障分析、PendSV 与上下文切换、MPU 内存保护单元等更深入的内核机制。

---

💬 读者问题专栏 · 问题征集

你在评估处理器性能或实测中断延迟时，是否遇到过：

• 同一款芯片在不同编译器下 CoreMark 分数差异巨大？
• 想实测中断延迟，但不知道从哪里入手？
• 在选型时不知道应该看 DMIPS 还是 CoreMark？
• 代码密度对实际项目的影响有多大？

欢迎留言，我会在 《Cortex‑M 有问必答》 中专题解答。

---

📢 关于作者与更多内容

我是 BackCatK Chen，长期关注嵌入式底层、国产半导体与 AI 算力芯片。

如果你对芯片架构、行业趋势感兴趣，欢迎关注我的公众号，获取更多宏观技术观察。

---

文章标签：Cortex-M CoreMark DMIPS Dhrystone 中断延迟 代码密度 Thumb 性能指标