On 2026/08/26 06:39 PM, Chinmay Rath wrote: > > On 8/26/26 15:50, Amit Machhiwal wrote: > > On 2026/08/26 10:38 AM, Chinmay Rath wrote: > > > From: Nikhil Kumar Singh <[email protected]> > > >
<snip> > > > + > > > +DST 011111 ----- ..... ..... 0101010110 - @X_ea > > > +DSTST 011111 ----- ..... ..... 0101110110 - @X_ea > > Per **PowerISA v3.1 §4.3.2.1**, dst, dstst, and dss are obsolete and > > must be treated as no-ops independent of whether Vector instructions are > > available. The new REQUIRE_INSNS_FLAGS(ctx, ALTIVEC) guard in all three > > handlers is incorrect — it causes these opcodes to be treated as illegal > > instructions on non-Altivec CPUs, contradicting the ISA mandate. These > > handlers should unconditionally return true with no flag check, matching > > the ISA's "always a no-op" requirement. The ra == 0 INVAL check in > > trans_DST and trans_DSTST should also be dropped for the same reason — > > if the instruction is a no-op, the operand constraint has no effect. > Thanks Amit ! > This is very informative. There are many such instances in QEMU code where > insns haven't been updated as per the newer ISA. > Though, I'd like to point out that the REQUIRE_INSNS_FLAGS(ctx, ALTIVEC) > guard in those insns is not new. This was already present as in the code, I > will mark it with [A] below for reference. > This patch simply intends to move the insn to decodetree keeping the > existing logic intact. The translation logic and flag checks remain same for > these 3 pointed out insns. I'd like to take up your suggestion here and post > a folllow-up patch to update those insns as per the new ISA. Would that be > okay ? Or would you prefer the insn's correction as per the ISA in this same > decodetree movement patch ? I did notice that this check already existed before this movement and I don't see it as a blocker for this series. It would make sense to fix such places in follow up patches. ~Amit
