Re: One more oddity with gcc and vax floats...

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> [emulate IEEE floating-point]
>> I'm not convinced.

Me neither.  "If you want IEEE-capable hardware, you know where to find
it."

The only benefit I can see to it is that it papers over software that
insists on IEEE float for no particular benefit.  Rust is an example;
almost all rust code, like almost all {C,FORTRAN,Python,etc} code,
doesn't care what the underlying FP is and would run fine on a VAX, but
rust specifies IEEE floats.

>> Starting to do all FP math in software will be costly, [...]
> Actually, it is possible to avoid that :-)

It'll still be costly compared to just doing VAX FP, just not *as*
costly as full soft-float.

> It should be possible to do all normal math using F- and G-floats +
> some extra instructions, with only the corner cases needed to be
> handled separately.

(a) What about VAXen that don't support G-float?  The MicroVAX-I is an
example, and the 11/780 and 11/750 had G-float only as options.  Are
any 780s or 750s without G-float known to still exist?  If not, is that
justification enough for assuming its presence?

(b) G-float has no denormals, infinities, or silent NANs.  (It's
debatable to what extent reserved operands can stand in for signaling
NaNs.)  Am I correct in assuming that the "some extra instructions" are
about making up for them?

It sounds as though what you're proposing amounts to what the compiler
thinks of a soft-float, but with the implementation routines using the
real hardware for most cases - or possibly open-coding the fast path.
Would that be a fair summary?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B