[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal
waterman at eecs.berkeley.edu
Thu Aug 8 08:33:09 BST 2019
On Thu, Aug 8, 2019 at 12:11 AM Jacob Lifshay <programmerjake at gmail.com>
> On Wed, Aug 7, 2019, 23:30 Andrew Waterman <waterman at eecs.berkeley.edu>
>> Hi folks,
>> We would seem to be putting the cart before the horse. ISA-level support
>> for correctly rounded transcendentals is speciously attractive, but its
>> utility is not clearly evident and is possibly negative. It does not make
>> sense to allocate opcode space under these circumstances.
> Since there are ways to implement transcendental functions in HW that are
> faster than anything possible in SW (I think Mitch mentioned a 5-cycle sin
> implementation), I would argue that having instructions for them is
> beneficial, and, since they would be useful on a large number of different
> implementations (GPUs, HPC, bigger desktop/server processors), it's worth
> standardizing the instructions, since otherwise the custom opcodes used for
> them would become effectively standardized (as mentioned by Luke) and no
> longer useful as custom opcodes on implementations that need fast
> transcendental functions.
That is not a quantitative approach to computer architecture. We don't add
nontrivial features on the basis that they are useful; we add them on the
basis that their measured utility justifies their cost.
> I have no problems ending up with different encodings and/or semantics
> than currently chosen, as long as that's done early enough and in a public
> manner so that we can implement without undue delay the chosen opcodes
> without being incompatible with the final spec.
Yeah, this is the cart leading the horse. It's not obvious that the
proposed opcodes justify standardization.
> Jacob Lifshay
More information about the libre-riscv-dev