My guess is that 'a' doesn't handle SSE SIMD instructions at all, nor the registers on which they operate. "Bad Opcode" just means it doesn't understand the instruction, as opposed to the register - it uses "bad register" to denote the latter. Hence, your problem stems from both the xmm* registers and the movaps instruction (SSE). I had a bit of a play with this: 0:000:x86> a 77be0bc9 movss xmm1,xmm2 movss xmm1,xmm2 ^ Bad opcode error in 'movss xmm1,xmm2'
Instruction is correct but 'a' presumably doesn't do SSE. 77be0bc9 mob @eax,@ebx mob @eax,@ebx ^ Bad opcode error in 'mob @eax,@ebx'
Intentionally misspelled and nonsensical instruction produces the same result. 77be0bc9 movups @xmm2,@xmm1 movups @xmm2,@xmm1 ^ Bad opcode error in 'movups @xmm2,@xmm1'
Another SSE instruction, registers prefixed with @ to denote registers and prevent the possibility of interpretation as symbols. 77be0bc9 mov @eax,xmm2 mov @eax,xmm2 ^ Couldn't resolve 'mov @eax,xmm2'
Now it understands the (non-SSE) instruction but not "xmm2". Without the @ prefix, it thinks it might be a symbol which it can't resolve. 77be0bc9 mov @eax,@xmm2 mov @eax,@xmm2 ^ Bad register error in 'mov @eax,@xmm2'
It's been told that xmm2 is supposedly a register, by use of the @ prefix, but it obviously doesn't know of the xmm* registers and it barfs with "bad register error".
Verdict: limitation of the 'a' engine. They haven't updated it to do SSE.
That needn't hold you back if you're only trying to modify a handful of instructions though. You can still work out the corresponding machine code yourself (Intel docs + vast amount of online info), and just use the 'e' (edit) command to punch that into memory directly.
Great question though. Have some rep