cmd/asm: incorrect instruction encodings

[rsc]

I have constructed a fairly exhaustive test suite for the x86 assembler and identified some problems. The ones in this issue are long-time bugs that appear to have been present since the beginning of the Go project. We should fix them but given the history there is no need to rush the fixes into Go 1.6.

This may not be all of them: my tests don't account for some Go renamings of instructions.

I intend to fix these and check in the tests.

ADCB (BX), DL: have encoding "1013", want "1213"
   0:   10 13                   adc    %dl,(%rbx)
   0:   12 13                   adc    (%rbx),%dl

ANDPS (BX), X2: have encoding "660f5413", want "0f5413"
   0:   66 0f 54 13             andpd  (%rbx),%xmm2
   0:   0f 54 13                andps  (%rbx),%xmm2

CMOVLEQ (BX), DX: have encoding "0f4413", want "480f4e13"
   0:   0f 44 13                cmove  (%rbx),%edx
   0:   48 0f 4e 13             cmovle (%rbx),%rdx

MOVQ 0x123456789abcdef1, AX: have encoding "488b0425f1debc9a", want "48a1f1debc9a78563412"
   0:   48 8b 04 25 f1 de bc    mov    0xffffffff9abcdef1,%rax
   7:   9a 
   0:   48 a1 f1 de bc 9a 78    movabs 0x123456789abcdef1,%rax
   7:   56 34 12 

MOVQ AX, $0x123456789abcdef1: have encoding "48890425f1debc9a", want "48a3f1debc9a78563412"
   0:   48 89 04 25 f1 de bc    mov    %rax,0xffffffff9abcdef1
   7:   9a 
   0:   48 a3 f1 de bc 9a 78    movabs %rax,0x123456789abcdef1
   7:   56 34 12

[rsc]

Recounting this to @aclements I figured out what is going on with CMOVLEQ. The GNU form is CMOV[cond][size] but the form added for Go is CMOV[size][cond]. So GNU's cmovleq is cmov-le-q while Go's CMOVLEQ is CMOV-L-EQ. The Intel syntax has no size suffix and is CMOVEQ/CMOVLE, but it seems clear that Go should not be inserting a size suffix in the middle of the defined opcode name. While in general I feel that we need to put up with past mistakes in our assembly definitions to avoid breaking existing assembly programs, this one seems so egregious and error-prone that I think we have no choice but to change these names for Go 1.7 to match the Intel and GNU syntax.

[gopherbot]

CL https://golang.org/cl/18850 mentions this issue.

[bradfitz]

Is this still going to happen?

[rsc]

Didn't get the new tables done for Go 1.7. These weren't an emergency for Go 1.6 and remain not an emergency for Go 1.7.