Sorry as I sent this I could see the subject and 7M. Chris
On 9/2/2024 1:33 pm, Chris Johns wrote: > 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 > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel