Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
On 03/02/2018 06:44 AM, Maciej W. Rozycki via cctalk wrote: > On Wed, 28 Feb 2018, Paul Koning via cctalk wrote: > >> 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. Its right after the VAX that DEC engineering started thinking about standards. It was clear that the PDP-11 was not one fully unified system as each variant had its own unique quirks more so after the advent of the LSI-11 and F11 chips. Of of the PDP-11 handbooks I have has a back page of differences in instruction set behavior between all of the known PDP-11s including T-11 and J11, It was clear the VAX architecture had to have a clear definition that was true across all of VAXen yet to come. This was brought about by the need to keep VMS consistent and also later Ultrix. Hence the DEC STD For VAX came to being and the test for is it a VAX as well. Exceptions were clearly listed and the software impacts were defined. Of course since Alpha had to run VMS (by then OpenVMS) and Ultrix or its heirs it also was spec'ed out fully and for all expected generations. > That's what architecture verification programs or AVP tests are for > nowadays. Everything that's not undefined in the architecture is supposed > to work as defined. This includes odd corner cases. Formal definitions > are included in the architecture specification. Now we do in the world. But a good example of variations on a theme is ARM. Though there are some controls is an earlier ARM 16bit a subset of an ARM 64 bit? Allison > Maciej
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
On Wed, 28 Feb 2018, Paul Koning via cctalk wrote: > 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. That's what architecture verification programs or AVP tests are for nowadays. Everything that's not undefined in the architecture is supposed to work as defined. This includes odd corner cases. Formal definitions are included in the architecture specification. Maciej
RE: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
From: Doug Ingraham Sent: Wednesday, February 28, 2018 9:53 AM > This is a great story! And it probably indicates that when developing the > Toad-1 this particular diagnostic was never run from an original DEC generated > tape or the Toad-1 would have failed the diagnostic. Alternatively assembling > the diag on the restoration project would have yielded a working multiply. As it happens, this diagnostic is KI-10 specific, so no recompilation of the KL-10 diagnostics would have caught it. In addition, because the XKL-1 CPU was supposed to be identical to the KL-10, it needed to pass the diagnostics *as provided* for the KL-10. > So is someone going to fix the multiply instruction in the 20+ year old Toad? > Actually, they tried, but because they had stopped using the Toad-1 several years earlier (and donated all the remaining spare parts to the museum), they had no way to test in-house, and limited cycles for developing a fix. If we ever need to recompile diagnostics for the KI-10 (or, mirabile dictu, a KA-10!) we'll use a Toad-2. Rich
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
On 02/28/2018 10:55 AM, Paul Koning via cctalk wrote: > 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. In general, I've always taken the manuals as saying "if you do things the way we say they work, you'll be safe". Where the manual says one thing and the reality is otherwise, there's a cause for concern. The arithmetic right-shift with sign extension always made perfect sense to me on the 6600. It's not so simple if all you have is a logical right shift and want to do an arithmetic one. The instruction mnemonic reflects this (AX, vs. left shift LX). If you've got the arithmetic right shift and need a logical one with zero fill, add an MX to create a mask and then a BX to clear the extended bits. If you time your code, the penalty is only 2 cycles. I recall that we ran into trouble with trying to automatically take advantage of the CMU option on the lower (72,73) CYBER machines (the CYBER 74 didn't have the CMU option). Since the CMU instructions co-opted the no-op (46xxx) instruction, you could test for a CMU by putting a 30 bit CMU instruction (IM) with the second parcel also being 46000 and a jump in the second two. If there was no CMU, the first two parcels would be executed as no-ops and the jump would be taken. Otherwise, the CMU instruction would be executed and no jump would occur, as CMU instructions could only be placed in the first parcel of a word. Clever--and I recall that it was used in several libraries (the lower CYBER CMU DM instruction was faster than a CPU loop for block moves). Then the CYBER 170 came along and someone decided that CMU instructions attempted when there was no CMU should cause an "illegal instruction" exception. And then everything broke. There, the code was playing by the book. The reference manual shows the lower 9 bits of the 46 instruction as shaded out; i.e., ignored. (on the 6600, we found that they weren't exactly ignored--non-zero values could affect the timing). Later versions of the manual show the instruction encoding as 46000, but that was only after CPD began taking advantage of the CMU capabilities with the "trick". --Chuck
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
> On Feb 28, 2018, at 1:10 PM, David Bridgham via cctalk > 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 > right. 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. paul
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
> 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 right. Doing it mod 256 would be easier; I had to add an extra rotor to my barrel shifter to handle the -256 case to make the diagnostic pass.
Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
On Tue, Feb 27, 2018 at 2:46 PM, Rich Alderson via cctalk < cctalk@classiccmp.org> wrote: > > Fast forward 20 years, to Living Computer Museum, where a KI-10 based > DEC-1070 > was undergoing restoration. Diagnostics were needed, so the resident > TOPS-20 > programmer laid hands on the MAINDEC sources for the KI-10 and proceeded to > compile them all and generate paper tapes of the results. All went > smashingly > well until the multiplication test. > > The diagnostic source for this test uses a macro to build a set of test > values > for X**2 where X is a power of 2. Internally, Macro-20 uses the IMULM > instruction to build the results. In the KA-10 manual, IMULx of 2**35 * > 2**35 > is supposed to store the high order part of the result into the 36 bit word > addressed by the instruction, and set the overflow bit. > > On the Toad-1 (and on the Toad-2 prior to our discovery of this bug), a > zero is > stored instead. Since we compiled the KI-10 diagnostics on the Toad-1, > this > incorrect result was placed on the diagnostic paper tape, and the KI-10 > seemed > to fail the diagnostic. Imagine our chagrin when days of trying to > correct the > problem led to the conclusion that the diagnostic was incorrect. > > Rich > This is a great story! And it probably indicates that when developing the Toad-1 this particular diagnostic was never run from an original DEC generated tape or the Toad-1 would have failed the diagnostic. Alternatively assembling the diag on the restoration project would have yielded a working multiply. So is someone going to fix the multiply instruction in the 20+ year old Toad? -- Doug Ingraham PDP-8 SN 1175
Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]
From: Paul Koning Sent: Monday, February 26, 2018 12:19 PM >> On Feb 26, 2018, at 12:06 PM, Doug Ingraham via cctalk >> > wrote: >> The purpose of an emulator is to accurately pretend to be the original >> hardware. It doesn't matter that the original OS runs on a particular >> emulator. If a program can be written that runs on the original hardware >> but fails on the emulator then there is a flaw in that emulator. > That's true. But it is unfortunately also true that creating a bug for bug > accurate model of an existing machine is extremely hard. This is true even in real hardware (or "real" hardware, if you prefer), whether bug-for-bug or simply correct results for corner cases. The XKL Toad-1 System was designed to be a superset clone of the KL-10 based DECSYSTEM-2065 from Digital Equipment Corporation. It implements the full 30-bit extended addressing introduced with TOPS-20 v4, of which the KL-10 provided a 23-bit subset, and provides native support for 10Mbit Ethernet and FASTWIDE differential SCSI2 (both state of the art in 1991 when the design was frozen). As a better DEC-20, the Toad-1 was a success. (We will leave aside the issue of its market failure, which is irrelevant to the story.) Fast forward 20 years, to Living Computer Museum, where a KI-10 based DEC-1070 was undergoing restoration. Diagnostics were needed, so the resident TOPS-20 programmer laid hands on the MAINDEC sources for the KI-10 and proceeded to compile them all and generate paper tapes of the results. All went smashingly well until the multiplication test. The diagnostic source for this test uses a macro to build a set of test values for X**2 where X is a power of 2. Internally, Macro-20 uses the IMULM instruction to build the results. In the KA-10 manual, IMULx of 2**35 * 2**35 is supposed to store the high order part of the result into the 36 bit word addressed by the instruction, and set the overflow bit. On the Toad-1 (and on the Toad-2 prior to our discovery of this bug), a zero is stored instead. Since we compiled the KI-10 diagnostics on the Toad-1, this incorrect result was placed on the diagnostic paper tape, and the KI-10 seemed to fail the diagnostic. Imagine our chagrin when days of trying to correct the problem led to the conclusion that the diagnostic was incorrect. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computers: Museum + Labs 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputers.org http://www.LivingComputers.org/