Subject: Re: Optimized kernel for PB520
To: Joe Laffey <joe@laffeycomputer.com>
From: Frederick Bruckman <fredb@immanent.net>
List: port-mac68k
Date: 11/29/2004 02:17:09
In article <Pine.NEB.4.61.0411281228490.18889@phenotype.laffeycomputer.com>,
	joe@laffeycomputer.com (Joe Laffey) writes:
> I am trying to build a minimalist kernel for this 520c PB with 8mb (I 
> know, buy more ram ;-)
> 
> I was wondering....
> 
> I should enable FPU_EMULATE, obviously, but what about FPSP? Also, can I 
> use -m68040 with -msoft-float ? I have them both in there now, but does 
> -m68040 imply having an FPU? I thought it had more to do with some 
> interger math operations that are handled with a single instruction in the 
> 040 vs the 030 and earlier.

The kernel must always be built with -msoft-float (and is, if you set
options the usual way, with "COPTS" or "CPUFLAGS"). As I understand it,
each process's floating point context is saved in the pmap on switching
to kernel mode, and restored when the process is run again, but there
is no place to save kernel floating point context.  This negates much
(all?) of the advantage of building the kernel with "-m68040", but it
doesn't hurt. (I do it.)

The most important optimization is to comment out "options M68030"
and "options M68020", which causes some run-time case statements to
be optimized away completely.

With a 68LC040, FPSP is doing you no good at all. That module is an
exception to the "no floating point in kernel". It consists of 68040
floating points instructions, supplied by Motorola (as machine code)
to exactly emulate the 68881 FP instructions.  As you don't have a
68040 floating point unit, the kernel should have set up the trap
table to go into FPU_EMULATE for any FP traps, so your system never
uses any of the FPSP code.

You're lucky that FPU_EMULATE works at all; many LC040's are broken
in some way which makes it impossible to emulate FP correctly.  Even
so, you'll probably get better performance if you build all binaries
with "-msoft-float"--in which case you won't even need FPU_EMULATE--as
that saves the overhead of a "trap".  If you do that, you'll also save
the kernel memory that FPU_EMULATE uses.  You could update to a
soft-float snapshot from within NetBSD, using "tar -C / -xzpf ...".
If it's a current snapshot, don't forget to update the kernel first.


Frederick