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

[lkcl]

Andrew, Bruce: I'm sorry, I'm having real difficulty understanding the need 
for a "quantitative" analysis, here.  It makes absolutely no sense.

Now, for the case where, for example.... let's say... an xBitManip "ROR" 
instruction, that's easy to do.  Crypto uses it, therefore crypto 
performance is adversely impacted, therefore it's easy to justify.

Or, let's say... an opcode that can be used for big-integer math "carry".  
You get some algorithms, you look at what the performance is before and 
after, and it's easy to justify.

However with 3D and OpenMP, it's a whole different ballgame (not so with 
Machine Learning, which can use the same APIs, just with different accuracy 
requirements).

Not only is the market *already pre-justified*, by massive billion-dollar 
Corporations such as NVIDIA, AMD, Intel etc., there's pre-defined hardware 
APIs in the form of the Khronos OpenCL opcode specification:
https://www.khronos.org/registry/spir-v/specs/unified1/OpenCL.ExtendedInstructionSet.100.html

that these companies collaborated to create such a specification, that *IS* 
the "justification".  attempting to do a "quantitative analysis" of 
*already proven opcodes* - repeating decades-long Industry-proven 
customer-backed ongoing acceptance is both staggeringly time-consuming and 
completely pointless, at the same time.

Machine Learning augmentations on the other hand are a different story, as 
the field is so new that not even the billion-dollar GPU companies have 
proven up-to-date useful hardware.

The justification for these opcodes is thus effectively one word: 
"Vulkan".  If it's in the Vulkan spec, that *is* the justification, because 
failure to include opcodes that SPIR-V supports *automatically* penalises 
any such hardware.

The other justification is - again - not quantitative, it's collaborative.  
The whole point of RISC-V is that it provides a central focal point for 
different stake-holders to utilise it and reduce their NREs and their 
customer costs and time to market.  Having these trigonometric opcodes - 
and compliance with the Vulkan API that goes with that - *is* a 
justification in and of itself.

So i'm really sorry, but a "quantitative" analysis of a near-exact replica 
of the Kronos OpenCL opcodes is misleading, pointless, and a hopeless waste 
of everybody's time.

Does that make sense?

l.