Paolo Bonzini <pbonz...@redhat.com> writes:
> On 19/03/19 11:18, Alex Bennée wrote: >> >> Richard Henderson <richard.hender...@linaro.org> writes: >> >>> 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? >> >> Agree, we should certainly be efficient with the base flags first (we >> already have overlap for AA32/64 states). I have no problem with using >> cs_base after that. We could bite the bullet and expand flags to 64 bits >> but I guess that will be a bit of a hit for 32 bit hosts. >> >> Given how many guests use the cs_base I wonder if it's time we came up >> with a better name for it: extra_tb_state, extra_state, moar_bits... > > Or make the flags 64-bits by moving cs_base into the upper 32-bits of > flags... This way 32-bit hosts do not see any difference. I think you still need a target_ulong for cs_base as some guests use it for next_pc. -- Alex Bennée
