[LLVMdev] Auxiliary operand types for disassembler.

Jim Grosbach grosbach at apple.com
Mon Jul 1 16:44:24 PDT 2013

On Jun 26, 2013, at 6:39 AM, Sid Manning <sidneym at codeaurora.org> wrote:

> On 06/25/2013 04:46 PM, Jim Grosbach wrote:
>> 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?
> A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100% certainty.  Adding the auxiliary operand was a way for the printer to accumulate this information as the packet is being read.
> An alternative is to pass the raw insn to the target printer.  This would have the same effect, giving the printer the chance to accumulate and interpret the insns when printing the contents of the packet.
> Here are some examples:
> - Some insns contain a 3-bit new value, the new value bits, Nv[2:1] are set to 1, 2, or 3 if the producer is 1, 2, or 3 insns ahead of the consumer.  Nv[0] is 1 if the producer is an odd register, 0 for even.
>  {
>                r17 = add(r2, r17)
>                r23 = add(r23, #-1)
>                if (!cmp.eq(r23.new, #0)) jump:t foobar
>  }
> The above packet has 2 producers, r17 and r23.  If the compare and jump is encoded as: 0x2443e000 where new value bits are stored in [18:16] and equal 0x3 then register 23 would be used - Nv[2:1] == 0x1.  The producer was 1 insn back and the register is odd.  If bits [18:16] had been 0x5 then register 17 would have been used.
> - Parse bits can be used to designate the end of a hardware loop.  If the parsebits are set to 10b in the first insn of the packet then this packet is the end of hardware loop 0, if the parse bits in insn 1 are set to 01b and the parse 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 having to change objdump itself.

The representation of a generic MCInst should not need to change. While not exactly what you’re dealing with, the ARM disassembler does have some multi-instruction context it has to maintain to get predicated instructions for Thumb2 correct. In your case, the disassembler will likely need to consume a packet at a time so it has the whole context.

That is, the printer and encoder shouldn’t have to know any of the context. The disassembler/codegen does all of it.


> Thanks,
>> -Jim
>> On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org
>> <mailto: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, "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 to correctly represent the insn it needs
>>> to accumulate the series of insns that form the packet. Only when the
>>> entire packet is known can the meaning of the parse bits be properly
>>> interpreted.
>>> Changing objdump's interface to printInst so it passes the raw insn
>>> bits down would allow the printer to accumulate the same information
>>> and would work just as well I think.
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> hosted by The Linux Foundation
>>> <MCInst.h.diff>_______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu
>>> <mailto:LLVMdev at cs.uiuc.edu>http://llvm.cs.uiuc.edu
>>> <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130701/53b89880/attachment.html>

More information about the llvm-dev mailing list