qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] running out of Arm TB flags...


From: Peter Maydell
Subject: Re: [Qemu-devel] running out of Arm TB flags...
Date: Tue, 19 Mar 2019 11:20:11 +0000

On Mon, 18 Mar 2019 at 23:36, Richard Henderson
<address@hidden> wrote:
>
> On 3/18/19 12:46 PM, Peter Maydell wrote:
> > Hi; for the M-profile floating point work I'm going to need I think
> > three new TB flags (to control whether to generate the code to do
> > the various independent things the pseudocode ExecuteFPCheck() function
> > does before executing any FP insn). Unfortunately we currently have
> > only 2 unused bits in the arm TB flags word.
> >
> > I can see two possible ways to get the 3rd bit:
> > (1) overload the meaning of an existing bit which I know isn't
> > relevant to M-profile (eg the XSCALE_CPAR or VECLEN or VECSTRIDE bits)
> > (2) start defining new bits in the currently-unused cs_base word
>
> Either works.  But I'd probably reuse (or eliminate) XSCALE_CPAR first.
> Afaik, xscale never had vfp, so CPAR could overlap FPEXC_EL?

Yes, XScale and VFP are mutually exclusive. I've made XSCALE_CPAR
share bits with VECSTRIDE. (It seemed nicer to have the overlap
be only within AArch32-only bits rather than overlapping with
an 'any' bitfield like FPEXC_EL.)

Speaking of VECSTRIDE, in theory we should implement the v8A
requirement that FPSCR.Len and .Stride are either RAZ/WI or
cause the insns which use Len and Stride to UNDEF if they are
set to non-zero. At the moment we just have the v7A behaviour
of "honour Len and Stride settings"...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]