4 ms·

Author of avo here. While I did really enjoy working on this project, I still fully agree with you. Go (Plan 9) syntax is not sufficiently different to make it

Author of avo here. While I did really enjoy working on this project, I still fully agree with you. Go (Plan 9) syntax is not sufficiently different to make it a powerful intermediate representation, hence SSA as you point out. In fact many of the differences are frustrating subtle changes in instruction mnemonics or operand order. This might be okay if there was a canonical instruction database that made all these differences from Intel and AT&T easy to discover. However these exceptions are really recorded in various parts of the golang.org/x/arch/x86 repo. Producing the instruction database for avo was quite a time-consuming process. See: https://github.com/mmcloughlin/avo/blob/master/internal/load/load.go https://github.com/mmcloughlin/avo/blob/master/internal/load... https://github.com/mmcloughlin/avo/issues/23 https://github.com/mmcloughlin/avo/issues/23 I've gained a lot more familiarity with the assembler and supporting infrastructure, so I'm hoping I may be able to contribute to this area of the core Go project.

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 ago
  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/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 ago
  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?

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 ago
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/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 ago
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?