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

[lkcl]

On Monday, September 9, 2019 at 7:03:58 AM UTC+1, Allen Baum wrote:
>
> At 4:45 PM -0700 9/8/19, lkcl wrote: 
> > 
> > 
> >Yes. You can see from the differences in those commercial GPUs, they each 
> made a different call. That's a clue. 
> > 
> >Here's the thing: the requirements in each market are so radically 
> different that it is impossible to call it one way or the other. 
>
> And that may be an excellent reason for a custom, rather than a standard 
> extension. 
>

i am relieved you said "may".

i forgot to mention: a custom extension would defeat the entire purpose of 
the exercise and not meet the full requirements (and the reply was too long 
already so i left it out).  i would not bother to have started this thread 
- at all - if the intention was to "just" have a custom extension.

clarifying the full requirements:

* a standard extension that covers the needs of the 3D embedded world, 
covering the 3D and numerical computation markets
* a standard extension that covers the needs of the embedded world, 
covering the 3D and numerical computation markets
* a standard extension that covers the needs of the 3d UNIX world, covering 
the 3D and numerical computation markets
* a standard extension that covers the needs of the UNIX world, covering 
the 3D and numerical computation markets

and for all four platforms to benefit from the shared saved development 
effort which is the whole purpose of RISC-V's existence.

exactly as how BitManip covers multiple disparate markets.  except that 
rather than dozens of different *computer science* branches 
cross-stratifying those different markets, there are only two computer 
science areas: 3D and numerical computation.

logically and rationally, it is categorically the case that this will not - 
and cannot - be a custom extension.

as a custom extension, if it goes into libm, gcc, numpy and other 
libraries, absolute chaos a la "Alitvec SSE" ensues by becoming a de-facto 
public standard out of sync with the rest of the RISC-V ecosysttem, 
completely destroying the RISC-V ecosystem in the process through 
conflictiing ISA allocation.


also, remember that the (very large) Open 3D Alliance markets includes 
ultra-low-power embedded systems (milliwatt budget for a GPU).  
Vectorisation is likely to be completely inappropriate, however scalar 
transcendentals will work out fine.

making a Vector ISA a hard implementation dependency before transcendentals 
can be utilised would penalise (exclude) those ultra-low-power GPU 
implementors.

this *has* to be a standard extension, and it has to be scalar.

l.