[LLVMdev] MCInst

[Chris Lattner]

On Jul 9, 2009, at 5:34 PM, David Greene wrote:
> Can someone explain what MCInst is vs. MachineIntr?

Sure.  MCInst is designed to be part of the "MC" set of libraries,  
which is stuff dealing with machine code.  We're building a suite of  
assemblers and disassemblers out of this.

MCInst is integral to this plan.  For an assembler you have two pieces:

1. "Recognize" an opcode + argument list to an MCInst (a .td  
instruction enum + MCOperands).
2. Run the "MCInst encoder" to emit a series of machine code bytes +  
relo entries.

For a disassembler, you have two other pieces:

3. Decode machine code bytes into an MCInst.
4. AsmPrint the MCInst to the ".s file" output.


Daniel will be working on #1 soon, #2 is basically a heavily  
refactored version of X86CodeEmitter.cpp:emitInstruction, #3 will be  
contributed soon by Sean, and #4 is basically a heavily refactored  
version of asmprinter:printInstruction (which I'm working on).

A strong goal for me is to make it so that we can build very small (as  
in code size) assembler and disassembler tools.  This means that none  
of this stuff can depend on (e.g.) libx86, because that brings in the  
huge target plus libcodegen plus libtarget plus vmcore, ... etc.  As a  
key part of this factoring, instruction asmprinting (for example) will  
no longer work directly on MachineInstr.  Instead,  
asmprinter::printInstruction will lower a MachineInstr to an MCInst,  
then call the MCInst asmprinter to do the hard formatting work.  You  
can see a horrible simple skeleton of this idea in  
X86ATTAsmPrinter::printMachineInstruction.

There is a ton of refactoring and cleanup left to do, but a great  
benefit of this is that it really helps clean up the targets and make  
them do the right things in the right places.

> I'm porting some
> patches we have here that affect MachineInstrs and am wondering  
> whether I
> need to make similar changes in MCInst.

You should almost certainly do everything on MachineInstr.  MCInst is  
still very early on, if you make any changes to MachineInstr I'll  
update MCInst to match.  Please discuss changes to core data  
structures like MachineInstr before you make them though.

> Why do we have two machine instruction representations?

Hopefully I covered that above.

-Chris