cortex-a中断中浮点运算破坏线程栈浮点寄存器 #8043
Conversation
…n the floating point calculation will be safe in interrupt function.
| @@ -97,7 +97,9 @@ rt_hw_context_switch: | |||
| tst r6, #(1<<30) | |||
| beq 1f | |||
| vstmdb sp!, {d0-d15} | |||
| vstmdb sp!, {d16-d31} | |||
| #ifdef RT_USING_VFPD32 /*there art 32 double float registers to save*/ | |||
There was a problem hiding this comment.
这个在编译的时候应该是不同的参数，对应的参数分别是什么？
There was a problem hiding this comment.
浮点单元有多种版本，VFPv2,VFPv3-D16,VFPv4-D16是只有D0-D15寄存器，VFPv3-D32,VFPv4-D32有D0-D31寄存器。我手上用的芯片实现的版本是VFPv4-D16，所以我只能测试D0-D15。我看到其它RTOS(如threadX,FreeRTOS)对于该处的实现均是保存的D0-D31，所以我默认它们的移植是正确的。所以就用RT_USING_VFPD32表示浮点寄存器是D0-D31的情况，至于只有D0-D15的情况，在我写代码时没有过多考虑（因为低16个寄存器大家都有），当然也可以使用如RT_USING_VFPD16来表示。
There was a problem hiding this comment.
浮点单元有多种版本，VFPv2,VFPv3-D16,VFPv4-D16是只有D0-D15寄存器，VFPv3-D32,VFPv4-D32有D0-D31寄存器。我手上用的芯片实现的版本是VFPv4-D16，所以我只能测试D0-D15。我看到其它RTOS(如threadX,FreeRTOS)对于该处的实现均是保存的D0-D31，所以我默认它们的移植是正确的。所以就用RT_USING_VFPD32表示浮点寄存器是D0-D31的情况，至于只有D0-D15的情况，在我写代码时没有过多考虑（因为低16个寄存器大家都有），当然也可以使用如RT_USING_VFPD16来表示。
唔，我的意思是，类似这样的方式，在编译时这个编译参数是什么？有不同的编译参数了，是否可能会出现gcc内部定义宏是有差异的。如果有差异，直接使用内置宏来做区分就显得最方便了，而不需要自己来定于宏。
There was a problem hiding this comment.
有的，如下：
-mfpu=name
This specifies what floating-point hardware (or hardware emulation) is available on the target. Permissible names are: ‘auto’, ‘vfpv2’, ‘vfpv3’, ‘vfpv3-fp16’, ‘vfpv3-d16’, ‘vfpv3-d16-fp16’, ‘vfpv3xd’, ‘vfpv3xd-fp16’, ‘neon-vfpv3’, ‘neon-fp16’, ‘vfpv4’, ‘vfpv4-d16’, ‘fpv4-sp-d16’, ‘neon-vfpv4’, ‘fpv5-d16’, ‘fpv5-sp-d16’, ‘fp-armv8’, ‘neon-fp-armv8’ and ‘crypto-neon-fp-armv8’. Note that ‘neon’ is an alias for ‘neon-vfpv3’ and ‘vfp’ is an alias for ‘vfpv2’.
The setting ‘auto’ is the default and is special. It causes the compiler to select the floating-point and Advanced SIMD instructions based on the settings of -mcpu and -march.
If the selected floating-point hardware includes the NEON extension (e.g. -mfpu=neon), note that floating-point operations are not generated by GCC’s auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision.
You can also set the fpu name at function level by using the target("fpu=") function attributes (see ARM Function Attributes) or pragmas (see Function Specific Option Pragmas).
There was a problem hiding this comment.
但是之前了解的是没办法让这个-mfpu 编译选项被.S文件识别出。
There was a problem hiding this comment.
可以用不同的编译参数从 gcc dump 出两份宏定义，然后对比一下文件是否有差异
| @@ -458,13 +458,30 @@ vector_irq: | |||
|
|
|||
| #else | |||
| stmfd sp!, {r0-r12,lr} | |||
| #ifdef RT_USING_FPU | |||
There was a problem hiding this comment.
中断一般都是主动保存，主动恢复 FPU 状态的。否则为了一个小概率发生的事件，系统却要付出每一次 IRQ 增加大量访存的巨大代价。这是不合理的。
因此建议是新增 FPU_SAVE/RESTORE 的 API/汇编宏，而不是修改 IRQ
There was a problem hiding this comment.
同意，这样会比较合理。中断函数中是否使用了浮点数，编程人员是知道的，主动进行保护是明智的。
There was a problem hiding this comment.
但这样好像也存在一个问题，就是线程在创建的时候就需要告知rt_hw_stack_init在初始化栈时要预留浮点单元的栈空间。所以相关的接口函数参数可能需要修改。
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
cortex-a平台下，中断中如果使用浮点计算会破坏线程栈中的浮点寄存器
你的解决方案是什么 (what is your solution)
对中断进行浮点寄存器的保护
在什么测试环境下测试通过 (what is the test environment)
在stm32mp135fae7上，基于lts-v4.1.x分支测试OK。
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up