qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v2 62/68] target/arm: Convert T16, Miscellaneous 1


From: Richard Henderson
Subject: Re: [Qemu-arm] [PATCH v2 62/68] target/arm: Convert T16, Miscellaneous 16-bit instructions
Date: Mon, 26 Aug 2019 16:47:13 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/26/19 1:38 PM, Peter Maydell wrote:
>> +  IT            1011 1111 ... imm:5             &ci cond=%it_cond
> 
> This is correct (same behaviour as the old decoder, but
> it looks a bit odd here because it's not the same as
> the fields defined by the architecture (in particular the
> 'cond' field is not the same set of bits as the 'firstcond'
> field). We could maybe comment it:
> 
>   # Bits 7:0 in IT are architecturally simply the
>   # new PSTATE.IT bits (despite the instruction description
>   # splitting them into 'firstcond' and 'mask' fields).
>   # In QEMU during translation we track the IT bits using
>   # the DisasContext fields condexec_cond and condexec_mask,
>   # so here we massage the bits from the insn into the form
>   # that that optimization requires.
> 
> (Or equivalently we could just pass a single 8 bit immediate
> to the trans_IT function and split it out there, I dunno.)

I think I'll just go with this latter and do everything in trans_IT.

>> +%imm6_9_3       9:1 3:5 !function=times_2
> 
> Would it be worth adding support to the decodetree script
> for letting you specify fixed bits in this kind of field-decode,
> so we could write '9:1 3:5 0' rather than having to specify
> a multiply-by-2 function to put the 0 bit in ? Or is it
> not likely to be common enough to be worth bothering with?
> (Not something for this series, anyway.)

I hadn't thought about that.

Adding 1, 2, or -1 also appears, but that's 3 of the 60 instances currently in
the tree whereas shifts make up 33 of 60.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]