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.
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