Re: "Double Precison" Keywords?

Sigh. The DXR instruction DID exist, and was generated by the
compilers. It was trapped and emulated by a combination of the
Fortran and PL/I run-time systems and supervisor code. In a
much later design (the System/390) it was provided in hardware,
and then the compiled code invoked it.

It is a little strange, though. It has a two byte opcode,
and so four byte instruction, unlike the other RR form
instructions.

For reasons that I never did understand, the assembler did not
originally have a DXR opcode, but had a macro that generated
the extended instruction code that was reserved for the actual
DXR instruction.

There must be some rule about the assembler and hardware
implementation of instructions. It seems strange to me, too.

And it was FAR more likely space, rather than time, given the
complexity of the emulation code - and, yes, I have worked on it.

IBM has been pretty good at doing statistical analysis
instead of just guessing.

Extended precision floating point was developed for the 360/85.

And they allowed for a future implementation of DXR in hardware
at that stage.

As you probably know, Fortran and I think PL/I ran on machines
with no floating-point, by emulating all of those instructions
in the same way that DXR was emulated.

You mean for S/360 processors? I know FP was available down
to the 360/30, and probably not for the 360/20. I might remember
that the floating point registers were implemented even on
machines without FP microcode. That makes the software
emulation much easier.

I don't remember seeing any such code, though. I have seen the
decimal emulation code for the 360/91. (Which, unlike extended
precision, was done all in the OS.)