Avo: Better X86 Assembly Generation from Go
1–10 of 20 posts
Re: Avo: Better X86 Assembly Generation from Go
#2I really wish Go (really, Plan 9) hadn't made their own assembly syntax. The fact that we have AT&T syntax to deal with instead of just using Intel's syntax is bad enough.
I understand the rationale—that you can use the assembly syntax as a sort of IR by unifying the syntax of certain basic operations across different ISAs—but that's properly considered a low-level IR, not assembly. (It's also a pretty bad form of IR for doing any interesting optimizations, which is why Go uses a separate SSA form for that.)
Re: Avo: Better X86 Assembly Generation from Go
#3I really wish Go (really, Plan 9) hadn't made their own assembly syntax. The fact that we have AT&T syntax to deal with instead of just using Intel's syntax is bad enough. I understand the rationale—that you can use the assembly syntax as a sort of IR by unifying the syntax of certain basic operations across different ISAs—but that's properly considered a low-level IR, not assembly. (It's also a pretty bad form of IR…
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... 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.
Re: Avo: Better X86 Assembly Generation from Go
#4A similar concept for python: https://github.com/Maratyszcza/PeachPy
Re: Avo: Better X86 Assembly Generation from Go
#5Really dope - excited to see this project come out!
Re: Avo: Better X86 Assembly Generation from Go
#6A similar concept for python: https://github.com/Maratyszcza/PeachPy
avo author here. Yes PeachPy was the inspiration for this, as well as asmjit. Both mentioned in the credits:
https://github.com/mmcloughlin/avo#credits
PeachPy actually has Go output already, and Damian Gryski has used this to great effect:
https://github.com/mmcloughlin/avo/issues/40
Unfortunately because PeachPy wasn't initially written with Go in mind there are some rough edges and Go features it simply doesn't support. avo hopes to fill this gap for Go programmers.
Re: Avo: Better X86 Assembly Generation from Go
#7A similar concept for python: https://github.com/Maratyszcza/PeachPy
avo author here. Yes PeachPy was the inspiration for this, as well as asmjit. Both mentioned in the credits: https://github.com/mmcloughlin/avo#credits PeachPy actually has Go output already, and Damian Gryski has used this to great effect: https://github.com/mmcloughlin/avo/issues/40 Unfortunately because PeachPy wasn't initially written with Go in mind there are some rough edges and Go features it simply doesn't su…
Ah - peach -> avocado, I see that now.
Re: Avo: Better X86 Assembly Generation from Go
#8I really wish Go (really, Plan 9) hadn't made their own assembly syntax. The fact that we have AT&T syntax to deal with instead of just using Intel's syntax is bad enough. I understand the rationale—that you can use the assembly syntax as a sort of IR by unifying the syntax of certain basic operations across different ISAs—but that's properly considered a low-level IR, not assembly. (It's also a pretty bad form of IR…
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 d…
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. :(
Re: Avo: Better X86 Assembly Generation from Go
#9I really wish Go (really, Plan 9) hadn't made their own assembly syntax. The fact that we have AT&T syntax to deal with instead of just using Intel's syntax is bad enough. I understand the rationale—that you can use the assembly syntax as a sort of IR by unifying the syntax of certain basic operations across different ISAs—but that's properly considered a low-level IR, not assembly. (It's also a pretty bad form of IR…
I've done a reasonable amount of ARM, x86 and amd64 programming with the go assembler.
It's quirks are annoying to start with, but if you use more than one assembly language you begin to see the advantages of a more consistent syntax between them.
I suspect the advantages for the go maintainers of a uniformish assembler syntax are the real reason for it.
Re: Avo: Better X86 Assembly Generation from Go
#10Earlier quoted context omitted.
avo author here. Yes PeachPy was the inspiration for this, as well as asmjit. Both mentioned in the credits: https://github.com/mmcloughlin/avo#credits PeachPy actually has Go output already, and Damian Gryski has used this to great effect: https://github.com/mmcloughlin/avo/issues/40 Unfortunately because PeachPy wasn't initially written with Go in mind there are some rough edges and Go features it simply doesn't su…
Ah - peach -> avocado, I see that now.
Haha yes! PeachPy was written at Georgia Tech and avo was written in California.