[Simh] single cycle stepping for pdp11
Johnny Billquist
bqt at softjar.se
Fri Sep 6 08:46:00 EDT 2013
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 <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>
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
More information about the Simh
mailing list