Re: Bug-for-bug compatibility [was RE: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]]

[allison via cctalk]

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!]]]

[Maciej W. Rozycki via cctalk]

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!]]]

[Rich Alderson via cctalk]

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!]]]

[Chuck Guzis via cctalk]

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!]]]

[Paul Koning via cctalk]

> 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!]]]

[David Bridgham via cctalk]

> 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!]]]

[Doug Ingraham via cctalk]

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!]]]

[Rich Alderson via cctalk]

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/

Writing emulators (Was: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Fred Cisin via cctalk]

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.


On Mon, 26 Feb 2018, Paul Koning via cctalk wrote:
That's true.  But it is unfortunately also true that creating a bug for 
bug accurate model of an existing machine is extremely hard.


There is always a decision to be made, whether to mimic the behavior, or 
mimic how it is supposed to behave.  If you are aware of a bug in the 
original, do you emulate that bug?There was once a New Yorker cartoon, 
where a mechanic told a customer, "For $300 we can get it to run like new. 
For $600 we can get it to run like it should."


Emulation of the bugs can not simply be ignored.
Surely, you could get away with not emulating the truncated mantissa FDIV 
bug?  Not necessarily.


Sometimes timing can be important.  Using a do-nothing loop for a time 
delay was never a good idea (and optimizers would remove it), but it did 
happen, ranging from crude amateur programs, to crude copy protection.


I remember when it was sometimes necessary for MS-DOS code to determine 
what processor it was running on.  Since not all processors provided an 
"Identify yourself" command, it was done through checking for bugs, 
obscure differences, etc.  Such as checking the size of the pre-fetch 
buffer, or whether a double prefix was maintained after an interrupt (REP 
ES:MOVSW).  There was no offical method for identification.  I remember 
an article in Microcornucopia that mentioned an Intel sanctioned 
set of methods; the author couldn't remember where he got it; I called 
Intel, and after many transfers reached somebody who understood the 
question; he had no idea, but asked me to forward him a copy if I did 
ever find it.



So, it becomes necessary to have massive configuration settings, to be 
able to emulate as spec'ed, or as which set of the variant bugs.


It's hard enough just getting it to work!
When the first software based PC emulator for the Amiga came out, it 
worked [well enough to run XenoCopy on some formats].  But, people 
griped because it wasn't faster than their current PC.
Geez!  They got an elephant to fly, and people gripe about the speed and 
payload capacity!



--
Grumpy Ol' Fred ci...@xenosoft.com

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Glen Slick via cctalk]

On Mon, Feb 26, 2018 at 12:19 PM, Paul Koning via cctalk
 wrote:
>
> Another example is the work pdp2011 had to do in order to make RSTS boot on 
> that FPGA based PDP-11 emulation, because RSTS was doing some CPU-specific 
> hackery to test for an obscure CPU (or FPU?) bug that had been corrected in 
> some ECO that it wanted to require.  The only way to figure out how to do 
> that is to reverse engineer that particular bit of code, which isn't normally 
> available in source form.
>

I have one M8190 KDJ11-B that caused an RSTS/E 10.1 installation
failure. I forget what the error message was. Looking at an
installation tape message maybe it was one of these strings.
Unfortunately I could not contact field service to correct the
problem.

ECOs are missing from this FPJ11.
This DCJ11 cannot be used in conjunction with an FPJ11 accelerator.
Contact Field Service for FCO kit EQ-01440-02 to correct the problem.
The floating exception ECO is missing from this FPJ11.

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Paul Koning via cctalk]

> 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.  Building an 
OS-compatible version is not nearly as hard, but still hard enough.  Passing 
diagnostics is yet another hurdle; in some cases that isn't feasible without an 
entirely different design.  For example, in the CDC 6600 there is the "exchange 
jump" test, which at some point depends on the execution time of a divide 
instruction and the timing of exchange instructions.  It is very hard for an 
emulator to  mimic that (and an utter waste of effort for every other bit of 
software available for that machine).

Another example is the work pdp2011 had to do in order to make RSTS boot on 
that FPGA based PDP-11 emulation, because RSTS was doing some CPU-specific 
hackery to test for an obscure CPU (or FPU?) bug that had been corrected in 
some ECO that it wanted to require.  The only way to figure out how to do that 
is to reverse engineer that particular bit of code, which isn't normally 
available in source form.

paul

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Doug Ingraham via cctalk]

On Fri, Feb 23, 2018 at 2:49 PM, Rick Murphy via cctalk <
cctalk@classiccmp.org> wrote:

> On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote:
>
>> Ok, then it could be for VMS, which also does this (via Andy's
>> unsupported driver).  I don't know of PDP-11 or other minicomputer systems
>> that do DECtape overlapped seek.  I suppose it could be for artistic
>> verisimilitude...
>>
>
> TSS/8. It was a wonderful thing to witness. Start the drive spinning,
> deselect it, go start up another, then reselect the first one as it
> approached the right part of the tape.
> -Rick
>

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.

I've been slowly working on a PDP-8 emulator since the mid 1980's.  It was
able to run code a couple of days after I started working on it.  FOCAL in
about a week.  The Teletype emulation timing was added early on so a
program could not tell it was running on the emulator by timing the TTY
instructions.  About 10 years ago I added acceleration curves to the high
speed paper tape reader timing.  Within the last year I have added DF-32
support and am working towards fixing the timing so a program could not
be written to tell.  I need to add a randomness factor to the inter platter
timing.  At the moment it looks like all the drives are in optimum lockstep
which makes transfers run a little faster but isn't reality.  Probably add
a 50 hz option for those in 50 hz countries since the drive motors run
slower there and thus transfers were slower.

I have delayed adding DECTape support for years because of the difficulty
of doing this correctly.  You need to support so much stuff to do this
right from a timing standpoint.  At least on the TC01 controller you can
read in the reverse direction as well as the normal forward direction.  Do
you need to support reverse reads?  Almost no software took advantage of
this.  Every drive runs a little different and the emulator could (should)
reflect this.

If you can't have a real machine the least you can have is a correct as
possible emulator.  It is a lot easier to be lazy and think you are done
when the OS boots or an interpreter appears to run or it passes
diagnostics.  In reality you have barely begun.


-- 
Doug Ingraham
PDP-8 SN 1175

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Rick Murphy via cctalk]

On 2/21/2018 5:14 PM, Paul Koning via cctalk wrote:

Ok, then it could be for VMS, which also does this (via Andy's unsupported 
driver).  I don't know of PDP-11 or other minicomputer systems that do DECtape 
overlapped seek.  I suppose it could be for artistic verisimilitude...


TSS/8. It was a wonderful thing to witness. Start the drive spinning, 
deselect it, go start up another, then reselect the first one as it 
approached the right part of the tape.

    -Rick

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Lars Brinkhoff via cctalk]

Rich Alderson wrote:
> It's not for Tops-10.  SimH only provides the KS-10 processor[1], so
> DECtape is not a possible peripheral.
> [1] Although there is a KA-10 in the works.

Also KI-10 in its current state.  Maybe PDP-6 in the future.

Re: SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Paul Koning via cctalk]

> On Feb 21, 2018, at 3:25 PM, Rich Alderson via cctalk  
> wrote:
> 
> From: Paul Koning
> Sent: Wednesday, February 21, 2018 6:41 AM
> 
>> And while there is roughly-accurate simulation of DECtape in SIMH (presumably
>> for TOPS-10 overlapped seek to work?)
> 
> It's not for Tops-10.  SimH only provides the KS-10 processor[1], so DECtape 
> is
> not a possible peripheral.

Ok, then it could be for VMS, which also does this (via Andy's unsupported 
driver).  I don't know of PDP-11 or other minicomputer systems that do DECtape 
overlapped seek.  I suppose it could be for artistic verisimilitude...

paul

SimH DECtape vs. Tops-10 [was RE: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]]

[Rich Alderson via cctalk]

From: Paul Koning
Sent: Wednesday, February 21, 2018 6:41 AM

> And while there is roughly-accurate simulation of DECtape in SIMH (presumably
> for TOPS-10 overlapped seek to work?)

It's not for Tops-10.  SimH only provides the KS-10 processor[1], so DECtape is
not a possible peripheral.

Rich

[1] Although there is a KA-10 in the works.