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

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

>>> DEC float does have NaN, but it doesn't have Inf.
>> It doesn't have silent NaNs, and it's debatable whether reserved
>> operands are close enough to stand in for signaling NaNs.
> Those, and Inf are the question.  And are we expected to check before
> each FP operation if any of those numbers are an argument to the
> instruction and special case that?

That's what I read the original proposal as.

> In which we are talking about adding multiple checks before basically
> any instruction that touches FP.

Yes.  Or library calls, a la soft-float, but with the code backing
those calls using real hardware to do the heavy lifting in the common
cases.

I don't know how large the performance cost would be; presumably it
would depend on the underlying hardware, and I don't know how the cycle
counts of the various options stack up against one another.

> Or are we going to stuff in arguments that result in reserved
> operands whenever we see an Inf or NaN, and trap and special case it
> then.

That is a clever idea.  I don't think it would work, though; it will
work for Inf or NaN as in input operand, but possibly not for output
operands; I'm not sure whether all operations that generate NaNs under
IEEE will fault on a VAX.

> Do we have enough reserved operands to represent these different
> values?

I'd have to check the details, but I *think* so.  I think IEEE
shoehorns infinities, and both kinds of NaN into the space VAXen
consider reserved operands.

>> VAX float also doesn't have subnormals.
> Also true, but I think we could possibly ignore that one.

I doubt it.  Most software will let you ignore the whole issue except
for the test suite, yes, but if you're going to bother providing Inf
and quiet NaNs you really should provide subnormals and rounding
control as well - I would guess, admittedly without any real basis,
that subnormals get more use than infinities or quiet NaNs.

> Just as I think the rounding differences can be ignored,

That too would be a problem point.  I think IEEE requires the ability
to control the rounding mode.

/~\ 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