[libre-riscv-dev] [Bug 208] implement CORDIC in a general way sufficient to do transcendentals

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=208

--- Comment #11 from Michael Nolan <mtnolan2640 at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #7)
> integer, and kept things at the same exponent.  i.e. we:
> 
> * adjusted the relative range of both numbers a and b so that they
>   had the same exponent (-1 from exp, shift mantissa until exp(a)==exp(b)
> * keeping enough bits (3x the IEEE754 length in some places) at all times
>   so that there will be no loss of precision
> * from that point on treated the mantissa as an integer, *completely
> ignoring*
>   the exponent until
> * finally at the end "re-normalising" the result.

Ah ok, this makes more sense. 


> unfortunately, as we will (later) be using the CORDIC block for other
> purposes,
> not just SIN/COS but as an actual opcode, if it doesn't do "actual CORDIC"
> we're stuffed, there.

Ah I see. So at some point we'll be wanting to use this for general rotations,
hyperbolic sin/cos, and such? 

> 
> i suspect that it might be possible, as the size of the ATAN2 constants
> gets smaller, to "shift" the result up slightly.
> 
> this we can do - test out - right now long before trying to move to FP.
> each CordicStage can take an extra argument which specifies that dx, dy and
> dz should be shifted by N extra bits.

I think I sort of understand - you want to scale up dx, dy (and presumably x
and y) when they're small so that they have more bits of precision. 

One thing that occurred to me - since power (and I assume riscv) don't include
any sin/cos opcodes but instead use a function in libc to calculate them, the
cordic would only be used by the GPU, right? If that's the case, do sin/cos
necessarily need to be as accurate as the result from libc?

-- 
You are receiving this mail because:
You are on the CC list for the bug.