21 Feb
2018
21 Feb
'18
6:56 a.m.
-----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!]
stated:
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 >> 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.
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
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. 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