[Simh] SIMH test suite / target CPU speed control

[Armistead, Jason]

While discussing SIMH futures, Vince Mulhollon wrote:

> I use a bash script that automates:
>
> wget's some relevant papertape or whatever of diagnostic routine
>
> runs a short expect script on simh pdp8 or whatever that executes the
> diagnostic routine and saves the disk images etc.
>
> md5sum the resulting output, and compare to the "golden" correct
> answer.

One potential problem would be accounting for any variation in the execution behavior, e.g. if the time-of-day clock was read from the host or if network interactions occur (assuming networking is enabled).  That would prevent you from getting repeatable modification dates on the SIMH target's disk file systems, and also the content of log files e..g  the OpenVMS OPERATOR.LOG.  So, the resultant disk images would differ in non-trivial ways.  Even if you could seed the time-of-day clock before running your SIMH test suite, any other process running on your host OS (and these days, there are many), would cause jitter in the elapsed execution time, again affecting timestamps. Even under DOS, I once observed a Toshiba Tecra laptop (Pentium 233) which had about a 10% variation in the number of simple increment operations it could do between the 55msec BIOS timer ticks - my conclusion was that the effects of all the background hardware ISRs implemented on a modern PC in the BIOS are non-trivial, e.g. battery management, network, USB, and who knows what else, even under good old DOS.

> For over a decade I've dreamed of a simh with 
> real time execution, so it runs and I/O operates at "real time" speeds,
> or perhaps a configurable multiple thereof.  I've always believed the
> current idle loop detection system is an architectural and scalability 
> dead end, the solution to a PDP-8 running at 100 times real speed and 
> hogging the host CPU 100% is to force the PDP-8 to run at "configurable 
> real speed" and ignore that its hogging a whopping 1% of the host CPU 
> in the idle loop.

The last time I looked, the arcade machine emulator MAME achieves this using the x86 Performance Counter functionality, and by knowing the clock cycle cost of each machine language instruction.  It then lets the emulated CPU run for some number of expected cycles, then idles itself until it's ready to do another chunk of instructions.  For example, if you can do 100msec worth of emulated instructions in 1msec on your shiny new multi-GHz CPU-equipped PC, you simply idle for 99msec.  To the observing user, if the time quanta is set right, it's not observable that it's not truly realtime.  For MAME, I think this is normally synchronized to the video refresh rate since that's what someone playing an arcade game is observing.

One of the challenges is retrofitting machine cycle counting into SIMH.  Some of those complex VAX instructions like the CRC instruction could take a variable amount of time to complete.  If you truly want to be cycle-accurate, you need to know all the gory implementation details.  If you wanted a "near enough is good enough" approximation and had an instruction which took between, say, 6 and 10 cycles to execute, you might split the difference and say that 8 cycles is an OK average.

Jason