Remove uses_fp parameter from RTAPI and HAL APIs#3901
Remove uses_fp parameter from RTAPI and HAL APIs#3901grandixximo wants to merge 1 commit intoLinuxCNC:masterfrom
Conversation
|
Hopefully I did not miss any... |
|
You should not remove the OptFP rule in halcompile just yet. Instead you should add the warning from my patch (and always return 1). That would give people an indication what is actually happening and gives them time to fix their code. The next release beyond 2.10 we can remove the rule completely. It is not clear whether it is appropriate to change the HAL API in 2.10. It feels as too much too crude too soon. It is more appropriate to warn users appropriately that |
|
what about #3286 |
grandixximo
force-pushed
the
fix/remove-uses-fp-2.10
branch
from
9486d25 to
a02aacf
Compare
I am not sure it still is, but even if it is, I think that the discussion has made it clear that the API for out-of-tree components shouldn't change. |
|
I'm not so sure the discussion points in that direction anymore. I think is a reasonable goal, but we are moving it to next release? |
|
I am not sure that "noparam" will actually break the API, as the only way to set parameters that I am aware of is the "setp" hal command, and that works equally well when parameters become pins. We have been steadily changing parameters to pins for many years now, and don't seem to have been breaking things. |
grandixximo
force-pushed
the
fix/remove-uses-fp-2.10
branch
2 times, most recently
from
5905b4d to
d7d39a9
Compare
|
Refactored for milder version, which will give deprecation warnings, docs to match. |
Andy, I respectfully disagree. While The For now, I've rolled this back to a milder change similar to what was done in 2.9, just adding deprecation warnings without breaking the API, as Bertho suggested. That said, IMO when we do decide to break API compatibility, we should do it all in one shot. The |
+1 Makes no difference to me if my comps break with 2.10 or the one after it. |
|
In hal/components/threads.c: You might as well remove the fp1/fp2/fp3 in the call to hal_create_thread() too and fix it to 1. And add a comment above the RTAPI_MP_INT declaring fp1/fp2/fp3. |
All threads now unconditionally save and restore FPU/SSE state, making the uses_fp parameter obsolete. Rather than removing it from the API (which would break out-of-tree components), this commit deprecates it with a grace period: RTAPI: uses_fp parameter is accepted but ignored; FPU state is always saved in rtapi_task_new() regardless of the value passed. HAL: uses_fp parameter is accepted but ignored in hal_export_funct(), hal_export_functf(), and hal_create_thread(). All functions and threads are always marked as FP-capable internally. The addf FP compatibility check is removed since all threads are now FP-capable. halcompile: fp/nofp keywords in function declarations now emit a deprecation warning and are treated as fp (always return 1). The keywords will be removed in a future version. Remove fp/nofp from all in-tree .comp files, conv.comp.in template, and mkconv.sh generator. Remove fp1= from test .hal files. Out-of-tree .comp files will still parse but emit a deprecation warning. Documentation: API man pages, tutorials, and guides updated with deprecation notices. Removed references to FP thread restrictions that no longer apply. No API signatures changed — out-of-tree components continue to compile unchanged but will see warnings from halcompile if they use fp/nofp. Based on patch by BsAtHome. Ref: LinuxCNC#3895
grandixximo
force-pushed
the
fix/remove-uses-fp-2.10
branch
from
d7d39a9 to
50f7f1d
Compare
|
like that? That was weird, Somehow I pressed enter and gihub decided that meant to cancel the PR, go figure... |
Yes.
That is the fun you get for allowing a machine to interpret your actions? |
I typed in the first sentence, pressed enter, instead of doing return to the next line, it closed the PR by itself, the close button was not even in view as I was typing, this is some JS crap, or whatever they use to write GitHub, unless my brain is turning into mush.... |
4 participants
Complete removal of the uses_fp parameter for 2.10. All threads now unconditionally save and restore FPU/SSE state.
RTAPI: remove uses_fp from rtapi_task_new(), remove RTAPI_NO_FP and RTAPI_USES_FP constants, hardcode FPU save in rt_task_init_cpuid.
HAL: remove uses_fp from hal_export_funct(), hal_export_functf(), hal_create_thread(). Remove uses_fp field from hal_funct_t and hal_thread_t structs. Remove addf FP compatibility check. Remove FP column from halcmd and halrmt display.
Components: remove uses_fp argument from all hal_export_funct and hal_export_functf call sites. Remove base_thread_fp from motion module, fp1/fp2/fp3 from threads component.
halcompile: remove OptFP grammar rule, fp/nofp parsing, and fp-related code generation and documentation output. Remove fp/nofp from all in-tree .comp files, conv.comp.in and mkconv.sh.
Documentation: remove uses_fp from API man pages, remove FP thread references from tutorials and guides.
Out-of-tree components must be updated to the new API signatures.
Ref: #3895