On 2013-09-06 13:28, Timothe Litt wrote:
On 06-Sep-13 05:25, Johnny Billquist wrote:
[snip]
do you have any examples of what you mean when you say "different models
do different amounts of work in a single cycle"?
This generally applies to CPU implementations - how wide the ALU is, how
many functional units allow parallel/pipelined execution, whether
shifting is done by a barrel shifter vs. multiple single-bit shifts, how
may quotient bits a divide produces per cycle, etc.
However, one can stretch the definition to include cache effects, as
noted below.
Right. And that is not reflected in simh.
[snip]
11/34: 3 memory cycles
11/44: 2 memory cycles
11/60: 2 memory cycles
11/70: 2 memory cycles
[snip]
These stats are slightly deceptive, but illustrate another aspect that
SimH doesn't (and shouldn't) emulate.
MOV (R0)+, (R1)+
architecturally has three memory accesses (1):
instruction fetch
read source operand
write destination operand
The only way to use only 2 memory cycles is if the instruction fetch is
accounted for separately. One reason to do this is when the machine
has an instruction cache. Some machines had one, others didn't. So the
table entries are making different statements about timing.
The number of cycles above is the *total*. Read the handbook.
It's actually the destination processing that takes no memory cycles
(well, on the 11/34 it does take that cycle). I don't know exactly how
they pull that one off, but it's very clear from the book that is really
is that step which doesn't cost anything on some of the architectures.
If it is caching, or if it done in parallel with the source read, with
the next fetch, or whatnot, I don't know.
My guess is that the CPU actually manage to squeeze it in with the
source read phase.
Of course, the operand read/write may also be cached - and thus not
appear (or depending on the hardware, not be completed) on the external
bus. [Write-thru caches will expose writes; write-back caches only show
evictions; reads may hit or miss in the cache - and may never see the
bus, or unconditionally issue on the bus, only to be aborted on hit.]
The PDP-11s that have cache all use a write through cache.
The auto-increments normally run in parallel with the memory operations,
but a naive implementation could consume CPU clocks. In the event of a
NXM or memory fault, they are rolled-back - which may, or may not
consume time.
They are not rolled back on a PDP-11. The changes are recorded in a
separate register, so that the OS can perform the rollback, if needed.
Further, the meaning of a memory cycle depends on the
microarchitecture. Even some early PDP-11s had memory buses separate
from the UNIBUS. A memory (but not I/O space) cycle on the internal
buses can be absorbed into a write buffer and/or cache, or expanded into
multiple cycles (where the internal bus is wider than the external bus).
The only 11s with truly separate memory bus is the 11/70. You can argue
that the 11/8x also have separate memory bus, since they use PMI for
memory. And of course, the 11/9x have all the memory on the CPU board...
Also, the 11/45/50/55 could have a separate Unibus for memory. You could
say that this would be a memory bus.
But yes, memory cycles are also somewhat ambiguous. My whole point was
that single stepping on the cycle level would not be universally the
same on all PDP-11s, so doing it in simh would mean you'd have to do
different stuff depending on specific model.
SimH is designed to preserve the ability to run software, not to
simulate microarchitecture, much less hardware. To that end, it
maintains just enough state to allow software to see the visible aspects
of the real machine. Where the low-level implementation details are
exposed to software, they must be (and are) simulated. Otherwise, SimH
uses whatever abstractions (a) are accurate enough for software (b) are
convenient/maintainable (c) perform reasonably. In that order. Highest
performance isn't a goal of SimH.
Right. Which I think makes sense.
You shouldn't expect SimH to provide cycle (or memory
reference)-accurate timing. Or, if it happens to do so now, don't
expect it to continue to do so in any particular case. Features that
depend on these generally aren't visible to software, and so aren't
emulated in SimH. And the internal implementations have been known to
change.
Agree.
As for debugging - some machines implement address and/or data break,
which are useful for debugging software and/or hardware. And as Mark
noted, the PC history is also helpful. But often the easiest way to
debug hardware emulations is to put debug and/or trace code in the
emulation. SimH has a lot (arguably, too much - that could be
conditionally compiled) of this code, which provides detailed timing.
External lights are best updated by sampling. Switches can take
advantage of deposit from the remote console.
The bottom line is that if you need memory-cycle accuracy (and software
doesn't), SimH isn't the right choice.
Agree.
Johnny
---
(1) Assuming that R0 and R1 don't point to the same address. In that
case, hardware could merge the read and write into a read-modify-write,
or optimize it to a NXM/protection check. RMW probably counts as 1.5
memory cycles; NXM timing depends on the bus and a protection check is
usually cheaper than a memory cycle. In any case, I don't know of any
machine that bothered to check for this for MOV -- it might make more
sense for an opcode that modified data (e.g. ADD).
This communication may not represent my employer's views,
if any, on the matters discussed.
On 06-Sep-13 05:25, Johnny Billquist wrote:
On 2013-09-06 02:11, Doug Snyder wrote:
do you have any examples of what you mean when you say "different models
do different amounts of work in a single cycle"?
Look at
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/handbooks/PDP11_Handbook1979.pdf,
appendix B.
Example:
MOV (R0)+,(R1)+
11/34: 3 memory cycles
11/44: 2 memory cycles
11/60: 2 memory cycles
11/70: 2 memory cycles
I think most other smaller/slower machines all use 3 memory cycles,
but I would suspect things like the J11 to also only use two memory
cycles.
Johnny
On Thu, Sep 5, 2013 at 3:02 AM, Johnny Billquist <[email protected]
<mailto:[email protected]>> wrote:
On 2013-09-05 07:15, Mark Pizzolato - Info Comm wrote:
On Wednesday, September 04, 2013 at 10:08 PM, Doug Snyder wrote:
it appears that simh supports single instruction stepping,
but not single cycle stepping for the pdp11.
>
if this is the case, have there been attempts or requests to
add single cycle support?
Hi Doug,
The core behaviors of the simh simulators are built around the
execution of instructions. This is the level which things are
simulated at.
What problem are you trying to solve or deal with your request
to be concerned about clock cycles?
And even further - single cycle stepping will mean different things
on different models of the PDP-11. Or rather, different models do
different amounts of work in a single cycle.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] <mailto:[email protected]> ||
Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_________________________________________________
Simh mailing list
[email protected] <mailto:[email protected]>
http://mailman.trailing-edge.__com/mailman/listinfo/simh
<http://mailman.trailing-edge.com/mailman/listinfo/simh>
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
