On Tue, 13 Oct 2020 at 21:06, Richard Henderson
<[email protected]> wrote:
> I think these two sets of masking are confusing.
> Perhaps usefully rearranged as
>
> if (!fp16) {
> val &= ~fz16;
> }
> vfp_set_fpscr_to_host(env, val);
>
> if (!m-profile) {
> vec_len = extract32(val, 16, 3);
> vec_stride = extract32(val, 20, 2);
> }
> val &= 0xf7c80000;
> if (lob) {
> val |= 4 << 16;
> }
> fpscr = val;
Yeah, probably cleaner.
The other thing I wondered about is whether we should
be setting vec_len/vec_stride for an A-profile CPU which
doesn't implement the short-vector extension (ie where
MVFR0.FPShVec is zero). But that gets a bit awkward: v8A
allows an implementation to make Stride and Len be RAZ,
but v7A didn't permit that and so I think we would need
to distinguish:
* has short-vector support (eg Cortex-A9)
* v8A, can implement FPSCR.{Stride,Len} as RAZ/WI
* no short-vector support, Stride/Len can be written
but the only effect is that some insns must UNDEF
(eg Cortex-A7)
I think at the moment we currently provide short-vector
support for everything, which is wrong but wrong in
the direction that means more guest code runs...
thanks
-- PMM
