[USRP-users] Compiling UHD Host Library: Problem Enabling ARM Neon Support

Kevin McGuire kmcg3413 at gmail.com
Fri Nov 10 01:29:25 EST 2017

I was able to get the compiler flags passed in so that the check for the
header arm_neon.h passes. I added it to the CMakeList root file with
SET(CMAKE_CXX_FLAGS, "${CMAKE_CXX_FLAGS} -mfloat-abi=softfp -mfpu=neon").

Then, it would detect neon. However, I spent considerable time cleaning up
whatever package problems I had since I ended up with a bunch of weird

Once I straightened my packages up (Debian), it is compiling with neon!
And, hopefully, it will actually use the ARM neon routines.

On Thu, Nov 9, 2017 at 3:22 AM, Kevin McGuire <kmcg3413 at gmail.com> wrote:

> I have noticed that neon support for the converter is not enabling. The
> CMakeError.log has this output. I am not certain as I am not really
> familiar with ARM and NEON, but I checked my CPU and it does support it.
> Also, the error message below is saying it is just a matter of passing
> certain flags.
> /mnt/extra/usr/lib/gcc/arm-linux-gnueabihf/4.8/include/arm_neon.h:32:2:
> error: #error You must enable NEON instructions (e.g. -mfloat-abi=softfp
> -mfpu=neon) to use arm_neon.h
>  #error You must enable NEON instructions (e.g. -mfloat-abi=softfp
> -mfpu=neon) to use arm_neon.h
> Normally, I would just fix it myself and move forward, but me and CMake
> mix like oil and water. It is kind of embarrassing but I swear it never
> does what I want it do - such as adding a darn flag. I even tried to force
> the options, lol, and all be danged if CMake finds some way to error.
> Will work on this tomorrow, but if anyone has a solution I am all ears. If
> not then no problem and I will reply when I figure it out.
> This came about when I noticed what really seemed like abnormally high CPU
> usage on my ARM code for a simple shuffling of data out of the network
> packets. I traced what I felt like was the biggest possible hot spot to the
> converter routine. Anyway, that is my plan right now, to see if NEON might
> help if the converter is having to swap byte order.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20171110/6ecd7787/attachment-0002.html>

More information about the USRP-users mailing list