deprecate uses_fp functionality in hal_create_thread

[rmu75]

Uses_fp proves to be problematic in case the compiler decides to generate SSE code, it silently corrupts FP / SSE state. This only affects RTAI.

I propose to get rid of realtime kernel threads that declare not to use FP (so every thread should be uses_fp=1), saving/restoring FP context shouldn't create measureable increase in latencies or max frequencies achievable on contemporary CPUs.

https://linuxcnc.org/docs/html/man/man9/motion.9.html
https://linuxcnc.org/docs/html/man/man3/hal_create_thread.3hal.html

[grandixximo]

@andypugh @BsAtHome @smoe

Need your input on this. Pretty big change, docs, addf, .comp and .c components. I think this touches a bit of everything if it was to be done proper, where we strip out FP/non-FP differentiation out of the codebase altogether.

Hit this bug on RTAI 5.4.280 with the etch-servo parport config. System was hard-crashing (heap corruption, libc segfaults, black screen). Tracked it down to pwmgen.make-pulses in the base-thread.

GCC was optimizing struct zeroing in make_pulses() into SSE instructions (pxor %xmm0; movups %xmm0). Function is exported with uses_fp=0, so RTAI never saves/restores XMM state. Every base-thread cycle it silently corrupts whatever Linux process was using those registers.

Scanned all 217 RT modules. Right now pwmgen is the only non-FP function where GCC actually emits SSE. The others are clean today. But that's basically luck, a compiler upgrade or a small code change could break any of them and you'd never know until someone's machine starts crashing.

IMO Robert is right, just make everything uses_fp=1 and be done with it. The ~100ns overhead for fxsave/fxrstor is nothing on modern hardware and it removes an entire class of silent bugs that are nearly impossible to diagnose.

[grandixximo]

Just made a small PR to at least fix the pwmgen, this Bertho's PR and cruckig are all to be merged for RTAI to be somewhat functional, the PR does not close the issue, it is a temporary patching up IMO

[BsAtHome]

On 4/2/26 1:17 PM, grandixximo wrote: GCC was optimizing struct zeroing in `make_pulses()` into SSE instructions (`pxor %xmm0; movups %xmm0`). Function is exported with `uses_fp=0`, so RTAI never saves/restores XMM state. Every base- thread cycle it silently corrupts whatever Linux process was using those registers.

This may be due to differences between the 32-bit and 64-bit compiler. https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html: Under -mfpmath it states: "For the x86-64 compiler, these extensions [sse] are enabled by default." There are probably other subtleties between 32- and 64- bit compilers that nobody ever checked. Also, I believe that -msse is added by default as an option too.

[snip] IMO Robert is right, just make everything `uses_fp=1` and be done with it. The ~100ns overhead for fxsave/fxrstor is nothing on modern hardware and it removes an entire class of silent bugs that are nearly impossible to diagnose.

Agreed, "modern" machines should not have any problem (100ns is 0.4% overhead on a 25000ns thread). And I guess that N'th level caching still could eat a bit from that too. One (hack) fix is to kill it in emc/hal/hal_lib.c in hal_create_thread() and set the uses_fp function argument to 1 just after entering the function (not too much later because it is used/assigned elsewhere). But that still leaves a lower level. Better alternative (still a hack) is to fix uses_fp to one in rtapi/rtapi_rtai.c in rtapi_task_new(). This is the lowest level before the rtai-kernel call gets involved. The other way is to remove the option from halcompile and always have it set at 1. However, that does not solve the problem for any non-.comp component and user-written code. Therefore, you could still end up on the wrong side if it is not killed very low down in the thread creation call-stack. Removing (or ignoring it) in halcompile still would be a proper thing to do and issue a warning when used.

…

-- Greetings Bertho (disclaimers are disclaimed)

[BsAtHome]

[sorry for cross-posting to dev-list; brain-not-awake-error detected; additional error detected: finger-and-eye-coordination-error, dev-list destination not performed]

[grandixximo]

Many components docs mention requiring Floating Point Thread.
And addf in HAL checks and enforces the requirement.
Those should also be cleaned up, if everything is Floating Point the requirements/restrictions should be lifted.

[andypugh]

Is it possible to disable sse except when uses-fp is enabled?
(I am nervous about assuming too much about why FP in the base thread was disallowed)

For reference, I was at the Wichita fest when JMK first enabled bas-thread FP:
02d22d6

[BsAtHome]

Is it possible to disable sse except when uses-fp is enabled? (I am nervous about assuming too much about why FP in the base thread was disallowed)

I don't think it really matters at al. The point is that non-RTAI (specifically uspace) always has FP enabled on both servo- and base-thread because it uses standard pthreads and doesn't even propagate the uses_fp signalling. There are no (real) problems with uspace timing and that should be indication enough that the whole FP/no-FP distinction should be considered ancient history.
Anybody using a machine not capable of running this is probably 10+ years old and that in itself would be enough to say that if they upgrade LCNC then they must upgrade the computer hardware to something (slightly) more recent too. Heck, they can probably run it in a RPi5 and be cheaper off.

[NTULINUX]

Just so you guys know, when it comes to kernel space, GCC's defaults are pretty out of the question. If you compile a kernel with make V=1 you'll see how explicit everything is.

LinuxCNC gets it's CFLAGS from RTAI:

RTAI_USER_CFLAGS="-O2 -march=x86-64 -fomit-frame-pointer -pipe"
RTAI_FP_CFLAGS="${RTAI_USER_CFLAGS} -D__IN_RTAI__ -mcmodel=kernel -std=gnu11 -nostdinc -ffreestanding -fno-pic -fno-builtin -fno-common -fno-unwind-tables -fno-asynchronous-unwind-tables -frounding-math -mpreferred-stack-boundary=4 -mstackrealign -mfpmath=sse -msse -msse2"

Without these, -msse -msse2 actually doesn't turn on because the kernel states that it only wants x87.

You cannot compile LinuxCNC or RTAI without these flags because you'll see many errors such as:

SSE register return with SSE disabled

SSE and SSE2 is required for at least some parts of LinuxCNC and RTAI but can safely be disabled for any corner cases you find.

And these flags are not the only ones.. When using Kbuild, it simply appends those flags to what's already in the kernel. For 4.19, this is what the most common flags are for the majority of the tree:

-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Werror=return-type -Wno-format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fno-builtin-wcslen -fmacro-prefix-map=./= -Wno-packed-not-aligned 

So you'd actually merge the kernel's flags, with RTAI_FP_CFLAGS, with RTAI_FP_CFLAGS taking precedence.

RTAI has used SSE/SEE2 in kernel space for the past 15-20 years with no issue, and certain parts of the kernel such as AMDGPU uses SSE/SSE2 as well:

drivers/gpu/drm/amd/display/dc/calcs/Makefile:calcs_ccflags += -msse2
drivers/gpu/drm/amd/display/dc/dml/Makefile:dml_ccflags += -msse2

SSE/SSE2 should definitely be disabled if that's the issue, just only where it's needed otherwise you will not be able to build much. SSE/SSE2 is also faster and more accurate than x87.

[BsAtHome]

SSE and SSE2 is required for at least some parts of LinuxCNC and RTAI but can safely be disabled for any corner cases you find.

There is the problem... Corner cases in kernel space are hard to debug and tend to crash things nowhere near the actual error. These are memory/register corruptions that become visible when something else crashes.

Simply enable FP on all threads and be done with it rather than trying to find and fix hard-to-find bugs and you still never know you've found them all.

[NTULINUX]

SSE and SSE2 is required for at least some parts of LinuxCNC and RTAI but can safely be disabled for any corner cases you find.

There is the problem... Corner cases in kernel space are hard to debug and tend to crash things nowhere near the actual error. These are memory/register corruptions that become visible when something else crashes.

Simply enable FP on all threads and be done with it rather than trying to find and fix hard-to-find bugs and you still never know you've found them all.

Yeah that works! :D

[grandixximo]

Is it possible to disable sse except when uses-fp is enabled? (I am nervous about assuming too much about why FP in the base thread was disallowed)

There is not other reason than squeezing performance from CPU that struggle with Floating Point operations, 10+ years old truth, it made sense at that time, GCC has moved on, Kernel has moved on, this issue has been there for years, no one ever dug deep enough. I was close to giving up as well, had to have YangYang check the assembly to dig it out, and I crashed Linux more times than I ever did before compounded and I did it all in one sitting, the frustration was trough the roof.

[andypugh]

OK, I am persuaded.

[NTULINUX]

The final fix for this will also need to be backported to 2.9 otherwise 2.9 will crash on RTAI as well.