"glen herrmannsfeldt" <gah@[EMAIL PROTECTED]
> wrote in message
news:m4ednbbFy-jGAibenZ2dnUVZ_s-dnZ2d@[EMAIL PROTECTED]
> robin wrote:
>
> > "glen herrmannsfeldt" <gah@[EMAIL PROTECTED]
> wrote in message
> > news:CZSdnfkDXvuBFyTeRVn-tg@[EMAIL PROTECTED]
>
> (snip regarding HER, HDR, and the lack of normalization in the early
> versions of S/360.)
>
> >>>Except, of course, initially for HER and HDR.
> >> The 1964 Principles of Operation makes this clear.
>
> (snip)
>
> >>Well, one could always add zero, still probably faster than divide,
>
> > Definitely faster than divide, but that took an extra instruction (4
bytes)
> > and possibly an extra constant (4 or 8 bytes) when there was precious
> > little store to hold the extras.
> > The real problem with HER and HDR, however, with the unnormalized
> > version was the loss of precision if the most-significant nibble ws 1.
>
> In sqrt you can likely live with that until the last iteration.
Not every program needs SQRT. In any case, it was probably
done by invoking a function, in which case, storage requirements
would not have been an issue.
Many programs, however, routinely require division by 2,
and as there may be a number of these in a program,
the amount of extra storage required would become a drawback.
> With the common implementation for binary machines, you lose, anyway.
> For S/360 the last iteration is done something like:
>
> y4=y3+(x/y3-y3)/2
>
> this is required for full precision HFP arithmetic, even with a
> normalizing HDR.
>
> (x/y3-y3) normally won't have many significant bits, so there is
probably
> no loss in the non-normalizing HDR.
The loss of a bit [non-post normalizing] for this step of halving
is irrelevant except for the last.
> It is also fairly common to do the initial approximation in fixed point.
> If one really wanted to, one could test the exponent bits prior to the
> HDR at the end.
The crux was that for general use, the original HER and HDR
were not as attractive as they would seem.
> -- glen
|
