Re: Broadcom BCM2709, ARMv8, and missing CPU features

[Tixy <tixy@yxit.co.uk>]

On Thu, 2016-07-28 at 00:48 -0400, Jeffrey Walton wrote:

> 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.

> $ 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.

>     // 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).

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.

Disclaimer, I'm only on my first coffee of the morning, so quite likely
not 100% accurate in my statements above. ;-)

-- 
Tixy