search for: endloop1

...rse bits in insn 2 are set to 10b then this is the last packet in hardware loop 1. If the parse bits in insn 1 and insn 2 are both set to 10b then this is then end in both hardware loops 0 and 1. At the tail of the packet the disassembler would add the following: }:endloop0 }:endloop1 }:endloop0:endloop1 to represent the end of the various loops. The disassembler has to accumulate the MCInsts for the whole packet and either the raw hex encodings or append the needed info as an operand stored in the MCInst. The reason I tried using MCOperand is that it kept me from...

...ructions if(p1) r0 = add(r1, r2) Dense semantics for DSP applications. Complex multiply optionally shifting result left by 1 with optional rounding and optional saturation r0 = cmpy(r1, r2):<<1:rnd:sat Hardware loops ended by optional packet suffix { r0 = r1 }:endloop0:endloop1 We found the Hexagon grammar to be straight forward to implement using plain lex / parse but harder within the MCTargetAsmParser. We were thinking a way to get the grammar to work would involve modifying tablegen and the main asm parser loop. We'd have to make tablegen break down each...

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type,

I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. The reason for this is that each insn has parse bits which are not explicit operands and have differing meanings based on the insn's location within the packet and the number of insns inside the packet. In order for the disassembler