Re: Broadcom BCM2709, ARMv8, and missing CPU features
>> Using '.byte' below rather than '.inst' or '.inst.w' is another can of worms...
>
> And if I'm not mistaken, the part of the reason why you got the
> instructions wrong...
>
>> $ gcc -g3 -O0 -march=armv7-a -mfpu=neon test.cc -o test.exe
>> $ ./test.exe
>> $
>
> Does the tool-chain default to ARM or Thumb? I assume ARM code.
I believe its ARM.
>> $ cat test.cc
>> #include <arm_neon.h>
>> int main(int argc, char* argv[])
>> {
>> __asm__ __volatile__
>> (
>> ".code 32"
>
> BTW, above selects ARM code generation, but won't have any affect
> because you don't specify any labels or instruction mnemonics to
> assemble.
That's the only thing that managed to get a good disassembly from objdump -d.
>> // AES (aese)
>> ".byte 0x4e, 0x28, 0x48, 0x20;\n"
>
> So as instructions are little-endian that's 0x2048284e for a 32-bit
> instruction, or 0x284e2048 if it's a Thumb2 instruction (I'm showing
> that the same way as the ARM ARM does).
I pulled the encodings from a known good machine that used intrinsics.
I did not hand encode them (too much work).
> According to my copy of the ARM ARM, the AESE instruction has these
> encodings:
>
> For Thumb:
>
> 1 1 1 1 1 1 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm
>
> For ARM
>
> 1 1 1 1 0 0 1 1 1 D 1 1 size 0 0 Vd 0 0 1 1 0 0 M 0 Vm
>
> For AArch64
>
> 0 1 0 0 1 1 1 0 size 1 0 1 0 0 0 0 1 0 0 1 0 Rn Rd
>
> So it looks like you've used the AArch64 encoding (for something
> compiled and presumably run as AArch32?!) and gotten the byte order the
> wrong way around.
I'm not sure if it matters, but this is an ARMv8 device running a 32-bit OS.
I'm still trying to figure out how to build test cases for an Aarch32
execution on Aarch64. Eventually it will go into an open source
library's test script. Also see
https://gcc.gnu.org/ml/gcc-help/2016-06/msg00097.html.
If you know how to do it, then please email me on a sidebar. I'm happy
to test theories. I think -mcpu=... factors into it somewhere.
Jeff
Reply to: