Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
paulkoning at comcast.net
Wed Feb 28 12:55:43 CST 2018
> On Feb 28, 2018, at 1:10 PM, David Bridgham via cctalk <cctalk at classiccmp.org> wrote:
>> Imagine our chagrin when days of trying to correct the
>> problem led to the conclusion that the diagnostic was incorrect.
> I may have a situation like this in working on my FPGA PDP-10. The
> Processor Reference Manuals seem quite clear that the rotate
> instructions take E mod 256. One of the manuals I've found even adds
> that they never move more than 255 positions. And yet the diagnostics I
> have clearly want ROT AC,-256 to move 256 positions to the right, not
> 0. Not having a real PDP-10 to compare against, I don't know which is
In general, manuals are only a rough approximation of reality. I remember an old joke that "PDP-11/x is compatible with PDP-11/y if and only if x == y". And sure enough, if you look at the models appendix of the PDP-11 Architecture Handbook you will see cleary that this is true. More precisely, it is if you ignore cases where two model numbers were assigned to the same thing, such as 11/35 and 11/40.
With the VAX, this got cleaned up to a significant extent, and ditto with Alpha. In both cases, an internal validator tool was created to verify that, at least from the point of view of instruction execution, a new machine worked the same as an existing reference machine. But this seems to be quite an unusual notion in the history of computer hardware development generally. Even when standard specifications exist that appear to spell out how an architecture is supposed to work, the reality is that two implementations will in general do it differently. That is particularly likely to happen in cases of "no one will do this" -- like shifts by more than the word size, or other oddball stuff.
And sometimes CPU designers do stuff that's just plain nuts, like the CDC 6600 which has a shift instruction where some of the high order bits must be zero and some are ignored. Or the way it executes a 30-bit instruction that starts in the last 15 bits of the instruction word. Both are cases where there is additional logic involved (or at least extra wires) to do something that clearly serves no purpose. And these things are definitely not documented in any user manual, though you can find them if you read the schematics carefully enough.
More information about the cctalk