Re:Avo: Better X86 Assembly Generation from Go
by pcwalton on Thursday January 10, 2019 @04:02PM
(#18878122)
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. :(
[ Parent
| on HN ]
Re:Avo: Better X86 Assembly Generation from Go
by mmcloughlin on Thursday January 10, 2019 @04:19PM
(#18878302)
Yes! 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/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`.
Re:Avo: Better X86 Assembly Generation from Go
by haberman on Thursday January 10, 2019 @06:05PM
(#18879335)
Even 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?