You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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 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!
__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.The text was updated successfully, but these errors were encountered: