On Tue, 2 Jan 2001, Matt Thomas wrote:
> At 01:02 PM 1/2/2001 -0500, Brian Chase wrote:

> >How would one go about doing an IEEE FP emulator for the VAX?  Obviously
> >this wouldn't be ideal in terms of performance but it would be useful.
> >Lots of FP dependent software assumes that you're using IEEE FP.  IMHO
> >this is more of a flaw in the software that makes that assumption.
>
> A lot of FP dependent software is wrong.  Considering how much engineering
> was done using VAX Fortran, I don't think you can say VAX FP is bad.  It's
> different from IEEE FP.  Most software never uses the IEEE rounding modes
> so it's not really an issue.

Oh, I'm definitely not saying it's bad.  I just know I've run into
problems with software wanting some type of IEEE support present before it
would work right.  POVray is an example of something I had difficulty in
getting to run under NetBSD/vax.

> >Maybe emulation is the wrong approach.  Would it be better to provide a
> >compile time library for programs wich need IEEE FP support?
>
> It would be very slow.

Eh, yeah.  Probably about as bad as when I was running Linux/i386 without
a mathco on a 386SX/16.  Likely a bit slower for the MicroVAX-II and
lesser machines, but still neat.

> >Given that we already have VAX FP instructions, I think that VAX based
> >IEEE support could be a lot faster in some cases than a purely integer
> >math based version.  You'd have to transform IEEE data into the VAX
> >format, run a VAX FP instruction, and then transform the result back into
> >IEEE.  I know it's more difficult than just that, but you should be able
> >leverage the existing FP support.
>
> VAX FP does many thing differently than IEEE FP so you can't use it to
> emulate IEEE FP.

Support exisits for IEEE FP on the Intel and ARM32 ports right?  The
386SX, 386DX, and 486SX processors don't support IEEE in hardware without
a mathco.  If they're emulating IEEE support using integer only
operations, I don't see why we couldn't do the same... only we'd be able
to add in VAX FP ops to speed things up a bit.  How much mileage could we
get out of doing the ops with the 128-bit H_float types, and then mapping
the results to smaller 32-bit and 64-bit IEEE formats?

> I have been thinking about adding G-Float libraries
> when I switch to ELF.  (I encode the executable float type in the ELF
> header so you can tell the difference and ld complain if you mix in
> the wrong types).  Note that the G float is closer in precision and
> range to IEEE FP double format.

Is the idea here that an executable would be able to dynamically link to
either G_float or D_float libraries depending on which 64-bit VAX FP type
the executable is expecting to use?  If so, that sounds interesting.

Under which circumstances would that be useful?

-brian.
--- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----
 Doctor:   I'm afraid I've got really bad news. You have cancer
           and Alzheimer's.
 Patient:  Well... at least I don't have cancer.