Re: [PATCH v3 22/51] target/arm: Trap AdvSIMD usage when Streaming SVE is active

[Richard Henderson]

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.


r~