On 6/24/22 14:38, Peter Maydell wrote:
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
On Fri, 24 Jun 2022 at 21:34, Richard Henderson
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
>
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
On Mon, 20 Jun 2022 at 19:09, Richard Henderson
wrote:
>
> This new behaviour is in the ARM pseudocode function
> AArch64.CheckFPAdvSIMDEnabled, which applies to AArch32
> via AArch32.CheckAdvSIMDOrFPEnabled when the EL to which
> the trap would be delivered is in AArch64 mode.
>
> Given that
This new behaviour is in the ARM pseudocode function
AArch64.CheckFPAdvSIMDEnabled, which applies to AArch32
via AArch32.CheckAdvSIMDOrFPEnabled when the EL to which
the trap would be delivered is in AArch64 mode.
Given that ARMv9 drops support for AArch32 outside EL0,
the trap EL detection ought
