Whup, looks like there might be some trouble in slow VAX paradise.  There
are two varieties of MicroVAX I.  One of them supports F_float and D_float
FP data types; the other variety supports F_float and G_float.  According
to the VAX Arch Ref Manual, about 90% of all MicroVAX I systems made were
of the D_float variety with the remaining 10% being G_float.

Based on the circuit board markings, I'm fairly positive that I've got one
of the G_float systems.  The problem being that GCC generates D_float
opcodes and operands for the double and long double C types.  This opens
up a nasty set of problems for any applications which rely on double or
greater precision floating point operations.  Hopefully the kernel doesn't
rely on any FP ops.  I'm sure we can still get NetBSD up and running on
this. 

One option may be to trap D_float operations and "emulate" them by
converting the operands to G_float format, running the corresponding
G_float operator, and then coverting the result back to D_float.  You've
still got the overhead of the trapping and format conversions, but at
least you don't have to emulate the FP operations with complex collections
of integer based code.  Other options include generating G_float code
across the board for double and long doubles, but then this excludes the 9
out of 10 MicroVAX I systems which only support F_float and D_float.  Or
we could add a G_float compiler option and generate separate G_float
binaries specific for the bizarro MicroVAX I. 

I favor sticking with one set of VAX binaries and letting the kernel trap
for D_float ops on the MicroVAX I.  This should also guarantee that the
MicroVAX I w/G_float is the slowest of all VAXes.  I WIN!

-brian.
---
Brian "JARAI" Chase | http://world.std.com/~bdc/ | VAXZilla LIVES!!!