关于Linux&Melis Kernel Neon使用的一些总结

单指令多数据（Single Instruction Multiple Data, SIMD)是一种使用一条指令就可以同时处理多个数据的技术，其实现原理是把要处理器的多个数据批量加载到位宽比较大的寄存器中，然后使用一条专用的指令对这些数据进行并行处理，如下图所示，SMD的应用场景包括科学计算，音视频编解码，图形处理，机器学习。

 

NEON的历史

ARM最初是在 armv6上引入SIMD技术的，那时SIMD指令只能对通用寄存器中的数据进行并行处理，而从ARMV7开始，新增了16个128位的向量寄存器，专门供SIMD指令使用。不在支持在通用寄存器上进行SIMD操作，为了与前一代SIMD区分，就称为ASIMD技术( Advance SIMD)技术，也就是NEON技术。

在ARMV8的AARCH64执行状态下对NEON做了进一步扩展，例如，将128 位的寄存器从16个增加到了32个，为了进一步提升计算性能和程序的可移植性，ARMV8.2中引入了可伸缩向量扩展技术(Scalable Vector Extension, SVE) 技术，不在约定向量寄存器的位宽，但是位宽必须是128 的整数倍，最多为2048位，通过SVE技术不用重新弄编译就可以让同一个可执行程序运行在不同向量位宽的CPU上，但是仅在AARCH64执行状态下才能用SVE指令。而在最新的ARMV9上又引入了SVE2技术，对SVE和NEON进行了扩展和增强。

问题描述

前些天在项目中遇到一个和neon使用有关的问题，做一下总结。

问题描述:Melis3.0方案跑在cortex-a7平台上，在用-mfpu=neon-vfpv4 --mfloat-abi=hard编译固件时，会概率性有系统死机或者数据不一致的情况出现。

问题分析：一开始别人跟我讲这个问题并没特别在意， 认为是个别模块的错误使用导致的，修复模块本身的bug就OK了，可是后面另一位同事报告他的模块又出现类似的问题，我逐渐开始怀疑和系统相关了。

问题规律: 问题多发生在读写内存前后，发现内存访问结束后，读回来和预期不一致的现象，用调试器查看，发现确实内存数据被改写，而且更诡异的，似乎这个问题可以和某些外设中断有关，中断来的越频繁，问题发生的概率越大。

问题根源：前面说到，方案是使能hard float的情况下编译的，所以GCC会在何时的时候将某些运算编译成neon指令去加速计算过程，根据arm eabi, 一个完整的链接单元必须保证各个模块用一致的浮点选项编译，否则可能会在链接阶段失败，最终造成的结果是固件中neon指令可能会出现在任何函数，我们知道，系统运行时是分上下文的，典型的就是任务上下文和中断上下文， 在melis里面，我有在任务切换到时候对neon单元进行上下文保存，但是却疏忽了中断上下文执行对应操作。在中断执行流中，中断处理函数会调用哪些函数，这些函数会不会使用neon指令进行加速完全是随机的，所以有可能会发生中断环境破坏了被中断的任务的NEON现场。

下面是网络找到一些说明：

找出问题的原因并没花太多时间，只是后来联想到，这个问题实际上和系统关联性不大，或者说，任何并发多任务OS上都不可避免要处理这个问题，那在这些系统上，比如Linux上是如何利用NEON的呢？

Linux简单粗暴的做法不禁让我大跌眼镜，在Linux里面,你是不能使用 --mfloat-abi=hard选项编译的，不但如此，还必须明确的告诉编译器，不能隐式的产生neon指令，方法是加入“-mfloat-abi=softfp”编译选项，指示编译器按照软浮点ABI编译，这样就完全杜绝了编译器意外产生neon指令（这里存疑，-mfloat-abi只控制软件调用的参数ABI）。

关于这一点，Linux内核有文档说明：/Documentation/arm/kernel_mode_neon.txt

至于为什么要用软浮点编译，文档也有说明，大概意思是说，即便只用-mfpu=neon选项，当优化等级调高的时候，编译器背后也会生成一些neon指令，为了杜绝这种情况，保证编译器在任何情况下都不自动产生neon指令，必须使用softfloat编译。

既然内核使用浮点编译选项， 那是如何使用neon的的？

原来，Linux是在层层保护的情况下使用neon的，要关抢占，防止任务调度出去，保存之前neon现场，并在使用完neon之后恢复， 不仅如此，使用neon的代码也不能靠编译器生成，所以当然也不能用c语言实现(因为前面说过，c代码都会按照软浮点编译), 最终只能通过汇编显示的调用neon指令实现。

具体点说，除了上面的编译要求必须满足外，使用neon指令的加速逻辑必须被 kernel_neon_begin / kernel_neon_end调用包裹。

kernel_neon_begin();