I'm using dismantle-ppc and finding I often have to look at the dismantle-ppc/data/PPC.tgen to figure out what ASM an opcode corresponds to. For example, the dismantle-ppc BC opcode corresponds to ASM bt opcode (the ASM bc opcode with first argument specialized to 12), and the dismantle-ppc BCn opcode corresponds to the ASM bf opcode (the ASM bc opcode with first argument specialized to 4). As far as I can tell this alternate meaning for the BC opcode, and the existence of the BCn opcode, are LLVM-isms. They don't correspond to anything I've seen in IBM PowerPC docs.
A step in the right direction which would be easier than adding support for custom doc strings would be to include the bits and AsmString fields from the PPC.tgen file into the generated docs, since these fields are how I usually figure out what ASM opcode a given dismantle-ppc opcode corresponds to.
I'm using dismantle-ppc and finding I often have to look at the
dismantle-ppc/data/PPC.tgen
to figure out what ASM an opcode corresponds to. For example, the dismantle-ppcBC
opcode corresponds to ASMbt
opcode (the ASMbc
opcode with first argument specialized to 12), and the dismantle-ppcBCn
opcode corresponds to the ASMbf
opcode (the ASMbc
opcode with first argument specialized to 4). As far as I can tell this alternate meaning for theBC
opcode, and the existence of theBCn
opcode, are LLVM-isms. They don't correspond to anything I've seen in IBM PowerPC docs.A step in the right direction which would be easier than adding support for custom doc strings would be to include the
bits
andAsmString
fields from thePPC.tgen
file into the generated docs, since these fields are how I usually figure out what ASM opcode a given dismantle-ppc opcode corresponds to.