discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?


From: Monahan-Mitchell, Tim
Subject: Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Date: Wed, 7 Aug 2013 15:23:19 +0000

Hi, Marcus.

Thanks for your help. Tom seems to have given a pretty definitive reply, but 
this is just to completely answer your reply.

> On 08/07/2013 02:44 AM, Marcus Müller wrote:
>>
>>
>> [1] note: in kernel terms of auxvec.h this stands for AT_HWCAP, see 
>> http://lxr.free-electrons.com/source/include/uapi/linux/auxvec.h?a=arm#L24
>> How Volk handles it looks like AT_HWCAP can only start on a 4-byte-aligned 
>> address within auxv;
>> I'm absolutely not sure whether this is correct; on my x86_64 machine, there 
>> is no AT_HWCAP in that case.
>decided to have a look into this instead of sleeping; man proc(5) and volk are 
>right: AT_HWCAP can only occur every 64 bit in /proc/PID/auxv. Sorry for the 
>confusion.

Your earlier reply said:

<snip> "... however, as it seems, detection of Neon fails."

But the cmake output I included said:

-- Performing Test have_mfpu_neon - Success
-- Performing Test have_funsafe_math_optimizations - Success

So I think the neon detection works?

You also asked: "does executing
   hexdump /proc/self/auxv|sed '0000 0010'
show anything?"

Yes, an error :) ... Maybe you meant grep? The first line of auxv matches to 
your string:

$ hexdump /proc/self/auxv
0000000 0010 0000 b0d7 0001 0006 0000 1000 0000
0000010 0011 0000 0064 0000 0003 0000 8034 0000
0000020 0004 0000 0020 0000 0005 0000 0009 0000
0000030 0007 0000 c000 4002 0008 0000 0000 0000
0000040 0009 0000 8f35 0000 000b 0000 0000 0000
0000050 000c 0000 0000 0000 000d 0000 0000 0000
0000060 000e 0000 0000 0000 0017 0000 0000 0000
0000070 0019 0000 dc07 bed4 001f 0000 dfeb bed4
0000080 000f 0000 dc17 bed4 0000 0000 0000 0000
0000090

And if I run the basic "cmake ../" command, I still get the same output for 
Volk.

You asked for the CFLAGS in CMakeCache.txt in that s case, here you go: 

// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_C_FLAGS:STRING=
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1

Just to compare, running my original cmake command yields the CFLAGS I manually 
specified:

grep C_FLAGS CMakeCache.txt
// CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel.
CMAKE_C_FLAGS:STRING=-I/usr/include/arm-linux-gnueabihf -mcpu=cortex-a15 
-mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//ADVANCED property for variable: CMAKE_C_FLAGS
CMAKE_C_FLAGS-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG
CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1
//ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1

Thanks again and all the best,
Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]