3 ms·
Yeah, AT&T syntax has much of the same issues of poor documentation. In particular, operand order is easy to remember for 2-operand instructions: it's reversed
by pcwalton 8y ago
Yeah, AT&T syntax has much of the same issues of poor documentation. In particular, operand order is easy to remember for 2-operand instructions: it's reversed in AT&T. But now with SSE and AVX we have 3- or 4-operand instructions, and the AT&T versions sometimes put the operands in (2, 1, 3), sometimes in (3, 2, 1), etc. There's no documentation for this aside from GCC as far as I can tell. :(
- mmcloughlin 8y agoYes! This tripped me up at one point. My comment says "Otherwise we could be in the bizarre special-case of 3-argument CMP instructions." https://github.com/mmcloughlin/avo/blob/0e253b3753beb409b3dd8028fc81f5fa4b96aaee/internal/opcodescsv/analysis.go#L84 https://github.com/mmcloughlin/avo/blob/0e253b3753beb409b3dd... It gets to the point where the only source of truth is the Go assembler itself. My test suite takes the avo instruction database and generates a massive assembly file with one line per instruction form, then passes this to `go tool asm`.
- haberman 8y agoEven just mapping between the mnemonics is non-trivial. You want to think that it's just a matter of removing size suffixes from AT&T, but it's sadly not that simple. "movslq" in AT&T maps not to "movsl" or even "movs" in Intel, but "movsxd". How is anybody supposed to figure that out?