From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.99.102.68 with SMTP id a65mr138176pgc.122.1481848684317; Thu, 15 Dec 2016 16:38:04 -0800 (PST) X-Received: by 10.157.37.247 with SMTP id q110mr29335ota.5.1481848684259; Thu, 15 Dec 2016 16:38:04 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!b123no548998itb.0!news-out.google.com!u18ni10560ita.0!nntp.google.com!75no544269ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 15 Dec 2016 16:38:03 -0800 (PST) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8d0f7f03-9324-4702-9100-d6b8a1f16fc5@googlegroups.com> Subject: Trigonometric operations on x86 and x64 CPUs From: Robert Eachus Injection-Date: Fri, 16 Dec 2016 00:38:04 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32862 Date: 2016-12-15T16:38:03-08:00 List-Id: A while back I expressed surprise that there were no versions of the Elemen= tary_Functions package for x86/x64 packages which used the built-in trig fu= nctions of the x86 family. It looked like an easy project but... It turns out that the only trig functions available are the former x87 inst= ructions which use a special stack. Not a problem--except that these instr= uctions are not reachable in (64-bit) "Long_Mode". You have to have a sepa= rate compilation unit that switches to one of the 32-bit modes. Okay... Bu= t you also need to support saving and restoring the x87 register stack. Th= ere is a protocol for doing that, but 64-bit code can't do it. You would t= hink "No problem 64-bit programs can't execute x87 instructions anyway." E= xcept, that is exactly what you are trying to do! So you need to call a co= mpatibility mode proceedure every time the CPU does a 64-bit context switch= .=20 At this point, I was ready to give up on the project as a bad job. I could= modify the stack save/restore code on Linux, but even then I would have a = distributed cost. Then I ran across a page which explains that the Intel i= nstructions use a 66-bit representation of Pi, and that results from the ra= nge reduction folding done in the software, is some values having only four= accurate significant bits! It looks better when expressed relative to the= argument in radians--but often you want to find sine or cosine of an angle= in degrees... Anyway, turns out you don't want a package that uses the built-in trig func= tions. What about square root, logs, and e^x? They should be all right bu= t you still have the nasty distributed overhead. Oh! And the stored values = for e, and the logs to convert to base 2 or 10 are all 66 bit. Maybe some = future instruction set extension will provide correct versions of the trig = functions without the 32-bit mode requirement.