[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[Mitchalsup]

Mitch AlsupMitchAlsup at aol.com


-----Original Message-----
From: Jacob Lifshay <programmerjake at gmail.com>
To: Luke Kenneth Casson Leighton <luke.leighton at gmail.com>
Cc: RISC-V ISA Dev <isa-dev at groups.riscv.org>; Mitchalsup <mitchalsup at aol.com>; allen.baum <allen.baum at esperantotech.com>; libre-riscv-dev <libre-riscv-dev at lists.libre-riscv.org>
Sent: Fri, Sep 13, 2019 8:33 pm
Subject: Re: [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

On Fri, Sep 13, 2019, 18:06 lkcl <luke.leighton at gmail.com> wrote:

On Saturday, September 14, 2019 at 4:56:07 AM UTC+8, Jacob Lifshay wrote:
> Some notes:
> 
> 
> I think it may be worthwhile to have separate Ztrans extension names to indicate the levels of accuracy that are implemented, allowing a low-precision implementation of all instructions outside of F and D while having full-precision implementations of F and D for code compatibility.

Hum, hum, don't know. My concern: that would be an NxM table of extension names. There are around 8 Ztrans ectensions, times four (so far, just found that OpenCL is different from Vulkan so that's 5) which would be 40 potential different extension names, rather than N+M which would be 12-13.


Assuming higher-precision operations are allowed to be used to implement lower-precision modes, we could have the higher-precision extensions just imply the lower precision extensions.alternatively, we could introduce the concept of extension parameters (like C++ template parameters).
While I have no vote in the matter--I would implore you not to shoot yourself in the foot this way.

please do elaborate on why you think it's a bad idea -- the riscv spec already seems to have parameterized extensions: XLEN (which is the pointer size in bits) as well as FLEN (size of fp register in bits)
When you get a multi-generational customer, which has an existing application;the first thing that customer will do is to run a sanity check of the new HW implementation using a "reference" benchmark. When any bit of the output of that program mismatches any bit from thenew implementation, the multi-generational customer will not be able to rationalize that this newHW is acceptable or not. This leads to various consternation,..... This happened to me at GOULD S.E.L circa 1982 when the new, faster, HW had more accurate FP implementation. The customer(one of the 3 letter spook organizations) could not accept delivery until a large amount of ourengineering time was spent hand holding said customer. HW was finally accepted mostly dueto the customer running out of ways to show how the new HW was potentially capable of screwingup multi-million line programs. Customer was never really convinced, but ran out of way to formulatenew questions which would eat engineering time (forever.)
You might be able to rationalize that this won't happen to you, to RISC-V, to <insert random>;I caution you on your ability to fight your way out of the hole you will be drilling.
parameterizing the Zftrans subextensions would be similar -- parameterizing each based on the maximum precision implemented. so, the ISA string could be something like: RV64GC_Zfacc_Zftrigpi.vlk_Zfrsqrt.full_Zfhyp.ml which would indicate that fsinpi and friends support the Vulkan/OpenCL precision mode and lower, frsqrt supports all precision modes, and ftanh and friends supports the machine learning precision mode and lower (though there isn't anything lower than ML mode in the current specs).
Jacob