On 06-Sep-13 05:25, Johnny Billquist wrote: [snip]
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.do you have any examples of what you mean when you say "different modelsdo different amounts of work in a single cycle"?
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 cycles11/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 operandThe 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 cyclesI 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.JohnnyOn 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>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
