The 360/91 wasn't the only one with problems. When I played with the
Watfiv source there were comments here and there about problems
different model 360's had. Some were in error trapping. I don't
remember which model(s) (I still have the printed source), but some of
them wiht pipelines could not accuratly re****t what instruction caused
an error, just that it was one of the ones in the pipe that caused the
problem.
I believe some other early pipelined machines had this problem or even
worse ones. not only did they have problems with error tracing during
execution but sometimes the program counter wasn't properly tracked
during normal interrupts like I/O, timers, etc.
IIRC the UCLA people doing the IBM part of the network project I worked
on said their 360/91 would get slower as they added RAM due to the cable
lenghts between the memory boxes and the CPU box.
glen herrmannsfeldt wrote:
> Dan Nagle wrote:
>
> (snip)
>
>> No Cray-1 ever had hardware divide.
>> Floating point divide was always a reciprocal approximation,
>> followed by correcting multiplications. A special 2-a.b instruction
>> applied part of the correction.
>
>
> Well, it was used to implement divide in high-level languages.
>
> I thought I remembered that multiply was not accurate out to the
> last bit, the reciprocal approximation obviously isn't. Maybe the
> corrected reciprocal is pretty close.
>
> Back to the 360, the 360/91 uses a divide algorithm similar to Cray,
> except that it does the multiply at the same time. It generates a
> rounded quotient, unlike the truncated quotient that S/360 specifies.
> As a result, it violates the Principles of Operation by being closer to
> the right answer.
>
> -- glen
>
|
