Making Rust available for Cortex-M33 revealed a weird inconsistency between how we use CPU_CORE and modules:
- Cortex-M4 exist with an FPU and without. Those are expressedas CPU_CORE=cortex-m4 and CPU_CORE=cortex-m4f.
- Cortex-M33 also exist with an FPU and without. Those are both called CPU_CORE=cortex-m33, and sometimes USEMODULE=cortexm_fpu is set.
Those two appear to do the same thing in different ways without any cause we could understand.
I think there's merit to the latter approach, as users who don't use the FPU of their MCU might want to opt to the technicall-softfloat ABI (which they don't pay for because they don't ever use floats), rather than stashing away FPU registers they don't use anyway. But I don't know for sure, not having worked with those details. But either way, I think this should be consistent.
If this is resolved either way, a hack in cpu/cortexm_common/Makefile.features where RUST_TARGET = to-be-set-later is assigned to only later be set precisely can be cleaned up, either by removing it again (if cortex-m33f becomes a thing) or by generalizing the pattern.
Making Rust available for Cortex-M33 revealed a weird inconsistency between how we use CPU_CORE and modules:
Those two appear to do the same thing in different ways without any cause we could understand.
I think there's merit to the latter approach, as users who don't use the FPU of their MCU might want to opt to the technicall-softfloat ABI (which they don't pay for because they don't ever use floats), rather than stashing away FPU registers they don't use anyway. But I don't know for sure, not having worked with those details. But either way, I think this should be consistent.
If this is resolved either way, a hack in
cpu/cortexm_common/Makefile.featureswhereRUST_TARGET = to-be-set-lateris assigned to only later be set precisely can be cleaned up, either by removing it again (if cortex-m33f becomes a thing) or by generalizing the pattern.