On Thu, 8 Feb 2001, Kevin D. Kissell wrote: > Well, in fact it ends up being both. The compiler substitutes library > invocations for FP instructions, one-for-one. That's a compiler emulator. You need to generate special code and place handlers in libgcc just like it's already being done for integer operations not supported by a CPU. I suppose all necessary glue code is already present in gcc. > The notion of using libc emulation based on catching SIGFP, > on the other hand, is so silly that I didn't even understand that > that's what you were referring to! It would be an amazing pig, > and there are corner cases, such as the emulation of the > instructions in the delay slot of branch-on-floating-condition, > that would be damned difficult to handle that way. How much more difficult than in the kernel? The kernel needs to take care of these case as well. Do you mean we miss certain information that is available for the kernel in the epc register? Well, we may always make the kernel pass it back, if needed. I'm not particularly amazed by the idea, but it's certainly doable. > > > > You never want to configure glibc with the --without-fp option. > > > > > > That's certainly what we had to do for OpenBSD without FP > > > emulation! What is the alternative? > > > > Write one. ;-) > > I don't understand, the alternative to building a --without-fp > glibc (which Carsten and I did for OpenBSD once already) > is to write *what*? An FP emulator for OpenBSD. Not that I care much... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
