"John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
news:YCXxf.66$Fd6.27@[EMAIL PROTECTED]
> robin wrote:
> > "John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
> > news:E1Uxf.1208$l03.452@[EMAIL PROTECTED]
> >> hancock4@[EMAIL PROTECTED]
wrote:
> >>> John W. Kennedy wrote:
> >>>> It is very well known that the entire 360 FP feature could have
used
> >>>> some input from numerical analysts; it's shot full of design
defects.
> >>> Could you elaborate on those design defects?
> >>>
> >>> How did S/360 compare with its predecessor machines (ie 709x)
regarding
> >>> those defects? What differences did competitors machines--those
> >>> available in 1965--have compared to S/360 regarding these defects?
> >> To start with, the S/360 word was four bits shorter than the 704
word.
> >> This was, at least, a strategic error, because it meant that
/up/grading
> >> to a 360 meant, in this area, a /down/grading in function.
> >
> > Yes and no. Double precision gave 28 extra bits.
>
> The 704 family offered double precision, too; it was not fully
> implemented in hardware, but the hardware assisted it, and the FORTRAN
> compiler sup****ted it.
It had to, in order to meet the standard.
> > But for most work, little difference between 36 bits and 32 bits.
> > But that's no measure, anyhow. The appropriate measure is
> > the number of mantissa bits and range of exponent.
>
> They add up to the word size, one way or the other.
Not relevant; what's im****tant is the breakdown --
and in particular, the number of mantissa bits.
> In any case, the
> S/360 had significantly fewer effective fraction bits (21) in single
> precision than the 7094 (27).
Leaving only 7 bits for the exponent. In other words, a reduced
range of exponent, which the S/360 corrected.
> In practice, a very, very large number of
> FORTRAN programs had to be altered to use double precision where single
> precision had once served.
I do not recall receiving a single complaint of that category,
even though the machine that we upgraded from used 31
mantissa bits for scientific work.
BTW, the PL/I SSP for the S/360 used - wait for it - SINGLE precision
as the default. Many of those for FORTRAN SSP were
provided only as single precision, some both single and double,
some double.
> > And as for a "strategic error", the S/360 was the only architecture
> > that was copied around the world [apart from the PC],
> > and is the only architecture that survives from the 1960s and earlier
> > [albeit updated].
>
> The _whole_ S/360 architecture was copied, but, whereas the 8/16/32/64
> two's-complement, byte-addressable data architecture has become
> universal, the S/360 floating-point design was never used outside of the
> context of full S/360 compatibility,
The S/360 was not copied in its entirety, and even in those
cases where it was not copied in its entirety, the
original hex floating-point design was retained
(without guard digit on double, with zero for underflow, etc)
> and the modern descendants of the
> S/360 now offer the vastly superior IEEE-754 as an alternative. Note,
> too, that floating-point has become nearly a dead issue in the S/360
> world; the z/OS FORTRAN compiler is decades old, and several generations
> out of date.
>
> >> But the hexadecimal base further meant that the effective length of
the
> >> fraction was essentially 21 bits (single precision) or 53 bits
(double
> >> precision), rather than the superficial 24 or 56, and this was not
> >> clearly understood at first.
>
> > I never had any difficulty with that, and I suspect
> > that nobody else did either.
>
> There were many problems with S/360 floating point in the early days;
Strange, we got along well with F.P.
And both machines that we subsequently obtained used
the original hex floating point (without guard digit, etc).
It is clear that it was not the problem that you imagine.
So-called "clones" retained the hex model without guard
digit on d.p. Strange, that.
How come *they* did not get "many problems"?
And if it was as bad as you claim, how come they
never implemented something better?
> the literature was awash with the subject.
Such as?
> > How would you have done it better?
No idea?
> > With binary, you would have, say, 21 bit mantissa plus sign
> > and 9-bit exponent plus sign (or biased 10 bits).
> >
> > The reason for chosing the 8-bit exponent field was influenced by
> > byte-orientation, which, among other things, permitted instructions
> > like IC and STC to manipulate the exponent.
>
> In other words, hardware convenience at the cost of usability.
>
> > Then there was the question of performance during pre- and
> > post-normalising ****fts of 4 bits at a time (maximum of 6 ****fts
> > for single precision) for hex is a lot quicker than 1 bit at a time
> > for binary (maximum 24 ****fts) [single precision, and corresponding
> > values for double precision].
> > The choice gave a range of 10**-78 thru 10**75 IIRC,
> > while some competitors had a less-accommodating range of
> > 10**-35 to 10**35.
> >
> > And if you chose 24 bit mantissa, that would give you 7 biased
> > exponent bits, or 6 real bits. Which doesn't give you an
> > exciting range of exponents, to put it mildly.
> >
> >> Other problems were corrected in a massive Engineering Change, which
> >> added a guard digit to double precision, added postnormalization to
the
> >> halve instructions HER and HDR, and changed the results returned in
> >> cases of overflow and underflow.
> >
> > Are you sure of that? The 1964 Principles of Operations
> > states that a zero word is returned for underflow,
> > which it always did.
>
> That was before the Engineering Change. After the Engineering Change, if
> the Underflow Mask bit in the PSW is 1, the exponent is wrapped (i.e.,
> is set to 128 more than the correct value).
>
> >> The early competitors generally had words longer than 32 bits, but I
am
> >> not familiar with any of them in detail.
> >
> > Competitive equipment had 32 bits, 48 bits, 36 bits, 60 bits
> > but in the main, more than 32 bits was scarcely the rule.
>
> 32 bits was rare before the 360.
Bendix?, Pilot ACE, DEUCE come to mind as 32-bit machines.
Others had 16 (or was it 18?) and 12 IIRC.
Others having a longer word were designed thus to accommodate
two instructions of, say, 24 bits, and the integer size was 24 bits.
The real problem with the S/360 was not the FPU but
with the fact that you didn't get many bangs per buck.
For some work, the machine that it replaced was faster.
|
