On 11/10/2017 04:11 AM, Ron Economos via USRP-users wrote: > I guess this is a little late, but you can pass in compiler flags on the > command line with -DCMAKE_CXX_FLAGS. For example: > > cmake -DCMAKE_CXX_FLAGS:STRING="-mfloat-abi=hard -mfpu=neon > -mtune=cortex-a15" ../
That would be the preferred way. The patch mentioned assumes that anytime you are using a compiler with the neon.h header file, the SoC you are compiling for has a neon unit. This is a bad assumption. There are a few examples of SoC's around that do not have a neon unit. Now UHD will generate neon and create runtime failures. Bottom line, in the ARM world, you cannot test compiler features to figure out what features the runtime system has. Philip > > Ron > > On 11/10/2017 12:07 AM, Gwenhael Goavec-Merou via USRP-users wrote: >> Hello, >> >> maybe this : https://github.com/EttusResearch/uhd/pull/135 >> will help you >> >> Gwen >> >> On Fri, 10 Nov 2017 00:29:25 -0600 >> Kevin McGuire via USRP-users <usrp-users@lists.ettus.com> wrote: >> >>> 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 errors. >>> >>> 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 <kmcg3...@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. >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
