On Fri, 24 Jun 2022 at 21:34, Richard Henderson <richard.hender...@linaro.org> wrote: > > On 6/24/22 08:30, Peter Maydell wrote: > > So the thing that worries me about structuring this this way > > is that the SME supplement appendix includes this caution: > > > > # The instruction encoding tables in this section [...] will > > # require correction if subsequent versions of the A64 ISA > > # add new instructions which overlap with these encodings. > > > > My guess (based on how the H.a Arm ARM has incorporated > > SME) is that these tables aren't going to be included > > in the Arm ARM and updated going forward. Instead the > > behaviour will be documented based on whether (existing > > and new) instructions call CheckNonStreamingSVEEnabled() > > or CheckSVEEnabled() in their pseudocode. > > I agree that this would be cleaner and more correct long-term. > > > So I'm a bit uncertain about how awkward it's going to be > > in future to maintain this transliteration of the SME > > supplement tables into decodetree: we might find that > > we have to look at new instructions and kind of > > reverse-engineer back out any required changes to the > > tables here, rather than simply "write the trans_ function > > for the new insn, looking at the pseudocode to see which > > _access_check() function it should be calling"... > > I thought about this, and if it were simply a matter of annotating the > trans_* functions > within translate-sve.c, I would have done it. But I would need to adjust A64 > AdvSIMD as > well, which is still done with the by-hand decoder. > > Can we use this solution in the short term, and fix up advsimd while > coverting it to > decodetree? I'm more and more convinced we'll want this sooner than later.
Yeah, I guess so. Is it possible to do the SVE stuff the right long-term way and have the short-term fix only for the A64 AdvSIMD, or do we need to do both the same way ? -- PMM