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
