I'm cross posting this to comp.lang.fortran since Glen hangs out there and
seems to have good recollection of all things numerical on early IBM boxes.

nmm1@cam.ac.uk wrote:

> In article <f7ddc15015d93c5e12b27e7b52d8dcf4@dizum.com>,
> Nomen Nescio <nobody@dizum.com> wrote:
> >
> >> On such systems, and on all for division, the instructions were trapped
> >> and emulated.
> >
> >Now that is curious. If so I wouldn't have expected to see the Divide in the
> >Principles of Operation.
>
> It wasn't actually an opcode - merely a macro for an extended opcode,
> and was reserved so that compilers could generate the code and the
> run-time system trap and emulate it.

Four floating point divide opcodes are defined in the Principles of
Operation along with descriptions of how they work. I'm referring to
GA22-7000-4 dated Sept. 1975 which I believe is available on
bitsavers.org. Perhaps you have confused this with the 360?

> >> If I recall, the division microcode was enabled only under MVS/XA.
> >> The emulation was typically available only for Fortran or if you
> >> wrote the handler yourself, though the emulation code was built-in.
> >
> >The hardware divide is noted back to 1974, well before XA (1981/82). It had
> >to have been implemented somehow back then.
>
> By the Fortran run-time system trapping the interrupt. There may
> have been a machine that implemented it in hardware, but none of
> the standard ones did.

Many 360 & 370 opcodes were microcoded and are to this very day on
z/Arch. That does not imply the use of macros or traps, it's transparently
supported by the processor. Interrupt handling is very expensive on MVS and
I would be very surprised if FORTRAN used this for anything other than the
normal SPIE processing of application programming exceptions such as
zero-divide, underflow, etc. I would think the Extended Floating Point
facility is nothing more than microcode assists but even so 4 flavors of
hardware divide seem to be supported in the base architecture.

> >> The format was also damn-near useless for most purposes, because it
> >> had the same exponent range as the lower precisions (10^75).
> >
> >That sounds right but I think the significant digits in the mantissa
> >helped. They couldn't get past their excess 64 notation until they finally
> >implemented IEEE maths.
>
> Essentially only for things like inner products, and even then
> you had to scale. Been there - done that :-)