Subject: Re: IEEE FP on VAX? [was Re: Trouble by compiling/configuring Perl5
To: Matt Thomas <email@example.com>
From: Brian Chase <firstname.lastname@example.org>
Date: 01/02/2001 15:24:18
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 Chase | email@example.com | http://world.std.com/~bdc/ -----
Doctor: I'm afraid I've got really bad news. You have cancer
Patient: Well... at least I don't have cancer.