Add HOST support

[higaski]

CMSIS should contain an ANSI C compatible core header (e.g. cmsis_none.h or cmsis_ansci.h) which can be compiled on any major platform without anything vendor specific. In the spirit of the "HOST build" of CMSIS-DSP which uses the none.h header to compile the DSP library on e.g. x86 we should have the same option available for just CMSIS.

The problem is that nowadays most "HAL libraries" of ARM silicon vendors rely on CMSIS headers as a lower layer and while one could easily stub (and or mock) some C functions which use memory mapped structs for peripherals and so on it's actually really hard to replace the underlying CMSIS headers.

My personal approach would be

• What can be replaced with a meaningful implementation (e.g. __QADD) should be.
• What can't should simply be a NOP.

/edit
Once such a header exists CMSIS-DSP could have a dependency to CMSIS and use this header, instead of defining things like __QADD itself.

[JonatanAntoni]

@christophe0606, how does this integrate with CMSIS-DSP?

[higaski]

After a quick glance over CMSIS-DSP I assume that care would have to be taken to not define functions like __QADD twice.

[christophe0606]

@JonatanAntoni The reasons why CMSIS-DSP can be compiled without CMSIS is to support Cortex-R, Cortex-A and aarch64 and the Python wrapper and to be able to build on target like Windows on Arm ... In those cases, we either use pure C (Python wrapper) or Neon extensions.
So dependencies to CMSIS are not needed in those cases.

But I don't see the use cases for CMSIS on host ? We don't need CMSIS on Windows on Arm for instance.

Now the only reason why I need a few C implementation for some intrinsics is legacy. CMSIS-DSP code targeting M0 is sometimes the same as the one targeting M4 and relies on macros for some intrinsics and a C version when targeting M0.

I think it would be cleaner to have a pure C version for M0 part. But the amount of intrinsics needed due to this legacy code is very low.

[higaski]

@JonatanAntoni The reasons why CMSIS-DSP can be compiled without CMSIS is to support Cortex-R, Cortex-A and aarch64 and the Python wrapper and to be able to build on target like Windows on Arm ... In those cases, we either use pure C (Python wrapper) or Neon extensions. So dependencies to CMSIS are not needed in those cases.

But I don't see the use cases for CMSIS on host ? We don't need CMSIS on Windows on Arm for instance.

Same use case as for CMSIS-DSP. Being able to compile a file which includes "cmsis_compiler.h" on x86 would greatly benefit unit tests. Currently, the burden to mock such a dependency is 100% offloaded to the users and once it gets to them, it's also 10x harder to solve. Having such a thing as HOST support would mean simply setting a flag somewhere in your build environment. Not having it means

1. Mock all the dependencies to satisfy the compiler (most likely by hand, because tools have a very hard time with header only stuff)
2. Fiddle with include paths to make sure your mocked version gets picked. This is especially great if the include paths are part of external dependencies and not your own.

[JonatanAntoni]

Hi @higaski,

Would you be able to contribute (at least a starting point) of what you would need for your project(s)?

Thanks,
Jonatan

[JonatanAntoni]

@higaski,

We are currently discussing restructuring CMSIS-Core, see #33.
So far, we are thinking about folders per profile (M, A, and R). Perhaps having another folder (generic?) would already serve your purpose?

[higaski]

Sorry for the delay. I've been thinking about this for a while now. Having a separate "generic" folder would definitively help, specially preventing "accidental" header lookup. I think I will be able to provide something (at least for the M-profile) but it might take a while as I can only shave off a few hours here and there.

Personally I'd only need the current "topmodel" (so an v8M) to be mocked and all older or less feature rich types just refer to this one. Would that be acceptable for you?

[JonatanAntoni]

Sure, let's start with what you need. We can always add additional stuff later.

[rsaxvc]

I've run into this too, recently trying to update ardupilot from just the DSP parts of CMSIS_5 to CMSIS_DSP. It seems cmsis_dsp.h mixes two tasks:

1. mapping CMSIS macros to architecture-specific intrinsics
2. mapping CMSIS macros to compiler-specific keywords and attributes

For example, most of cmsis_gcc.h is needed for an AMD64 build, just for things like __STATIC_INLINE. One thing to consider is that we probably really do want it to complain if we can't work out the right architecture on ARM(and maybe AARCH64) systems. For other systems maybe we fallback to generic-profile immediately? Also, what should go in generic-profile? I can't seem to find anything that needs to exist there.

Separately, I'll mention that all CMSIS macros defined with two leading underscores overlap with the language reserved space, but fixing that is probably not something for CMSIS6 to solve.

[christophe0606]

@rsaxvc If you are targetting anything else than Cortex-M, you can disable the dependency to CMSIS Core.
With cmake build of CMSIS-DSP, just use -DHOST=ON
With a make build just use -D__GNUC_PYTHON__ (the feature was introduced for the Python wrapper).

If your target supports Neon, you can enable its support in CMSIS-DSP with -DNEON=ON (cmake) or -DARM_MATH_NEON (make). Not all functions are providing Neon but we are going to add more Neon code.

[rsaxvc]

With cmake build of CMSIS-DSP, just use -DHOST=ON

Thanks @christophe0606, that works great for my needs.

If you are targeting anything else than Cortex-M, you can disable the dependency to CMSIS Core.

Just a note, I think ARM11, Cortex-R4, and Cortex-A without NEON may also want to use CMSIS Core, because otherwise CMSIS-DSP has to fallback to scalar implementations rather than the older SWAR DSP extensions available on those devices. At least for ARM11 Q15 formats the FFT is quite a bit faster that way.