Den 2019-02-08 kl. 08:54, skrev Martin Husemann:
I assume that the problem is that if you try to something with a number, and that operation will overflow a D-float, you will get a SIGFPE. The same operation could be legal for IEEE floats since the sizes of mantissa/exponent differ, and no programs these days care about anything else than IEEE floats :-)On Fri, Feb 08, 2019 at 04:50:58AM +0000, John Klos wrote:I've been thinking about issues with floating point exceptions on VAXen. Currently it's difficult to compile packages such as python which have tons of floating point tests because so many of them fail because of infinities or NaNs. awk is still problematic when used in pkgsrc because of FP exceptions.Can you explain a bit more details? Only changes I ever had to make were the slighly different limits, most other things just work fine and relying on NaN propagation in 3rd party software seems to be rare. The vax is indeed exception happy, but often this is triggered by bogus compiler output (like bit shift/mask operations out of range).
The best way would (of course) be to fix failing programs, but that would be a forever-going work since noone (except we) run on an non-IEEE platform.
There are no software floating point for D floats that won't generate exceptions (floats are standard on all vax).
So, what can we do?One way would be to default catch SIGFPE and write back something useful as result. I think I have seen an example of that somewhere?
Another way would be to make the VAX an IEEE-compliant platform :-) Combining the use of D/G float with SIGFPE and some checking would probably be quite possible.
-- Ragge