On Mon, 18 Mar 2019 at 23:36, Richard Henderson <richard.hender...@linaro.org> 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
