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.