On Thu, 2016-07-28 at 02:38 -0400, Jeffrey Walton wrote: [...] > >> // 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.
So it's running in AArch32 mode, and you want the encodings for that, not the AArch64 version. I.e. the second encoding I mentioned, which would be .inst 0xf3b00300 or better, find a compiler version and options that knows about the instructions you want to test (which I see you already asked about below). Sorry I can't help with that, I know little about toolchains, and have also never used the newer ARM instruction features like VFP, SIMD, crytpo etc. > 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. -- Tixy
