Libre RISC-V Mailing list Archives (accessible via public-inbox)
 help / color / Atom feed
From: bugzilla-daemon@libre-soc.org
To: libre-riscv-dev@lists.libre-riscv.org
Subject: [libre-riscv-dev] [Bug 208] implement CORDIC in a general way sufficient to do transcendentals
Date: Wed, 15 Apr 2020 19:54:43 +0000
Message-ID: <bug-208-13-IhLBD1iyUg@https.bugs.libre-soc.org/> (raw)
In-Reply-To: <bug-208-13@https.bugs.libre-soc.org/>

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

Cole Poirier <colepoirier@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colepoirier@gmail.com

--- Comment #12 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Michael Nolan from comment #11)
> (In reply to Luke Kenneth Casson Leighton from comment #7)
> > 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?

Michael, here are some possibly relevant links to FPU accuracy... or rather
inaccuracy. I've also added them to the resources page under "5.4 Past FPU
Mistakes to learn from".

Intel Underestimates Error Bounds by 1.3 quintillion
Posted on October 9, 2014 to Random ASCII – tech blog of Bruce Dawson 

https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

Intel overstates FPU accuracy 06/01/2013

http://notabs.org/fpuaccuracy/


Cole

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

  parent reply index

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-208-13@https.bugs.libre-soc.org/>
2020-04-13 14:35 ` bugzilla-daemon
2020-04-13 17:23 ` bugzilla-daemon
2020-04-13 17:34 ` bugzilla-daemon
2020-04-15 17:54 ` bugzilla-daemon
2020-04-15 18:04   ` Cole Poirier
2020-04-15 19:14 ` bugzilla-daemon
2020-04-15 19:16 ` bugzilla-daemon
2020-04-15 19:17 ` bugzilla-daemon
2020-04-15 19:19 ` bugzilla-daemon
2020-04-15 19:21   ` Cole Poirier
2020-04-15 19:25     ` Luke Kenneth Casson Leighton
2020-04-15 19:29       ` Cole Poirier
2020-04-15 19:34 ` bugzilla-daemon
2020-04-15 19:54 ` bugzilla-daemon [this message]
2020-04-15 21:30 ` bugzilla-daemon
2020-04-16  7:53 ` bugzilla-daemon
2020-04-16  8:53 ` bugzilla-daemon
2020-04-16  9:48 ` bugzilla-daemon
2020-04-16 15:36 ` bugzilla-daemon
2020-04-16 16:22 ` bugzilla-daemon
2020-04-16 16:46 ` bugzilla-daemon
2020-04-16 16:59 ` bugzilla-daemon
2020-04-16 17:16 ` bugzilla-daemon
2020-04-17 12:29 ` bugzilla-daemon
2020-04-17 17:19 ` bugzilla-daemon
2020-04-17 17:28 ` bugzilla-daemon
2020-04-17 17:31 ` bugzilla-daemon
2020-04-17 18:02 ` bugzilla-daemon
2020-04-17 18:37 ` bugzilla-daemon
2020-04-17 18:38 ` bugzilla-daemon
2020-04-17 18:42 ` bugzilla-daemon
2020-04-17 19:36 ` bugzilla-daemon
2020-04-17 19:56 ` bugzilla-daemon
2020-04-17 19:59 ` bugzilla-daemon
2020-04-18 21:52 ` bugzilla-daemon
2020-04-20 21:51 ` bugzilla-daemon
2020-04-20 22:43   ` Jacob Lifshay
2020-05-05 13:17 ` bugzilla-daemon
2020-05-05 14:04 ` bugzilla-daemon
2020-05-05 14:06 ` bugzilla-daemon
2020-05-05 14:29 ` bugzilla-daemon
2020-05-05 14:42 ` bugzilla-daemon
2020-05-05 14:52 ` bugzilla-daemon
2020-05-05 14:53 ` bugzilla-daemon
2020-05-05 14:55 ` bugzilla-daemon
2020-05-05 14:58 ` bugzilla-daemon
2020-05-05 15:00 ` bugzilla-daemon
2020-05-05 15:00 ` bugzilla-daemon
2020-05-05 15:10 ` bugzilla-daemon
2020-05-05 15:10 ` bugzilla-daemon
2020-05-05 15:13 ` bugzilla-daemon
2020-05-05 16:03 ` bugzilla-daemon
2020-05-05 16:12 ` bugzilla-daemon
2020-05-05 16:16 ` bugzilla-daemon
2020-05-05 16:28 ` bugzilla-daemon
2020-05-05 17:02 ` bugzilla-daemon
2020-05-05 17:30 ` bugzilla-daemon
2020-05-06  9:53 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-208-13-IhLBD1iyUg@https.bugs.libre-soc.org/ \
    --to=bugzilla-daemon@libre-soc.org \
    --cc=libre-riscv-dev@lists.libre-riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Libre RISC-V Mailing list Archives (accessible via public-inbox)

Archives are clonable: git clone --mirror https://inbox.libre-soc.org/libre-riscv-dev

Example config snippet for mirrors


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git