[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