| glen herrmannsfeldt 2006-01-14, 7:55 am |
| John W. Kennedy wrote:
> robin wrote:
(snip)
[color=darkred]
> 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.
If the speed ratio was much smaller on 360 than 7094 that would
also have helped.
(snip)
[color=darkred]
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.
[color=darkred]
[color=darkred]
> There were many problems with S/360 floating point in the early days;
> the literature was awash with the subject.
>
[color=darkred]
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.
[color=darkred]
> 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)
[color=darkred]
> 32 bits was rare before the 360.
One of the results of designing a machine useful for both fixed and
floating point problems.
-- glen
|