Hello,
I am interested in experimenting with Golang assembly with LLVM on X86. Golang Assembly is most similar to AT&T/GAS with some differences:
- A small number of instructions have operand order flipped
- Some mnemonics are different
- Different register naming conventions
Iskander Sharipov covers details here: https://quasilyte.github.io/blog/post/go-asm-complementary-reference/
I have started looking into how the X86AsmPrinter and InstPrinter works. It seems like there could be two high-level approaches:
-
Treat Golang assembly as a completely separate third variant. This would require substantial edits to various X86Instr*.td files, mainly to account for variant number 2 in all the AsmString entries. That is, strings like “mov{l}\t{$src, $dst|$dst, $src}” would need to account for a third possibility. Likely much of this could be automated, but the changes would be substantial. Then hopefully other differences could be handled with MnemonicAlias. Further changes would be required to
X86AsmPrinter.cc, parsers, and no doubt many other places I haven’t even seen yet. -
I am interested in whether it’s feasible (and easier) to treat Golang as a “sub-variant” of AT&T. That is, no changes made to the *.td files, but the differences between AT&T and Golang assembly are handled later in code (X86AsmPrinter and the like). I have not fully thought this through yet.
I thought I would reach out for some advice from people who might have a better intuition. Are either of these approaches reasonable? Is there a better third way? Is the whole thing going to be prohibitively difficult? Any pointers appreciated.
Cheers,
Mike