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~
