On 6/10/26 18:50, Mouse wrote:
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.
It does seem to potentially be pretty costly...
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.
Hmm. Maybe a good point. If we can't catch results that goes out the window with IEEE we need to not only check all incoming values, but we need to somehow also check the results...
This is getting uglier...
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.
Yeah. Looks like the whole mantissa is free to play with. Although I wonder if it can get messed up when you get traps?
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.
I do think the test suites are going to trip up, yes. And I guess you have a point. If we don't pass the test suite, what's the point? So I guess we need to do all of it...
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.
It does. But honestly, would we (or thew software) care? It's not like are requirements are very high precision FP math here, but to be able to get software running. But then again, I bet some test suites will check this too, and so we need to also deal with that, which is going to be way ugly. Because that will require post processing of every operation in a more complex way.
Johnny