Clarify implications for fcsr

[nick-knight]

My understanding is that the psABI intends for fcsr to be the ABI manifestation of fenv, when the latter is relevant. With this understanding, I find the current wording to be misleading:

• fcsr is an object in the ISA, not the C language, so it is nonsensical to say it has "thread storage duration".
• It can be interpreted as imposing constraints on fcsr for all programs, even those that don't access/modify fenv.
• The relevant properties of fenv have been present since C99, so the specific reference to C11 is not meaningful.

This PR attempts to clarify the intent while addressing these three points. Your feedback is most welcome.

[kito-cheng]

fcsr is an object in the ISA, not the C language, so it is nonsensical to say it has "thread storage duration".

I am struggling with thread storage duration since that also give promise about the CSR is thread-safe and execution environment must guarantee that, but I think that different point from your PR, however that would be a wider issue that just fcsr, there are same issue for vcsr, vl and vtype and all URW unprivileged CSR.

It can be interpreted as imposing constraints on fcsr for all programs, even those that don't access/modify fenv.

Just make sure you are trying to address this by following sentence ?

In contexts where accesses or modifications to the C floating-point environment 
(`fenv`) are meaningful, like when the `FENV_ACCESS` pragma is "on",

The relevant properties of fenv have been present since C99, so the specific reference to C11 is not meaningful.

Agree with that, thanks!

[kito-cheng]

Another attempt to clarify fcsr: #289

[nick-knight]

the CSR is thread-safe and execution environment must guarantee that

My understanding is that the ISA guarantees that each hardware thread (hart) will have its own fcsr, so fcsr is "thread-safe" in this sense, and there is nothing further the ABI needs to say about it. Perhaps you mean C-language threads, not RISC-V harts? In this case, we need to first clearly define how fcsr is reflected by an object in the C language. My PR attempts to address this.

Just make sure you are trying to address this by following sentence ?

Correct.

[nick-knight]

As far as I can tell, neither Clang nor GCC fully supports fenv for RISC-V targets, even though it's been ~23 years. The FENV_ACCESS pragma is ignored, and the various command-line flags don't fully cover the required functionality.

My attitude is that my use-case would be better addressed by F-extension intrinsics. I acknowledge that this is a RISC-V-specific solution; however, in my experience, the people asking for this functionality generally aren't writing code that is meant to be broadly portable across architectures.

Another one of my objectives with this PR is to leave the psABI open to eventual implementation of fenv, as well as alternatives like F-extension intrinsics.

[kito-cheng]

As far as I can tell, neither Clang nor GCC fully supports fenv for RISC-V targets, even though it's been ~23 years. The FENV_ACCESS pragma is ignored, and the various command-line flags don't fully cover the required functionality.

Yeah, that's one reason I didn't mention FENV_ACCESS in #289 since I am not sure should we mention a thing without well implemented in mainstream open source compilers...

My attitude is that my use-case would be better addressed by F-extension intrinsics. I acknowledge that this is a RISC-V-specific solution; however, in my experience, the people asking for this functionality generally aren't writing code that is meant to be broadly portable across architectures.

Might be little bit digress from the topic, but I am curious what the shape is for those intrinsic in your mind? providing static rounding mode argument? or guarantee the order among different F-ext. intrinsic?