On Sat May 19 2001 at 17:33, Tom Oehser wrote:
> I am considering turning off the math emulation in the kernel.
Do it. (How much overhead is saved?)
(Can math emulation be available as a module? No, don't think so).
> This would mean that it would no longer work on machines with 386 and
> 486sx stuff without a coprocessor. But, how many of those machines have
> 8mb and use tomsrtbt, anyway? Is this a viable option to make the kernel
> smaller, or is this a bad idea?
I've been surrounded by all sorts of computers, hundreds of them,
all different shapes and sizes, for the past few years now. Except
for some kludgy old (discarded) laptops, I can't recall seeing a
386/no-copro or 486sx class machine up and running in all that
time... every one of them has had hardware math capability. These
old machines are so slow and getting so difficult to maintain or
upgrade that they are just not worth the time or effort.
So I wouldn't notice the difference if emulation was removed, and I
suspect that very few would. And those few can get around the
problem by building a new kernel.
But the kernel itself would boot without a copro, no problem. The
downside would be that applications might no longer be 100% useable
on those low-end boxes, with tomsrtbt one of the very few unix-based
tool that could be booted on them to, eg, assess the state of their
hardware.
Willian "Chops" Westfield said in another reply:
> How much of the tomsrtbt toolset itself actually requires floating point?
To which Tome Oehser replied:
> My understanding is that the kernel itself needs floating point to run,
> although I'm not really sure why. I could be wrong. -Tom
Disclaimer: I'm no big-time hardware junkie or kernel hacker, I
just get and keep the hardware up and running :-)
My understanding is that the kernel does _not_ need floating point.
Indeed, the policy is that floating-poing math code is forbidden in
kernel space. There is no "math.h/libm" equivalent in any of the
kernel headers or internal code.
I got this from a recent thread on another mailing list where
someone was asking about the use of floating-point in a kernel
module they were building... the general concensus was that f-p is
forbidden in kernel space, and in most cases the desired results
and accuracy can be obtained using integer math algorithms.
The only exception to this would be kernels (and applications?)
compiled specifically for i586 and better processors. (My
understanding is that the math processor is used by the kernel for
other optimisation tricks in these better class machines).
I guess the only definitive test is to try booting a tomsrtbt disk
with a kernel without math emulation on an old 386/486sx box, and
seeing what breaks :) (I suspect very few problems, if any).
Cheers
Tony
