> On Feb 20, 2018, at 8:18 PM, Sean Conner via cctalk <[email protected]>
> 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 <[email protected]>
>> 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
