[EXT] Re: [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

Jeff Scott

Completely agree.  Was very happy RISC-V did not include FPU exceptions.




From: tech-vector-ext@... <tech-vector-ext@...> On Behalf Of Andrew Waterman via lists.riscv.org
Sent: Friday, December 17, 2021 1:48 PM
To: Ken Dockser <kad@...>
Cc: tech-alternate-fp@...; tech-unprivileged@...; tech-vector-ext@...
Subject: [EXT] Re: [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability


Caution: EXT Email

Defining a standard extension that provides precise traps on FP exceptions seems like a reasonable thing to do, if only to facilitate the use case you mention in a standard way. The strategy would presumably be to add another five bits to the fcsr that indicate which exceptions will raise traps.


But I’ll also briefly remark that not requiring traps on FP exceptions has been a godsend for implementing high-performance in-order cores, where data-dependent traps would preclude early retirement and deferred execution of these instructions. So there’s good reason never to make such an extension mandatory, even in the RVA profiles.


On Fri, Dec 17, 2021 at 11:31 AM Ken Dockser <kad@...> wrote:

While I understand that it had been decided long ago (relatively speaking) that RISC-V would not support trapping on floating-point exceptions, I am wondering if we need to revisit this.


I have heard that ARM's rationale for adding floating-point exception trap capabilities in ARMv7.8 was not because of an inherent need for new code, but for enabling the efficient porting of X86 code to ARM.


Does anyone out there have any experience with porting X86 code to RISC-V? Has the lack of trapped FP exceptions hindered such porting?

Likewise, is there an interest in proposing a TG to create an extension that adds FP trap capabilities to Scalar and Vector FP.