"John W. Kennedy" <jwkenne@[EMAIL PROTECTED]
> wrote in message
news:ivXyf.40$gh5.16@[EMAIL PROTECTED]
> robin wrote:
> >>>> 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.
> >> There was no FORTRAN standard until long afterwards.
>
> > IBM set it.
>
> So your argument is that the 704 hardware had to implement
> double-precision floating-point in 1954 in order to sup****t FORTRAN IV,
> which didn't even come out until 1962 (two hardware generations
later)?
You said it ; I didn't.
> >>>>> 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 order to make any sense of your argument, I can only assume that
you
> >> do not know what the words "relevant" and "mantissa" mean. Kindly
look
> >> them up.
> >
> > The term "mantissa" has been used since the early days of computers
> > to describe part of floating-point number.
> >
> > Are you having a bad day?
>
> Either you are attempting to argue that the size of the fraction and the
> size of the exponent are each more im****tant than one another, while
> simultaneously maintaining that word size has nothing to do with the
> issue either way, or else you are simply misusing words.
Are you trying to divert attention from "mantissa"?
> >>>> 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.
> >> Having trouble with subtraction, are we now?
> >
> > When I last looked, 27 + 1 + 7 + 1 = 36.
>
> Are you under the impression that the 704 series had a 35-bit word with
> a parity bit?
You said 36 bits earlier.
> >>>> 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, 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.
>
> > You're overlooking, PL/I, which for which z/OS has a recent compiler.
>
> PL/I is not a major player in the raw-science market; if it were, IBM
> would have implemented PL/I sup****t for the (now dead, like every other
> attempt to put the 360 family back into the high-performance-computing
> market) 370 vector processor.
>
> >>> The S/360 was not copied in its entirety,
> >> Problem state was.
> >
> > Only the original, not the revised hardware, as I previously stated
(below).
>
> Indeed, even the TS instruction was not implemented.
>
> >>> 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)
> >> I'm sure IBM spent all that money upgrading all those machines
without
> >> payment just for fun.
> >
> > AFAIK, no-one else followed suite.
>
> Because they couldn't afford to.
Try again. They could have done it when the system
was built.
Most of the changes would have required only an alteration to
the ROM (except for the harwitred machines).
> >>> 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.
> >> It is clear that it wasn't a problem for /you/.
> >
> > It wasn't a problem for anyone in an extensive institution.
>
> It demonstrably was a problem. IBM spent a fortune fixing what could be
> fixed
Most of the changes would have required only an alteration
to the ROM.
> (note that it had to implement the change on at least seven
> different machine types), the literature was full of problems introduced
> by the S/360,
You still haven't named any.
> and, in the end, the S/360 and follow-up lines were never
> more than marginally successful in the supercomputing arena.
This was principally on account of the price of the machine
and speed (or rather, lack of), rather than any other factors.
FYI, our s/360 was slower than the machine that it replaced
for small jobs -- yet the machine it replaced was 50 times
slower (add time 64uS). When LCS was put on the S/360,
it ran even slower, because the OS took up most of the
fast memory, so that user programs were loaded into slow
memory.
One of the factors contributing to the slowness showed up
when we consistently got "disk overrun"s (with slow memory).
These errors only came up after some 250 attempts to read a track
of disc to memory, and each retry failed (DMA).
The remedy ? Increase the number of attempts!
> > I didn't buy anything. But I would point out that those
> > "cheap" systems had superior real-time performance, with
> > multiple resister sets and processor states for handling
> > interrupts.
> >
> >>> And if it was as bad as you claim, how come they
> >>> never implemented something better?
> >> They did. In 1967,
> >
> > No they didn't. I was referring to clones in which the guard digit
> > on d.p. was NEVER provided. [see above]
> >
> >>>> the literature was awash with the subject.
> >
> >>> Such as?
> >
> > Still no instance?
>
> Gee, somehow I can't find my old computer magazines from the mid-60's. I
> guess my mother threw them out with my comic books.
>
> >>>>> How would you have done it better ?
> >
> > Still no answer?
>
> I was in Junior High when these choices were being made. All I know is
> that they were found inadequate in the field by many customers.
|
