glen herrmannsfeldt wrote:
> John W. Kennedy wrote:
>
>> robin wrote:
>
>
> (snip)
>
>>> But for most work, little difference between 36 bits and 32 bits.
>>> But that's no measure, anyhow. The appropriate mesaure is
>>> the number of mantissa bits and range of exponent.
>
>
>> They add up to the word size, one way or the other. In any case, the
>> S/360 had significantly fewer effective fraction bits (21) in single
>> precision than the 7094 (27). In practice, a very, very large number
>> of FORTRAN programs had to be altered to use double precision where
>> single precision had once served.
>
>
> That may be true, but the for many numerical algorithms the number of
> bits required increases as the size of the problem increases, which
> likely would have happened in the transition from 7094 to 360.
In the early 1960's when I worked at a Division of North American
Aviation (the aerospace ****tions now owned by Boeing) we received the
second 360/65 on the West Coast, and we were an IBM beta site for
several of their software products. The biggest headaches we had in
migrating programs from 7094 to 360 were (1) learning job control
language (JCL), and (2) redeclaring Fortran variables from single- to
double-precision where the loss of 4 bits made a difference. Since we
were on cost-plus government-funded projects the efficiency of the 360
in terms of an extra machine cycle per F.P. computation was of
absolutely no consequence monetarily or operationally.
>
> If the speed ratio was much smaller on 360 than 7094 that would
> also have helped.
>
>>> 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].
>
>
> (snip)
>
>>>> 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.
>
>
> For many algorithms the average number of bits, 22.5, is more
> representative than the minimum. There is always a tradeoff between
> exponent and fraction.
>
>>> 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;
>> the literature was awash with the subject.
>>
>>> How would you have done it better?
>>> 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.
>
>
> There are formats which use an 8 bit exponent followed by the sign and
> fraction. That allows the exponent to be manipulated using byte
> instructions.
>
>> In other words, hardware convenience at the cost of usability.
>
>
> Mostly I would say that it took more work to come up with algorithms
> suitable for HFP. I explained previously the modification to the SQRT
> algorithm, simple once you know it but someone had to figure that out.
>
> (snip)
>
>>> 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.
>
>
> One of the results of designing a machine useful for both fixed and
> floating point problems.
>
> -- glen
>
>
|
