Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the proper way to define __CLZ? #26

Closed
petertorelli opened this issue Dec 6, 2022 · 2 comments
Closed

What is the proper way to define __CLZ? #26

petertorelli opened this issue Dec 6, 2022 · 2 comments
Labels
question Further information is requested

Comments

@petertorelli
Copy link

__CLZ is used in the softmax functions, however it is not defined for non-Arm compilers in CMSIS-NN.

Compare this to CMSIS-DSP, defines it by ultimately including dsp/none.h which contains an inline C function for it (and other intrinsics).

One can solve this by including dsp/none.h in the softmax headers, but that requires both installing CMSIS-DSP and hacking this library.

@felix-johnny
Copy link
Contributor

@petertorelli Thanks for the question.
The difference compared to DSP is that DSP officially supports building on host. NN doesn't and we don't have plans to do that in the near future. But, I understand how this can be an issue. So, narrowing down the issue to progress.

If building for say x86, one shouldn't have to support Arm Cortex-M processor specific intrinsics at all. This can be made sure by not defining ARM_MATH_DSP or ARM_MATH_MVEI. Doing so will ensure only pure C code is used with some exceptions like __CLZ without any loss in functionality.

There are some macros related to align or restrict, which you could define(away) in your application. As for CLZ, the application can define it for now. Hope this non CMSIS-DSP solution helps.

@felix-johnny felix-johnny added the question Further information is requested label Dec 7, 2022
@petertorelli
Copy link
Author

@felix-johnny Thanks for the response. It makes sense, in that I would expect eyebrows to be raised if someone asked if an Arm hardware library had plans for x86 compatibility. However sometimes it is a lot easier to bring up examples and tests on a host (cough audiomark cough). __CLZ was unique in that there were no other intrinsics exposed, this lead me to believe I was doing something wrong. All good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants