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.36.117.194 with SMTP id y185mr2445590itc.0.1482076024531; Sun, 18 Dec 2016 07:47:04 -0800 (PST) X-Received: by 10.157.8.134 with SMTP id 6mr601329otf.17.1482076024456; Sun, 18 Dec 2016 07:47: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!75no1349058ite.0!news-out.google.com!c1ni3356itd.0!nntp.google.com!75no1349055ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 18 Dec 2016 07:47:04 -0800 (PST) In-Reply-To: <295c603e-920d-4405-afb6-084d3d165112@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW NNTP-Posting-Host: 199.203.251.52 References: <8d0f7f03-9324-4702-9100-d6b8a1f16fc5@googlegroups.com> <295c603e-920d-4405-afb6-084d3d165112@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <402a5703-6155-4d4f-ab62-feb29c5687c5@googlegroups.com> Subject: Re: Trigonometric operations on x86 and x64 CPUs From: already5chosen@yahoo.com Injection-Date: Sun, 18 Dec 2016 15:47:04 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32912 Date: 2016-12-18T07:47:04-08:00 List-Id: On Sunday, December 18, 2016 at 4:19:12 PM UTC+2, Robert Eachus wrote: > On Sunday, December 18, 2016 at 5:09:55 AM UTC-5, already...@yahoo.com wr= ote: >=20 > > Such implementations are common, due the hype created by sensationalist= s.=20 > > But, for reasons stated above, I personally consider them as disservice= for > > overwhelming majority of users that would be served much better by usin= g x87 > > implementation "as is". >=20 > I am one of those other users.=20 What do you mean? Are you one of 99.9999% that will be better served by fptan instructions 'a= s is' or one of 0.0001% that can benefit from more precise range reduction? > In paricular tangents near Pi/4 (90 degrees) pi/2 > have very large swings for small errors. A bad value of Pi can result in= a very large negative value for the tangent instead of a very large positi= ve value.=20 How do you calculate argument of tangent? Is it result of addition/subtraction? In this case you are crying over spil= led milk, because addition/subtraction already killed the precision of the = argument and precision of evaluation of tangent is already irrelevant. Or is it a result of multiplication by PI? Then you are using wrong functio= n. You should use tanPi(). Well I know, easier said than done. tanPi() is a= part of IEEE standard for more than decade, but it is still not part of st= andard libraries for majority of popular languages. So, what should you do if you want to calculate tan(x*pi) for value of x ve= ry close to 0.5 and tanPi() is not available? The answer is obvious - calculate 1/tan((0.5-x)*pi). Anyway, more precise argument reduction for tan() is not something that can= help your case. > =20 > > I think that you have some misconception about x87 in long mode. > > FYI, as far as hardware and popular x64 OSes (Windows/Linux/BSD, I supp= ose MAC OS/X too, although I don't know it for sure) goes, x87 in long mode= just works. >=20 > For now, maybe: >=20 > "Early reports claimed that the operating system scheduler would not save= and restore the x87 FPU machine state across thread context switches. Obse= rved behavior shows that this is not the case: the x87 state is saved and r= estored, except for kernel mode-only threads (a limitation that exists in t= he 32-bit version as well). The most recent documentation available from Mi= crosoft states that the x87/MMX/3DNow! instructions may be used in long mod= e, but that they are deprecated and may cause compatibility problems in the= future." (From Wikipedia) Sounds like political bullshit. Neither Microsoft nor other major OS vendors will ever stop saving/restorin= g x87 state on task switch on x64 platform. Because disadvantages of doing = so are too big and *technical* (as opposed to political) advantages are alm= ost non-existing. They (Microsoft) surely want to maximize similarity between x64 and other p= latforms, esp aarch64, and they surely would like to kill x87 because of th= at, but they simply can't do it. >=20 > Obviously, a package which results in garbage if some other thread runnin= g on the same CPU core is using MMX or x87 instructions is not something I = want my name attached to. That means that I have to either figure out a te= st* which guarantees that the x87 registers are saved and restored correctl= y, or mark the package as 32-bit compatibility code. It is always saved/restored. It will continue to be saved/restored for as l= ong as x64 platform is supported. >=20 > By the way, you may want to check which mode of code your compiler puts o= ut. For (AMD and Intel) x64 CPUs there are three: Legacy, Compatibility, a= nd Long modes. Long mode uses 64-bit addressing throughout. Compatibility = mode allows users a 32-bit (4 Gigbyte) virtual address space per program/ap= plication. A program can mix long and compatibility mode sections, and in = practice most libraries are compatibility mode. I don't understand what are you talking about. In-process libraries, like those that we discuss, always run in the same mo= de as the rest of the process. At least that's how it works on Windows/Linu= x/*BSD on x64. I heard that IBM z/OS works differently, but in context of x87 that particu= lar bit trivia does not appear relevant. >=20 > * The test can be in the body of the package and executed only once per p= rogram execution. If there were a bit I could check...