Question regarding ARMV7M FPU context switch and ISRs

[Chris Johns]

On 8/2/2024 9:55 pm, Sebastian Huber wrote:
> On 08.02.24 11:43, Cedric Berger wrote:
>> On 08.02.2024 11:09, Sebastian Huber wrote:
>>> On 08.02.24 10:53, Cedric Berger wrote:
>>>>
>>>> This would also simplify the context switching code, by centralizing of the
>>>> saving of the FPU context in RTEMS only, and enabling optimisation like only
>>>> saving/restoring the FPU when switching between tasks defined with
>>>> RTEMS_FLOATING_POINT.
>>>>
>>>> What do you think? I'm missing something? would it be a good idea?
>>>
>>> From experience, working with the RTEMS_FLOATING_POINT in applications is
>>> quite annoying. Is there really a measurable and significant performance
>>> improvement if you enable the deferred FPU switching? Can you guarantee that
>>> the compiler will not generate FPU or vector instructions for integer
>>> operations? In this version or a GCC release in the future?
>>
>> Obviously, since I'm not God, I won't be able to provide any guarantee
>> regarding the future :)
>>
>> But I believe that if GCC started to use FPU for integer operations, many
>> people would complain:
>>
>> FreeBSD requires fpu_kern_enter/fpu_kern_leave to use FPU in the kernel, and
>> Linux requires kernel_fpu_begin/kernel_fpu_end to use FPU ops in the kernel.
>>
>> I'm pretty sure Linus will give GCC developpers a hard time if they start to
>> use FPU for integer operations anytime soon...
> 
> I am definitely sure that on PowerPC the AltiVec unit is used to optimize memory
> copies and initializations. I agree that it is unlikely that GCC will use the
> FPU for integer operations.

FPU hardware often have wider data paths so they can be used for high speed
copies, ie 128bit at a time, so it is not about integers ...

https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/blob/master/newlib/libc/machine/arm/memcpy-armv7a.S#L31

Please be careful with any changes in this area.

Chris