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