Re: Math emulator

You (Andrew Valencia) wrote:
>
> [Peter Holzer <hp@quasi.vmars.tuwien.ac.at> writes:]
>
> >How about using a soft-float library? If our shared-lib plans ever take
> >off, this library could use 387 instructions on machines which have one,
> >and 386 instructions on other machines. Sure this is not as fast as
> >using inline code, but I think it is a fair compromise if you want to
> >distribute binaries (If you really want speed, you probably want to
> >recompile with -mi486 or something, anyway).
>
> My reaction is that we may as well use the default in-line code, with
> the reasoning being that if you're running FP on a non-FP-equipped machine,
> you're really not getting performance anyway.

Yes, but for some applications it may be enough. I don't do raytracing
or finite-element simulation, so FP performance is not really a concern
for me. I was quite happy with Turbo-C, and very disappointed with both
GCC on Minix and DJGCC, because they were at least one magnitude
slower (DJGCC has become a lot better, it is now almost as fast as
Turbo-C. Bruce Evans' soft-float library is a lot faster).

> My plan is to use the Plan9-style of signal handling. Because this
> specifies that signal handling completion happen with an explicit
> call (as opposed to UNIX, where you do a subroutine return), there is
> no need to do that trampoline hackery.

I don't think it makes much difference, whether the signal handler
itself calls sigreturn (or whatever it is called) or falls into it. The
performance problem in Minix was that a hardware generated signal would
trap into the kernel, which would send a message to the memory manager,
which would send one to the system task, which would set up the stack
for the process, make it runnable, and tell MM that all was ok. 5 task
switches (between rings 0, 1, and 3) for every FP instruction. Actually
the new signal code (which calls sigreturn at the end to restore the
signal mask) would add another two task switches.

> Since the FPU-not-present exception gets its own vector, it really
> shouldn't be too hard to point this back into the ring3 code somewhere.
> Adding this would be a nice part of the overall 387 support work.

Good.

        hp

-- 
   _  | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| |   |  ...and it's finished!  It only has to be written.
__/   |         -- Karl Lehenbauer