We are working on enabling the MC code-emitter for Hexagon and it's
necessary to add the missing opcode bits to the insn tables.
I'm considering scooping the opcode bits from the processor source files
for correctness' and expediency's sake and I'm afraid that a
significant
refactoring of the current insn tables will be necessary.
I intend to create classes for each insn with the opcode and have the
current insn definitions use the current names but based on a insn class.
For example, a conditional indirect branch insn is currently defined as:
def JMPR_cdnNotPt_V3: JRInst<(outs),
(ins PredRegs:$src1, IntRegs:$src2),
"if (!$src1.new) jumpr:t $src2",
[]>,
Requires<[HasV3T]>;
Its new definition would be like this:
let Defs = [PC], isPredicated = 1 in
class V3_J2_jumprfnewpt<list<dag> P = [], string C = ""> :
JRInst
<(outs),
(ins PredRegs:$Pu, IntRegs:$Rs),
"if (!$Pu.new) jumpr:t $Rs",
P, C> {
bits<2> Pu;
bits<5> Rs;
IClass = 0b0101;
Inst{27-21} = 0b0011011;
Inst{12-11} = 0b11;
Inst{9-8} = Pu;
Inst{20-16} = Rs;
};
let isReturn = 1, isBarrier = 1, isTerminator = 1 in
def JMPR_cdnNotPt_V3 : V3_J2_jumprfnewpt<>,
Requires<[HasV3T]>;
The insn class would be in a separate file included in the file where
the insns are defined. So its refactoring will mean that the way in
which insns are defined will be changed and a new file, added.
Would this be a sensible way to mix a machine-generated file that
wouldn't be modified often and one that is meant to be hand modified at
will?
TIA
--
Evandro Menezes Austin, TX emenezes at codeaurora.org
Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum