[Simh] pdp11 fails MAINDEC CPU test 14 D0NA

Johnny Billquist bqt at softjar.se
Thu Jul 9 21:06:56 EDT 2020


On 2020-07-10 02:55, Paul Koning wrote:
> 
> 
>> On Jul 9, 2020, at 8:29 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> On 2020-07-10 02:19, Paul Koning wrote:
>>> The VAX architecture seems to have been an explicit design effort.  For the Alpha this was even more obvious, where a monstrously large book (certainly 500 pages, maybe double that) was written and reviewed in depth before anything was cast into silicon.  Not so for the PDP11, as you pointed out.
>>
>> It definitely was an explicit effort. I seem to remember seeing/reading somewhere at some point that this was because of what had happened on the PDP-11. So a lesson learned kind of thing.
> 
> At least DEC learned.  Too many other companies had the same opportunity but did not take it.

True. This was back when DEC was primarily an engineering company 
though. Before they became obsessed with becoming a new IBM...

>> ...
>>> My suspicion is that the PDP-11 architecture handbook was an after the fact effort.  The date (1983) supports that notion.  Also, it's a handbook, a fat paperback like the processor and peripheral handbooks.  I don't know of any internal analog, like DEC Std 032 for VAX.
>>
>> Yeah, I would expect that it would an after the fact thing. But it would still be interesting to see any effort made by DEC to put it all in one book. As mentioned, the list (maybe in different revisions) do exist in multiple other handbooks and manuals. But then it's just an appendix without much further analysis.
>>
>> I think I also saw/read somewhere that different new PDP-11 implementations basically tried to look at what had previously been done, and tried to just match that, as there was no official definition of a PDP-11. But then they always did some deviation or other for the sake of efficiency, cost or just clean up.
> 
> I think at least one or two differences were deliberate and planned -- between 11/20 and the rest.  That's what the existence of the "Z" error code in the assembler implies.  (I think that pops up if you do one of those R0,(R0)+ instructions or cases like that, where the whole thread started.)  And the change of RTI along with the introduction of RTT is clearly an intentional change for optimization.

There are lots of them. The deletion of the low bit in the PDR register 
in the J11 compared to the 11/70 (actually, it might only be the KB11 
that implement that bit), for example. Or the addition of the CSM 
instruction. Cache bypass is another one...
Clearly all of these were for things that were deemed not needed/used, 
or things that was deemed very useful to add...

Not to mention the whole EAE, EIS, FIS, FPP, CIS story. :-)

But I also seem to remember that a couple of differences between the 
11/20 and all the others were basically because the 11/20 is the only 
implementation not microcoded, so some behavior was just accidental 
because of the way the implementation works, and once they started doing 
other implementations, where they microcoded, they figured they should 
think about what was actually reasonable expectations on how things 
should work.

The R0,(R0)+ thing is way more convoluted than just an 11/20 vs. 
everything else kind of thing, though. Almost dividing the family in 
half... But yes, MACRO-11 tries to spot a few use cases where the 
outcome is undefined/implementation specific, and flags those with Z.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


More information about the Simh mailing list