delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/14/03:23:45

Date: Mon, 14 Jun 1999 10:20:54 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Eric Rudd <rudd AT cyberoptics DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: libm sources from cyberoptics
In-Reply-To: <3763E492.DE5D8281@cyberoptics.com>
Message-ID: <Pine.SUN.3.91.990614102005.21962D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sun, 13 Jun 1999, Eric Rudd wrote:

> > I'm not sure whether this is a bug in Gas or something else.  One
> > thing that confuses me is that I don't understand how your code was
> > supposed to work.
> 
> In many of the routines, I have comments that indicate the current
> contents of the coprocessor stack

Sure, and they are very helpful.  It's the contradiction between these
comments and the documentation of the FP instructions that got me
bogged.

> In view of the problems you have had, I think the only feasible solution
> is to emit the correct opcode bytes directly, thus bypassing the assembler
> altogether.

Wouldn't using FSUB and FXCHG be a better way (albeit a slower one)?

But if you think that using opcodes is better, then go for it.  I
suggest leaving a comment there explaining why this was done.

> > 2) exp2 and exp10: I checked again, and they indeed set errno for the
> >    last two Elefunt tests.  The original test program didn't do that
> >    because I failed to see that your source defines __pow2, not pow2,
> 
> I need to put in proper stubs for these.

No, you don't.  The library build procedure does that automatically,
by reading <libc/stubs.h> and generating an assembly module for each
one of the #define's.

My problem was caused by the fact that I didn't replace the math
functions in libc.a with you versions.  Instead, I made a separate
library and linked the test programs with "make LIBS=libm1.a".  My
mistake was that I didn't realize that exp2 is #define'd by the test
programs to pow2, and pow2 lives only in libc.a.  The rest is history.

So you can stop worrying about this aspect, it was simply my mistake.

> I hope at least you're using -fno-builtin; otherwise some of my
> routines (such as sqrt, sin, and cos) don't get called at all!

The test programs are compiled without optimizations, so the built-ins
aren't used, at least with GCC 2.7.2.1 (which is what I used).  Also,
when the built-in raises an FP exception, the code emitted by GCC
automatically calls the library function, so the errno-related issues
don't get affected by this.  Lastly, I did step with a debugger into
the programs and made sure the library functions get indeed called, at
least in those cases where I had something strange to investigate.

> > Provided we find a solution to asin and acos, this leaves the
> > following issues:
> 
> I'm still thinking about these issues; here are my current inclinations,
> based on recent discussions on djgpp-workers (I'm still open to discussion):

Personally, I don't have anything against your suggestions, so let's
go with them, unless somebody else objects.

> There was much discussion in djgpp-workers about pow(0.,0.).  I think I will
> probably change it to return 1., but indicate a domain error.

Seems like nobody is opposed, so let's do it.

> There's also the issue of whether the control word needs to be maintained in
> round-to-nearest.  I'll look at the 387 manual, to see if we need to do
> that.

The docs I sent to you explains that people should not mess with the
rounding mode, but if they do and cannot restore it, they should link
with -lm (which doesn't depend on FPU's rounding mode) and pay the
price in slow-down and perhaps some inaccuracy.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019