[i=s] 本帖最后由 kai迪皮 于 2025-7-14 20:58 编辑 [/i]<br /> <br />

1.?背景

在?Arm?处理器的大家族中，Cortex-A?系列因其高性能、高主频常被用于智能手机、平板电脑或高端应用处理器。而在以嵌入式、物联网为主的?Cortex-M?系列中，“低功耗、成本敏感、实时性”是更重要的需求。如果在?Cortex-M?设备上做大量数字信号处理、机器学习，过去往往只能依赖：

0. 标量浮点单元(FPU)：一次只能对一个浮点数做运算；
1. 一些编译器层面的?loop-unrolling、优化，让标量运算稍微提速；
2. 若需要真正的?SIMD?并行，则很难在?Cortex-M?里找到现成的硬件方式。

然而，Arm?在?2020?年左右推出了“Helium”——这是一套专门面向?M?Profile?的向量扩展（MVE，M-Profile?Vector?Extension）。它为像?Cortex-M52、M55、M85?这样的内核带来了真正的?SIMD?特性，使得一次加载可处理?4?个?32?位浮点数或更多定点数据，并且提供了丰富的指令（vld/vmul/vadd/vsub/vst等）。这样，一颗Cortex-M?MCU就能接近?Cortex-A?上?Neon?指令那种“单指令多数据”的高并行度，极大提升处理效率。

2.?为什么不直接把Neon搬过来？

谈到?SIMD?并行，大家或许首先想到的是?Neon?指令集——Neon?在Cortex-A及部分Cortex-R处理器里十分常见，广泛用于多媒体、图像视频处理和机器学习。那为何?Arm?不把?Neon?直接塞进?Cortex-M?就完事了？

2.1?Neon?是什么？

Neon?是?Arm?针对?Cortex-A（以及部分?Cortex-R）推出的?SIMD?指令集，用于如手机?SoC?的多媒体、图像/视频处理、机器学习推理等繁重运算。Neon?要求较大的硬件和寄存器资源，且通常在运行?Linux/Android?这类操作系统的平台上，能充分发挥高吞吐率、多线程流水线调度的优势。

2.2?Helium（MVE）为何另起炉灶

Cortex-M?作为?MCU，面积更小、功耗更低、且对实时中断响应要求严苛。如果把?Neon?全搬过来，可能会带来：

??资源占用和成本显著增加； ??功耗不符合?MCU?级需求； ??复杂的流水线与中断机制可能冲突。

因此，Arm?重新定义了更“轻巧”的向量扩展——Helium?(MVE），在保留?SIMD?并行优势的同时，兼顾?Cortex-M?的低功耗与实时特质。

2.3?Helium?与?Neon?的相似与差别

• 相同点：
• 都是?128-bit?SIMD；
• 都能批量处理多路数据，如同时处理?4?个?float；
• 指令类型相似，如?vld、vst、vmul、vadd?等。
• 不同点：
• Helium?更贴合?M?Profile?的堆栈、上下文切换；
• 使用谓词寄存器（tail?predication），方便应对剩余元素不整除的情形；
• 面向低功耗与小型?MCU?环境进行了特殊优化。

总的来说，Neon?面向“大块头”的?Cortex-A，而?Helium?（MVE）?为“小巧”的?Cortex-M52?或?M55?等内核而生。二者血脉相承，却分工不同。

3.?设置应用场景：基于矩阵元素运算

为了让?Helium?的效果更直观，我们选了一个常见场景：对矩阵（或向量）里每个元素做运算，比如：

• 元素自乘：A[i]?=?A[i]?×?A[i]；
• 两个矩阵?A[i]?与?B[i]?对应元素相乘，写入?C[i]；
• A[i]?=?scaleFactor?×?A[i]?等缩放操作。

这些“逐元素乘法”在图像滤波、音频处理、神经网络激活函数中常见。若矩阵规模较大，仅靠标量?FPU?循环就会效率偏低；如果能同时处理?4?个浮点数，就能让【总循环数】大幅减少，真正凸显?SIMD?并行优势。

3.1?代码层面：两个版本的对比目标

我们将在下文分别展示：

• 标量版本（FPU?模式）：朴素的?while?循环，每次只乘?1?个数；
• MVE?向量版本：手写?Helium?Intrinsics，让编译器明确生成向量指令。

通过编译并在?G32R501?上实际运行，我们能清晰看到这两种方法在不同时期、不同编译优化条件下的性能表现。

4.?代码实现

在CMSIS-DSP库里，你可能会看到类似下面的函数原型“arm_mult_f32”。这里我们把arm_mult_f32拆分成两个函数以便可以同时在G32R501平台上运行：?arm_mult_f32_fpu?与?arm_mult_f32_mve。

在正式开始我们的测试之前，我们要安装好CMSIS-DSP?pack，里面有一些我们所使用到的内容，我们引用该pack可以让我们少做很多“轮子”。

4.1?标量循环：arm_mult_f32_fpu

这是一个常见的写法：在?while?循环里，每次取一个元素做乘法，然后放回结果数组。这个函数对编译器而言信号很明确：它是标量运算，没有使用SIMD?指令。

ARM_DSP_ATTRIBUTE void arm_mult_f32_fpu(
 const float32_t * pSrcA,
 const float32_t * pSrcB,
    float32_t * pDst,
    uint32_t blockSize)
{
  uint32_t blkCnt; /* Loop counter */

  blkCnt = blockSize;
  while (blkCnt > 0U)
  {
    *pDst++ = (*pSrcA++) * (*pSrcB++);
    blkCnt--;
  }
}

在日常开发中，这种循环最常见：灵活、好理解。不过一旦数据规模变大，就可能遇到性能瓶颈。

4.2?MVE向量循环：arm_mult_f32_mve

Helium?里一次能处理?128?bits，也就是?4?个?32?位浮点数。这里我们利用了?MVE?提供的?C?intrinsics，明确告诉编译器要走向量化指令：

ARM_DSP_ATTRIBUTE void arm_mult_f32_mve(
 const float32_t * pSrcA,
 const float32_t * pSrcB,
    float32_t * pDst,
    uint32_t blockSize)
{
  uint32_t blkCnt; /* Loop counter */

  f32x4_t vec1;
  f32x4_t vec2;
  f32x4_t res;

  /* Compute 4 outputs at a time */
  blkCnt = blockSize >> 2U;
  while (blkCnt > 0U)
  {
    vec1 = vld1q(pSrcA);   // load 4 floats from pSrcA
    vec2 = vld1q(pSrcB);   // load 4 floats from pSrcB
    res = vmulq(vec1, vec2); // vector multiply
    vst1q(pDst, res);     // store 4 results

    pSrcA += 4;
    pSrcB += 4;
    pDst += 4;
    blkCnt--;
  }

  /* Tail: handle leftover if not multiple of 4 */
  blkCnt = blockSize & 0x3;
  if (blkCnt > 0U)
  {
   mve_pred16_t p0 = vctp32q(blkCnt);
   vec1 = vld1q(pSrcA);
   vec2 = vld1q(pSrcB);
   vstrwq_p(pDst, vmulq(vec1, vec2), p0);
  }
}

一次性能处理4个浮点数据，不再是单条标量指令。最大好处：缩减循环迭代次数，编译器也不用猜测你是不是想要?SIMD——代码里就是实打实的向量指令。

5.?测试数据：无优化→-Ofast，一步步见证性能悬殊

接下来我们在?G32R501（支持?Helium）上，用?blockSize=192?做了三组实验。编译器为?armclang，重点考察“标量函数?vs.?显式?MVE?函数”的实时性能（CPU?cycles）。

5.1?场景一：无优化?(-O0)

如果我们把编译优化关掉，或者保持低级别，让编译器不做自动向量化，那就能观察到纯“显式向量”VS.“标量循环”的对比。

大致结果如下：

• MVE?版（arm_mult_f32_mve）约?3209?cycles
• 标量版（arm_mult_f32_fpu）约?5021?cycles
• 速度比?=?5021?/?3209?≈?1.56

可以明显看出，显式向量化要比标量快?50%?以上。这也是?SIMD?并行的直观魅力——一次指令并行处理多个数据，循环次数减少。

5.2?场景二：-Ofast?最高优化

当我们切换到?-Ofast?编译等级时，编译器会尽可能地利用各种高级别优化。

结果如下：

• MVE?版：约?544?cycles
• 标量版：约?551?cycles
• 速度比?=?1.01

不可思议的是，这时标量循环已经能做到几乎和显式MVE一样快。二者仅差?7?个周期，几乎可以当作持平。这跟我们在无优化时看到的?1.56?倍差距完全不一样。难道说?Helium?自己失灵了吗？还是标量浮点爆发了？

我们深究一下，看看汇编代码的情况。我们通过使用 fromelf --text -c -o "$L@L.asm" "#L" 查看反汇编代码（设置完毕后重新编译一次代码）：

我们发现编译器把?arm_mult_f32_fpu?生成了包含向量操作的函数，出现了vmul.f32这种操作。

  arm_mult_f32_fpu
    0x00002298:  b580    ..   PUSH   {r7,lr}
    0x0000229a:  f24310c0  C...  MOVW   r0,#0x31c0
    0x0000229e:  f2403100  @..1  MOVW   r1,#0x300
    0x000022a2:  f2c00000  ....  MOVT   r0,#0
    0x000022a6:  f2c20100  ....  MOVT   r1,#0x2000
    0x000022aa:  1a08    ..   SUBS   r0,r1,r0
    0x000022ac:  2810    .(   CMP   r0,#0x10
    0x000022ae:  d212    ..   BCS   0x22d6 ; arm_mult_f32_fpu + 62
    0x000022b0:  f04f0ec0  O...  MOV   lr,#0xc0
    0x000022b4:  f2403000  @..0  MOVW   r0,#0x300
    0x000022b8:  f24311c0  C...  MOVW   r1,#0x31c0
    0x000022bc:  f2c20000  ....  MOVT   r0,#0x2000
    0x000022c0:  f2c00100  ....  MOVT   r1,#0
    0x000022c4:  ecb10a01  ....  VLDM   r1!,{s0}
    0x000022c8:  ee200a00   ...  VMUL.F32 s0,s0,s0
    0x000022cc:  eca00a01  ....  VSTM   r0!,{s0}
    0x000022d0:  f00fc009  ....  LE    lr,{pc}-0xc
    0x000022d4:  e00e    ..   B    0x22f4 ; arm_mult_f32_fpu + 92
    0x000022d6:  f24312c0  C...  MOVW   r2,#0x31c0
    0x000022da:  20c0    .    MOVS   r0,#0xc0
    0x000022dc:  f2c00200  ....  MOVT   r2,#0
    0x000022e0:  f020e001   ...  DCI.W  0xf020e001 ; ? Undefined
    0x000022e4:  ecb21f04  ....  LDC   p15,c1,[r2],#0x10
    0x000022e8:  ff000d50  ..P.  VMUL.F32 q0,q0,q0
    0x000022ec:  eca11f04  ....  STC   p15,c1,[r1],#0x10
    0x000022f0:  f01fc009  ....  LETP   lr,{pc}-0xc
    0x000022f4:  bd80    ..   POP   {r7,pc}
    0x000022f6:  0000    ..   MOVS   r0,r0

可见不再是简单“FMUL?+?store”的标量操作，而是经过编译器一番“整容”式的高级编译，使得和MVE（其实已经是使用MVE指令了）的实现在周期数上拉近差距，也就出现了1.01的差异。

5.3?场景三：禁止自动向量化

了更好地对比，我们可以把?arm_mult_f32_fpu.c?放到单独的编译命令并指定 -mcpu=cortex-m52+cdecp0+nomve选项，从而强行禁止编译器对那段标量循环进行自动向量化。也就是让它只能走单浮点?FMUL?+?store?的老路。

再测试，得到：

• MVE?版：?544?cycles（和上一场景相同）
• 标量版（禁止自动向量化）：?817?cycles
• 速度比?=?817?/?544?≈?1.50

和前面无优化时的1.56差不多，再度证明如果不自动向量化，标量写法就没那么“神速”。

总结起来，我们通过这几步观察，就得到了非常有意思的结论：在?-Ofast?等较高优化等级下，编译器会自动分析循环并进行向量化（auto-vectorization），使得“标量函数”也变得和手动MVE版本几乎同等效率。

6.?总结

G32R501?作为支持?Helium?的代表之一，不仅仅是“功能上多了几条指令”，而是提供了充分的浮点（或定点）向量化能力、并且在相同主频下大幅提升数据吞吐。同时?Arm?在?CMSIS-DSP?库做了大量支持，可以直接调用现成的?API?做滤波、变换、统计等。这些?API?底层就已经根据宏定义自动用上?MVE?指令，可以让开发者几乎“零门槛”地享受向量化红利。

另外我们不需要过分担忧编译器不会向量化，只要数据结构和循环逻辑比较“干净”，-Ofast?就能把它变成并行处理。

所以，可以说在?G32R501?这类具备?Helium?指令集的?MCU?工程里，你不用担心“写不写?Intrinsics”的问题。只要你选对了编译选项（?-Ofast?），就能享受到自动向量化的便利。如果你想要在某些关键环节进一步控制指令、管理缓存或内存对齐，可以再去写手工?intrinsics。可总结为：“能手写就手写，更有逼格；懒得管就让编译器替你搞定，也完全可行！”

这里是代码： 附件：g32r501_driverlib_mve.zip（解压至 G32R501_SDK_V1.1.0\driverlib\g32r501\examples\eval\即可使用）

以上便是本次分享的全部内容，感谢您的阅读，在评论区发表你的看法吧~。