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

[Dave Wade]

> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Paul
> Koning via cctalk
> Sent: 21 February 2018 14:41
> To: Sean Conner <spc at conman.org>; General Discussion: On-Topic and Off-
> Topic Posts <cctalk at classiccmp.org>
> Subject: Re: Writing emulators [Was: Re: VCF PNW 2018: Pictures!]
> 
> 
> 
> > 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.
> 

For early machines like the Manchester baby AKA the SSEM and the Ferranti
Pegasus its almost essential.
Many of programs for these early machines rely on cycle times to produce
predictable delays.
So the SSEM noodle timer only works because the machine runs at 110Khz..

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

Davd