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~