On Thu, Jul 28, 2016 at 3:06 AM, Tixy <[email protected]> wrote: > 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
OK, thanks. I *think* what may have happened is the disassembly occurred on host machine, not the target machine. > 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. Yeah, this is quite painful at the moment. I think there's a disconnect between what's advertised to work, and what works in practice. Let me see if GCC 6.0 is available; or if Clang has better success. I'm doing my best to avoid building GCC myself. I have very bad memories from that experience. Jeff
