Mail Archives: djgpp-workers/1999/06/14/03:23:45
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 -