Re: Indirect Bit

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 :-)

In comp.lang.fortran Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> wrote:
> 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.

Only last week was discussion on the Q format descriptor and the
H Extended compiler that generated code for REAL*16 and COMPLEX*32
data types.

(snip)
>> >> On such systems, and on all for division, the instructions
>> >> were trapped and emulated.

This is a little hard to follow, but somehow regards extended
(quadruple) precision floating point on S/360 and S/370.
It is fairly well documented, including a whole article in the
IBM Systems Journal, and I have the issue that includes it.

>> > Now that is curious. If so I wouldn't have expected to see the
>> > Divide in the Principles of Operation.

Extended precision first appeared in the 360/85. There seems to have
been some system to test out different ideas on different S/360
models. Virtual storage first appeared on the 360/67, fairly close
to the way it was later done on S/370. IBM did studies and found
that extended precision divide was needed rarely enough that it
made more sense to implement it as software emulation.

One of my first disassembly projects, by hand, was IEAXPDXR and
IEAXPALL. The first is the emulation for DXR, the latter for all
extended precsion opcodes. (The DXR emulation in IEAXPALL directly
calls emulation routines for other extended precision instructions.)

>> 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.

Unlike the other RR instructions, which are two bytes long with
a one byte opcode, DXR is X'B22D' and a four byte instruction.

Now, exactly what the rules are on what instructions the assemblers
recognize I don't know, but yes there is a macro DXR to generate
the appropriate code. Note that the diagnose instruction, implemented
in hardware, has no assembler mnemonic. The extended branch
instructions (such as BNE, BGT, etc.) generate B instructions
with the appropriate mask.

MACRO
&LABEL DXR &R1,&R2
..* INSURE LABEL IS ON HALF WORD BOUNDARY
DS 0H
..* GENERATE OPCODE FOR EXTENDED PRECISION DIVIDE
&LABEL DC XL2'B22D'
..* USE EXTENDED PRECISION MULTIPLY INSTRUCTION
..* TO ALLOW THE ASSEMBLER TO DO THE REGISTER
..* ANALYSIS
MXR &R1,&R2
..* MAKE THE THIRD BYTE OF THE INSTRUCTION BINARY
..* ZERO, IE REMOVE MXR OP CODE.
ORG *-2
DC X'00'
ORG *+1
..* THE FINAL FORMAT OF THE EXTENDED PRECISION
..* DIVIDE INSTRUCTION, BYTE BY BYTE, IS
..*
..* B2 2D 00 R1R2
MEND

> 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?

It is not in the GA22-7000-3 version. Exactly which machines
did and didn't have it in hardware or microcode, I am not sure.

Many features and instructions described are optional on
different models.

>> >> 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.

IEAXPDXR and IEAXPALL are written to be called from an SPIE routine
after decoding an illegal opcode exception.

Now, the 360/91 didn't implement the decimal instructions in
hardware and instead the OS included the emulation routines.

Instead, these require the user to write an SPIE routine and
then call the appropriate routine from there.

>> >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).

The format is conveniently designed to simplify software emulation.
The significand is 112 bits, with a sign and exponent field in each
half. The instructions generate an exponent 14 less (unless it
wraps) for the low half.

>> > 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 :-)

-- glen