Do vxsat and vxrm really belong in fcsr?

[JamesKenneyImperas]

I'm promoting a comment I made to an issue so it can be more easily tracked.

We have implemented the new functionality described in section 3.2 (Vector Context Status in mstatus) in riscvOVPsim (visible when parameter vector_version is set to master only). However, the implementation is quite ugly: it really makes no sense from a user perspective that floating point should have to be enabled in order to do fixed point operations, or that floating point state is marked dirty on a fixed point saturation event (for example), or that VS!=0 is required for CSR access to vl, vttype and vstart but FS!=0 is required for similar access to vxsat and vxrm.

This all comes about because vxsat and vxrm are aliased within fcsr. I think this is an error, and you should seriously consider removing these fields from fcsr (perhaps introducing a new vxsr if you think having a composed view is important), simplifying the interface so that vector CSRs are entirely controlled by VS and floating point CSRs by FS with no confusion between them.

I understand that this could be quite an upheaval, but the current proposal seems to undermine one entire purpose of the FS bit, which is to indicate as accurately as possible whether floating point state is dirty.

[aswaterman]

It is a compromise; I dispute the claim that it makes no sense. An alternate design that packs these registers into a new vcsr has both advantages and disadvantages compared to the status quo. The current design reduces the number of CSRs that might need to be saved or restored on a context switch. This is particularly relevant for user-level context switches, which cannot check FS/VS.

[solomatnikov]

There is significant interest in making vector core without FPU but with fixed point. From this discussion it sounds like it might not be possible, so I vote for decoupling fixed point state from floating point state.

[aswaterman]

It is still possible to build fixed-point-only vectors and no FPU. The spec mentions that you can just hardwire mstatus.FS=3 on such systems.

…

On Sat, Nov 30, 2019 at 7:44 AM Alex Solomatnikov ***@***.***> wrote: There is significant interest in making vector core without FPU but with fixed point. From this discussion it sounds like it might not be possible, so I vote for decoupling fixed point state from floating point state. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#341?email_source=notifications&email_token=AAH3XQU2KMIMM3LPSTAYARTQWKC5ZA5CNFSM4JST5PMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQLFYY#issuecomment-559985379>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3XQVAYX6O5GQN3RKQN4LQWKC5ZANCNFSM4JST5PMA> .

[JamesKenneyImperas]

To clarify the vector-core-without-FPU-but-with-fixed-point, scenario:

1. fcsr would be implemented, but contain only vxrm and vxsat fields (no floating point fields);
2. fcsr, vxsat and vxrm CSRs would be present and accessible if mstatus.FS!=0. mstatus.FS might be hard-wired to 3, meaning these are always accessible, even if mstatus.VS=0;
3. vstart, vl and vtype would be present and accessible if mstatus.VS!=0.
4. Fixed-point operations would require both mstatus.FS and mstatus.VS to be non-zero.

I am not from a hardware background and I can make no informed comment about the context switch overhead that Andrew describes, but to me this seems arcane.

[kasanovic]

We'll discuss this in TG. Alternative is to implement a separate vcsr.

[kasanovic]

TG came up with solution that adds vcsr, and copies frm and fflags into that vcsr.