gson@araneus.fi (Andreas Gustafsson) writes:
> My problem is that when I do this, the kernel panics with 
> "npxsave: masked".  My modem code relies heavily on floating point,
> and apparently NetBSD/i386 does not fully support the use of floating
> point in kernel code.

s/does not fully support/explicitly forbids/  8-)


> So, I am wondering, is this lack of support for floating point in the
> kernel on the i386 port
> 
>  a) considered a bug or a feature?

Feature.  It's a performance issue:

If you can use FP in the kernel, then unless you're very careful about
saves and restores around the places where you want to do FP work, you
need to save FP state in every interrupt and trap entry and exit
routine.

If you consider a modern processor, e.g. Alpha, where you've got 31 8
byte FP regs and an FPCR, you're throwing away no less than half a MB
of memory bandwidth, untold cache lines, tlb misses, etc., per second
-- that's just counting the saves and restores caused by clock
interrupts, not even syscalls or other interrupts...

In effect, you're (probably more than) doubling your interrupt/trap
handler overhead.


>  b) fixable?

You can probably fix it, but again, it's not desirable that you do so.
I doubt that NetBSD would buy back the fix, even if you do, but i'm
not authoritative there.

You won't be able to fix it as an LKM, though.  you need to replace
choice bits of existing code.


>  c) affecting other NetBSD ports besides i386?

Yes, many.  (Note that some systems that NetBSD runs on don't _have_
FPUs at all, e.g. SA-110.)


>  d) affecting other modern Unix-like systems besides NetBSD?

Yes, as far as I know.  From what I understand, it's not an uncommon
restriction.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
Plug: Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/