Date: Mon, 14 Jun 1999 10:20:54 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Eric Rudd cc: djgpp-workers AT delorie DOT com Subject: Re: libm sources from cyberoptics In-Reply-To: <3763E492.DE5D8281@cyberoptics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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 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.