Writing emulators [Was: Re: VCF PNW 2018: Pictures!]

[Paul Koning]

> On Feb 20, 2018, at 8:18 PM, Sean Conner via cctalk <cctalk at classiccmp.org> wrote:
> 
> It was thus said that the Great Eric Christopherson via cctalk once stated:
>> On Tue, Feb 20, 2018 at 5:30 PM, dwight via cctalk <cctalk at classiccmp.org>
>> wrote:
>> 
>>> In order to connect to the outside world, you need a way to queue event
>>> based on cycle counts, execution of particular address or particular
>>> instructions. This allows you to connect to the outside world. Other than
>>> that it is just looking up instructions in an instruction table.
>>> 
>>> Dwight
>>> 
>> 
>> What I've always wondered about was how the heck cycle-accurate emulation
>> is done. In the past I've always felt overwhelmed looking in the sources of
>> emulators like that to see how they do it, but maybe it's time I tried
>> again.
> 
>  It depends upon how cycle accurate you want.  My own MC6809 emulator [1]
> keeps track of cycles on a per-instruction basis, so it's easy to figure out
> how many cycles have passed.  

SIMH in principle allows the writing of cycle-accurate CPU simulators, but I don't believe anyone has bothered.  It's hard to see why that would be all that interesting.  For some CPUs, the full definition of how long instructions take is extremely complex.  Take a look at the instruction timing appendix in a PDP-11 processor handbook, for example; there are dozens of possibilities even for simple instructions like MOV, and things get more interesting still on machines that have caches.

Another consideration is that you don't get accurate system timing unless the whole system, not just the CPU emulation, is cycle-accurate.  And while there is roughly-accurate simulation of DECtape in SIMH (presumably for TOPS-10 overlapped seek to work?) in general it is somewhere between impractical and impossible to accurately model the timing of moving media storage devices.  You'd have to deal not just with seek timing but with the current sector position -- yes, I can imagine how in theory that would be done but it would be amazingly hard, and for what purpose?

If you have a machine with just trivial I/O devices like a serial port or a typewriter, then things get a bit more manageable.

SIMH certainly has event queueing to deal with I/O.  For correctly written operating systems that is extremely non-critical; if an I/O completes in a few cycles the OS doesn't care, it just has a fast I/O device.  Poorly written operating systems may have unstated dependencies on interrupts occurring "slow enough".  So a common practice is for the CPU emulation just to count instructions (not cycles or nanoseconds) and for the I/O events to be scheduled in terms of a nominal delay expressed in average instruction times.  I haven't yet run into trouble with that (but then again, I've been working with well-built operating systems).

	paul