[Simh] single cycle stepping for pdp11
Timothe Litt
litt at ieee.org
Fri Sep 6 07:28:19 EDT 2013
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.
[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.
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 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.
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).
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.
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.
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.
---
(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 <bqt at softjar.se
>> <mailto:bqt at softjar.se>> 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: bqt at softjar.se <mailto:bqt at softjar.se> ||
>> Reading murder books
>> pdp is alive! || tryin' to stay hip" - B. Idol
>> _________________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com <mailto:Simh at trailing-edge.com>
>> http://mailman.trailing-edge.__com/mailman/listinfo/simh
>> <http://mailman.trailing-edge.com/mailman/listinfo/simh>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20130906/d43802e8/attachment-0002.bin>
More information about the Simh
mailing list