17
Full disclosure: I worked on the x87 FPU of a 486-class CPU at a math-coprocessor company in the early 1990s and thereafter worked at AMD, where I was on the 3DNow! design team and the design team for the FPU of the AMD Athlon processor (also known as K7).
The x87 FPU never acquired a flush-to-zero mode. In fact, denormal support was one of the major ...
14
The MC68882 was relatively well-regarded among 1980s FPUs. Digging out accurate timing information takes some effort, but it appears that handling denormalised values was only moderately burdensome for this FPU. In the context of a register-to-register FADD already taking several dozen clock cycles:
Taking a denormalised extended-precision source operand ...
12
While this may cover many ways of overflow (from integer and counter all the way to record, I assume the Overflow in question is about floating point, which more precisely means over/underflow of the exponent.
The exact handling varies widely between compilers and machines. Fortran 77 did not make any assumptions here (AFAIK), it at all, it was expected that ...
9
I don't recall any overflow handling on the FORTRAN 77 compiler that I worked on and supported (Honeywell Series 60 Level 62). Any overflow would cause a program abort, so it was up to the programmer to ensure that overflows did not happen. This compiler was designed to be compatible with IBM System/360 FORTRAN, and even used the same base-16 floating point ...
8
I only have experience of ICL mainframes, CDC, Prime 300, Data General Nova and Eclipse. On those, the programs just crashed. Like Mick's answer, it would be up to the programmer to figure it out. These were variants of Fortran II (lots of 3- way jumps), Fortran IV (or 66) and Fortran V (what the vendor called it).
Fortran was mainly used for High ...
5
Before IEE 754, there was no floating point equivalents to "NaN" or "Inf". Overflow, underflow, and division by zero generated interrupts which would be ignored, trapped, or terminated the program with a default error message (and most likely a core dump as well).
These options could often be controlled from Fortran by a collection of ...
4
As a Fortran Compiler writer for dusty deck (and other computers), let me add that many answers, although correct, are not focusing on the implementation Fortran language, but features that they might have remembered using from Fortran. Many of those features, although correctly described, are mainly about features provided by the operating system or run-...
3
On BESM-6 the ALU/FPU interrupts (overflow, division by zero) were inexact, thus it was impossible to recover and continue, but it was possible to handle them with a mechanism akin to the setjmp/longjmp capability in the C language, where the "setjmp" equivalent was IFOVFL(DUMMY), returning 0 at setup, and 1 on exception, and the "longjmp"...
3
The answer is "it depends".
If your object program is running on a machine that traps on arithmetic overflow, you'll get a trap on arithmetic overflow.
If there's a latching overflow indicator, there might be a way to interrogate it; with ICL 1900 FORTRAN, you could CALL OVERFL(K) to set K depending on whether overflow had occurred (K=1 for ...
2
The PDP-8, a tiny minicomputer compared to some of the examples here, did the following in its floating point package:
The input conversion routine halts on overflow during calculation of the mantissa. Typing RUBOUT and pressing CONTINUE on the console will restart the routine.
Overflow during exponent calculation yields an unpredictable result; the ...
2
In my dusty memory, F77 on a CDC Cyber 175 would crash on floating-point overflow, and I would assume that applies from 6600 to 176 as well. That might have been due to local setup.
Only top voted, non community-wiki answers of a minimum length are eligible
