From sigma.research at gmail.com Wed Sep 4 16:14:46 2013 From: sigma.research at gmail.com (William Gallant) Date: Wed, 4 Sep 2013 16:14:46 -0400 Subject: [Simh] Looking for IBM System801 materials Message-ID: I'm looking for IBM System801 documentation and software yet to surface. I've noticed three documents on bitsavers - http://bitsavers.trailing-edge.com/pdf/ibm/system801/ Anyone have anything? I would like to build an emulator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:08:20 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:08:20 -0700 Subject: [Simh] single cycle stepping for pdp11 Message-ID: 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? thanks, doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 01:15:04 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 22:15:04 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> 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? - Mark From dsnyder at blueshiftinc.com Thu Sep 5 01:32:29 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:32:29 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < Mark at infocomm.com> 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? > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 01:38:13 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 22:38:13 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:41:45 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:41:45 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: for pdp11s, single cycle stepping refers to single bus cycle stepping, not single clock cycle stepping. for instructions that make several memory access, the processor can be stopped at each memory access in order to examine the address and data for each memory access. this can be very useful for low-level software or hardware debugging. doug On Wed, Sep 4, 2013 at 10:32 PM, Doug Snyder wrote: > many (if not all) of the pdp11 models support single cycle stepping. to > more accurately model an actual pdp11, it would be nice if simh could model > that feature. not being able to model that feature is certainly not the > end of the world, but it is a noticeable difference. > > doug > > > > On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < > Mark at infocomm.com> 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? >> >> - Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:46:21 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:46:21 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> Message-ID: it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm < Mark at infocomm.com> wrote: > OK, so the original hardware supported single cycle stepping.**** > > ** ** > > What would expect to happen in the simulator if you stepped single > cycles? What details would you want to have access to after stepping at > the cycle level?**** > > ** ** > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Doug Snyder > *Sent:* Wednesday, September 04, 2013 10:32 PM > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com > *Subject:* Re: [Simh] single cycle stepping for pdp11**** > > ** ** > > many (if not all) of the pdp11 models support single cycle stepping. to > more accurately model an actual pdp11, it would be nice if simh could model > that feature. not being able to model that feature is certainly not the > end of the world, but it is a noticeable difference.**** > > ** ** > > doug**** > > ** ** > > ** ** > > On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < > Mark at infocomm.com> 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? > > - Mark**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 02:12:06 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 23:12:06 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670C@REDROOF2.alohasunset.com> Simh doesn't expose any abstraction of the internal details at the level you are mentioning. Emulation at that level for each processor and/or device was never a direct goal. However, there certainly are some parallels to how the original hardware behaved internally which you are welcome to explore using a debugger on the simulator itself. You can set breakpoints at the components which reference memory and/or within the code which implements the device interface which the operating system expects to see. In theory, you could add code to the memory reference code path to update a blinken light display, but this would horribly impact simulator performance, and you still wouldn't have a stepping ability at the bus cycle level. In theory, you could restructure the PDP11 simulator to execute bus cycles instead of instructions. I think this would be a very significant amount of work, and would then still run much slower even if no blinken light display was being driven. On the other hand, if you're not really trying to drive a blinken light display, you can get a lot of detailed information from the pdp11 simulator using the instruction history capability: sim> set cpu history=100 sim> set bre sim> set bre 14302 sim> b rq0 Breakpoint, PC: 014302 (JMP 14064) sim> show cpu hist PC PSW src dst IR 032142 030001| 000001 DEC R0 032144 030005|032144 140010 MOV #0,R2 032150 030001|024600 000001 MOV R5,R1 032152 030001|032152 024600 ADD #0,R1 032156 030000|000000 000040 CMP R0,R2 032160 030011| BCS 32214 032214 030011| 000040 ASR R2 032216 030000|000000 000020 CMP R0,R2 032220 030011| BCS 32234 032234 030011| 000000 ASL R0 [..etc..] - Mark From: Doug Snyder [mailto:dsnyder at blueshiftinc.com] Sent: Wednesday, September 04, 2013 10:46 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm > wrote: OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark From: Doug Snyder [mailto:dsnyder at blueshiftinc.com] Sent: Wednesday, September 04, 2013 10:46 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm > wrote: OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Thu Sep 5 06:02:04 2013 From: bqt at softjar.se (Johnny Billquist) Date: Thu, 05 Sep 2013 12:02:04 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: <5228569C.3060307@softjar.se> 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 || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dsnyder at blueshiftinc.com Thu Sep 5 20:11:56 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Thu, 5 Sep 2013 17:11:56 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5228569C.3060307@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> Message-ID: do you have any examples of what you mean when you say "different models do different amounts of work in a single cycle"? On Thu, Sep 5, 2013 at 3:02 AM, Johnny Billquist 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 || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > ______________________________**_________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.**com/mailman/listinfo/simh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Fri Sep 6 05:25:27 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 11:25:27 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> Message-ID: <52299F87.1030207@softjar.se> 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 > 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 || > Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > _________________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.__com/mailman/listinfo/simh > > > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From litt at ieee.org Fri Sep 6 07:28:19 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 06 Sep 2013 07:28:19 -0400 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <52299F87.1030207@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> Message-ID: <5229BC53.4080600@ieee.org> 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 > > 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 || >> Reading murder books >> pdp is alive! || tryin' to stay hip" - B. Idol >> _________________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> 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: From bqt at softjar.se Fri Sep 6 08:46:00 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 14:46:00 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229BC53.4080600@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> Message-ID: <5229CE88.2010108@softjar.se> 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 >> > 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 || >>> Reading murder books >>> pdp is alive! || tryin' to stay hip" - B. Idol >>> _________________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.__com/mailman/listinfo/simh >>> >>> >>> >> >> > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Fri Sep 6 10:32:50 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 06 Sep 2013 10:32:50 -0400 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229CE88.2010108@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> Message-ID: <5229E792.7090308@ieee.org> > The number of cycles above is the *total*. Read the handbook. Not really. You're confusing observed timing with which cycles happen. This is all a matter of how you account for the cycles. The instruction must be fetched. The source must be read. And the destination must be written. These all cause some sort of cycle - whether or not it appears on the external bus. The handbook is talking not about how many cycles happen, but about the effect on instruction timing. That is, accounting for their effect on observed timing. The context of the OP's question was an assumption about which cycles *happen*, not their timing. He wanted to observe/single step them, not measure how long instructions take. I chose to reply mostly in the PDP-11 context, but intentionally included some general information since this question has come up with other architectures as well. From a timing point of view, the fetch can be hidden by an i-cache, by prefetch that overlaps execution, and other tricks. The source can come from cache, from a bypassed result of a previous instruction in the pipeline, or from memory. The destination can go to memory, a write buffer, or a cache. And it can be bypassed direct to the ALU. This all has an impact on timing. And depending on precisely how you define your observation point, which cycles happen. Inside a CPU, most of them happen - except for bypassed operands. Past that point, things get wild depending on cache/write buffer effectiveness. Architecturally, all three cycles always happen sequentially. In a given instance on a given implementation, which ones appear on any particular bus and the resulting instruction timing may vary greatly. [Bypass: A machine may send a write to memory, but notice that a subsequent instruction needs the value before the value arrives in memory. In this case, the value can be sent to the execution unit before it reaches memory - completely or partially bypassing the memory/cache unit, and eliminating a memory cycle. Depending on the exact timing/microarchitecture, the value can come directly from the ALU, from pipeline stages in the CPU, from pipe stages in the memory unit, from a write queue, write buffer or cache.] > 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. You can't do this. A write requires the source operand; you can't start it until you you have the source data. (A clever machine can overlap the access checks, and maybe the address phase of an a/d external bus if the source read doesn't require the bus. But the 11s were not that smart.) You *can* disconnect the write from the next fetch with a write buffer (as I noted), but that doesn't eliminate the write, it just delays it until the write buffer is evicted. All of this amounts to accounting and buffering tricks. With buffers (and I include caches in this), you eliminate some bus cycles. But eventually things get evicted. So the bus cycle happens later - and is charged to something else. Maybe a subsequent instruction. Maybe averaged into memory overhead. With luck, there are multiple references to the the same address, and there is a reduction in external bus cycles due to coalescing. Statistically, that works. Worst case, they all happen. In any case, the details are only of interest to hardware types - they don't and never will enter SimH. > They are not rolled back on a PDP-11. Not in hardware. As you noted, the OS has to do it, which is even slower. However, the resulting memory/register fetches create bus traffic, which the OP would like to see. > Also, the 11/45/50/55 could have a separate Unibus for memory. You > could say that this would be a memory bus. Yes, I was thinking of those machines - the 11/45 counts as 'early'. > 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. We are in violent agreement on the first point. On the second, I go further: the effort would be inconsistent with SimH's goals and design. It should not be attempted. > The PDP-11s that have cache all use a write through cache. Yes. The KL10 was the first DEC machine to have a write-back cache. And it has some novel aspects for software. ['aspect' DEC jargon file: something that *just is*, v.s. a *feature* or a *bug*] This communication may not represent my employer's views, if any, on the matters discussed. On 06-Sep-13 08:46, Johnny Billquist wrote: > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From bqt at softjar.se Fri Sep 6 11:01:45 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:01:45 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229E792.7090308@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> Message-ID: <5229EE59.7080007@softjar.se> On 2013-09-06 16:32, Timothe Litt wrote: >> The number of cycles above is the *total*. Read the handbook. > Not really. You're confusing observed timing with which cycles happen. > > This is all a matter of how you account for the cycles. The instruction > must be fetched. The source must be read. And the destination must be > written. These all cause some sort of cycle - whether or not it appears > on the external bus. The handbook is talking not about how many cycles > happen, but about the effect on instruction timing. That is, accounting > for their effect on observed timing. Did you even read the book? They list both execution times, and memory cycles. Yes, the chapter is about execution times. That does not change that the number of memory cycles used is also shown, and that MOV (R0)+,(R1)+, as an example, is only two memory cycles total. And that includes instruction fetch and execution, source processing and destination processing. Johnny > > The context of the OP's question was an assumption about which cycles > *happen*, not their timing. He wanted to observe/single step them, not > measure how long instructions take. I chose to reply mostly in the > PDP-11 context, but intentionally included some general information > since this question has come up with other architectures as well. > > From a timing point of view, the fetch can be hidden by an i-cache, by > prefetch that overlaps execution, and other tricks. The source can come > from cache, from a bypassed result of a previous instruction in the > pipeline, or from memory. The destination can go to memory, a write > buffer, or a cache. And it can be bypassed direct to the ALU. > > This all has an impact on timing. And depending on precisely how you > define your observation point, which cycles happen. Inside a CPU, most > of them happen - except for bypassed operands. Past that point, things > get wild depending on cache/write buffer effectiveness. > > Architecturally, all three cycles always happen sequentially. In a > given instance on a given implementation, which ones appear on any > particular bus and the resulting instruction timing may vary greatly. > > [Bypass: A machine may send a write to memory, but notice that a > subsequent instruction needs the value before the value arrives in > memory. In this case, the value can be sent to the execution unit > before it reaches memory - completely or partially bypassing the > memory/cache unit, and eliminating a memory cycle. Depending on the > exact timing/microarchitecture, the value can come directly from the > ALU, from pipeline stages in the CPU, from pipe stages in the memory > unit, from a write queue, write buffer or cache.] > >> 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. > You can't do this. A write requires the source operand; you can't start > it until you you have the source data. (A clever machine can overlap > the access checks, and maybe the address phase of an a/d external bus if > the source read doesn't require the bus. But the 11s were not that smart.) > > You *can* disconnect the write from the next fetch with a write buffer > (as I noted), but that doesn't eliminate the write, it just delays it > until the write buffer is evicted. > > All of this amounts to accounting and buffering tricks. With buffers > (and I include caches in this), you eliminate some bus cycles. But > eventually things get evicted. So the bus cycle happens later - and is > charged to something else. Maybe a subsequent instruction. Maybe > averaged into memory overhead. With luck, there are multiple references > to the the same address, and there is a reduction in external bus cycles > due to coalescing. Statistically, that works. Worst case, they all happen. > > In any case, the details are only of interest to hardware types - they > don't and never will enter SimH. > >> They are not rolled back on a PDP-11. > Not in hardware. As you noted, the OS has to do it, which is even slower. > > However, the resulting memory/register fetches create bus traffic, which > the OP would like to see. >> Also, the 11/45/50/55 could have a separate Unibus for memory. You >> could say that this would be a memory bus. > Yes, I was thinking of those machines - the 11/45 counts as 'early'. >> 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. > We are in violent agreement on the first point. On the second, I go > further: the effort would be inconsistent with SimH's goals and design. > It should not be attempted. >> The PDP-11s that have cache all use a write through cache. > Yes. The KL10 was the first DEC machine to have a write-back cache. > And it has some novel aspects for software. > > ['aspect' DEC jargon file: something that *just is*, v.s. a *feature* or > a *bug*] > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 06-Sep-13 08:46, Johnny Billquist wrote: >> 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. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > From aek at bitsavers.org Fri Sep 6 11:07:33 2013 From: aek at bitsavers.org (Al Kossow) Date: Fri, 06 Sep 2013 08:07:33 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229E792.7090308@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> Message-ID: <5229EFB5.4070202@bitsavers.org> On 9/6/13 7:32 AM, Timothe Litt wrote: > This is all a matter of how you account for the cycles. The instruction must be fetched. The source must be read. And the destination must be written. These all cause some sort of cycle - whether > or not it appears on the external bus. Non-processor requests will also effect how often you can get out the Unibus. I remember the VT11 being a particularly bad bus hog. Massbus disks and I would think comms processors would be a problem too. I would imagine this would be a huge win for even the smallest caches to try keeping the CPU off of the Unibus. From bob at supnik.org Fri Sep 6 11:13:07 2013 From: bob at supnik.org (Bob Supnik) Date: Fri, 06 Sep 2013 11:13:07 -0400 Subject: [Simh] Various PDP11 fixes and enhancements Message-ID: <5229F103.605@supnik.org> 1. RK611 bug - RK07 not recognized on RSTS/E. Fixed. New version smoke-tested with VMS, M+, RSTS/E, and RT. 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. Only tested with RT11, as M+ and RSTS/E support requires a unique SYSGENs. Feel free to hack on it. 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that it should not track changes in floating point instructions is still open. As usual, look for recent checkins in the GitHub repository, or new files in the interim corrections directory on the SimH web site (http://simh.trailing-edge.com/interim). /Bob From bqt at softjar.se Fri Sep 6 11:33:20 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:33:20 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229EFB5.4070202@bitsavers.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> <5229EFB5.4070202@bitsavers.org> Message-ID: <5229F5C0.4050201@softjar.se> On 2013-09-06 17:07, Al Kossow wrote: > On 9/6/13 7:32 AM, Timothe Litt wrote: > >> This is all a matter of how you account for the cycles. The >> instruction must be fetched. The source must be read. And the >> destination must be written. These all cause some sort of cycle - >> whether >> or not it appears on the external bus. > > Non-processor requests will also effect how often you can get out the > Unibus. > I remember the VT11 being a particularly bad bus hog. Massbus disks and > I would think comms processors would be a problem too. > I would imagine this would be a huge win for even the smallest caches to > try > keeping the CPU off of the Unibus. Indeed. And I just realized/remembered one more thing about the separate memory bus thingy. One could also argue that the memory on the 11/24 and 11/44 are on a separate memory bus, since these machines also have 22-bit addressing for memory, which cannot be done over the Unibus. However, they share parts of the signals with the Unibus, so for those machines, it does not really offload the bus in any way. Johnny From bqt at softjar.se Fri Sep 6 11:40:19 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:40:19 +0200 Subject: [Simh] Various PDP11 fixes and enhancements In-Reply-To: <5229F103.605@supnik.org> References: <5229F103.605@supnik.org> Message-ID: <5229F763.8090807@softjar.se> On 2013-09-06 17:13, Bob Supnik wrote: > 1. RK611 bug - RK07 not recognized on RSTS/E. Fixed. New version > smoke-tested with VMS, M+, RSTS/E, and RT. Nice! > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. > Only tested with RT11, as M+ and RSTS/E support requires a unique > SYSGENs. Feel free to hack on it. Is this something specific to a third massbus, or just a case of the RS03/RS04 devices as such? I mean, on M+ you can have all type of devices on the same massbus. > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that > it should not track changes in floating point instructions is still open. I wasn't aware of any discussions. Could you, or someone sum it up? Is it a question of whether MMR1 should reflect changes to the general registers if a FP instruction is aborted? If so, I'm pretty sure they should be. I think I have read it somewhere in some documentation, and could try and locate it, if that really is the question. Also, MMR1 might reflect changes to the PC as well, as far as I can read documentation... But it's "complicated". :-) Johnny > > As usual, look for recent checkins in the GitHub repository, or new > files in the interim corrections directory on the SimH web site > (http://simh.trailing-edge.com/interim). > > /Bob > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From elson at pico-systems.com Fri Sep 6 11:55:25 2013 From: elson at pico-systems.com (Jon Elson) Date: Fri, 06 Sep 2013 10:55:25 -0500 Subject: [Simh] Simh Digest, Vol 117, Issue 4 In-Reply-To: References: Message-ID: <5229FAED.5080907@pico-systems.com> > Date: Thu, 05 Sep 2013 12:02:04 +0200 > From: Johnny Billquist > To: simh at trailing-edge.com > Subject: Re: [Simh] single cycle stepping for pdp11 > Message-ID: <5228569C.3060307 at softjar.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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. >>> >> >> >> 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. > > I worked for years on PDP-11s, and never heard of this single cycle stepping. I can imagine there might be a jumper on one of the boards that enables this for customer engineer's debugging, but as far as I know you only got single complete instruction stepping with the halt switch. I worked with the 11/20, 11/34, 11/45 and even the CalData emulator. Jon From bqt at softjar.se Fri Sep 6 12:14:20 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 18:14:20 +0200 Subject: [Simh] Simh Digest, Vol 117, Issue 4 In-Reply-To: <5229FAED.5080907@pico-systems.com> References: <5229FAED.5080907@pico-systems.com> Message-ID: <5229FF5C.1070101@softjar.se> On 2013-09-06 17:55, Jon Elson wrote: > >> Date: Thu, 05 Sep 2013 12:02:04 +0200 >> From: Johnny Billquist >> To: simh at trailing-edge.com >> Subject: Re: [Simh] single cycle stepping for pdp11 >> Message-ID: <5228569C.3060307 at softjar.se> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> 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. >>> >>> 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. >> > I worked for years on PDP-11s, and never heard of this single cycle > stepping. > I can imagine there might be a jumper on one of the boards that enables > this > for customer engineer's debugging, but as far as I know you only got single > complete instruction stepping with the halt switch. I worked with the > 11/20, 11/34, 11/45 and even the CalData emulator. I would have expected the 11/45 to be similar to the 11/70 in this case. The 11/70 have one switch on the front panel labelled "S INST/S BUS CYCLE". If you are halted, and pull the CONT switch, with HALT enabled, it will single step. Either one instruction, or one bus cycle, depending on this switch. Johnny From djg at pdp8online.com Mon Sep 16 21:15:02 2013 From: djg at pdp8online.com (David Gesswein) Date: Mon, 16 Sep 2013 21:15:02 -0400 Subject: [Simh] PDP8 changes Message-ID: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> I'm not sure where simh development is discussed with the move to github. I submitted a couple of bug but I have some other changes I have made to my version and want to see if they are of interest. 1) Modify bin loader to read multiple section tapes. 2) Modify breakpoint command to add breakpoint on instruction value. 3) Raw socket for teletype console instead of telnet wrapped. From bob at supnik.org Mon Sep 16 21:59:12 2013 From: bob at supnik.org (Bob Supnik) Date: Mon, 16 Sep 2013 21:59:12 -0400 Subject: [Simh] Recent bug fixes Message-ID: <5237B770.6020104@supnik.org> Message: 5 Date: Fri, 06 Sep 2013 17:40:19 +0200 From: Johnny Billquist To:simh at trailing-edge.com Subject: Re: [Simh] Various PDP11 fixes and enhancements Message-ID:<5229F763.8090807 at softjar.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2013-09-06 17:13, Bob Supnik wrote: > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. > Only tested with RT11, as M+ and RSTS/E support requires a unique > SYSGENs. Feel free to hack on it. Is this something specific to a third massbus, or just a case of the RS03/RS04 devices as such? I mean, on M+ you can have all type of devices on the same massbus. >>> The Massbus implementation links an RH to a single device type. >>> This is an artifact of the simulator, not of real life. >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units. > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that > it should not track changes in floating point instructions is still open. I wasn't aware of any discussions. Could you, or someone sum it up? Is it a question of whether MMR1 should reflect changes to the general registers if a FP instruction is aborted? If so, I'm pretty sure they should be. I think I have read it somewhere in some documentation, and could try and locate it, if that really is the question. Also, MMR1 might reflect changes to the PC as well, as far as I can read documentation... But it's "complicated". Johnny >>> Looking at the J-11 microcode: >>> MMR1 does not track FP changes. This is because in early systems, like >>> the 11/45, it didn't have enough bits to record an 8 byte register change. >>> The J-11 goes through great pains to undo register changes before it >>> springs a trap or memory management abort. >>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction >>> stream is read through a special microinstruction, because the hardware >>> always prefetches the next instruction word. Even modes 47 and 57, which >>> make no sense, don't update MMR1. /Bob Supnik From spedraja at gmail.com Tue Sep 17 02:49:26 2013 From: spedraja at gmail.com (SPC) Date: Tue, 17 Sep 2013 08:49:26 +0200 Subject: [Simh] PDP8 changes In-Reply-To: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> References: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> Message-ID: I think they are interesting. 1 and 3 in particular. SPc. 2013/9/17 David Gesswein > I'm not sure where simh development is discussed with the move to > github. I submitted a couple of bug but I have some other changes I > have made to my version and want to see if they are of interest. > > 1) Modify bin loader to read multiple section tapes. > 2) Modify breakpoint command to add breakpoint on instruction value. > 3) Raw socket for teletype console instead of telnet wrapped. > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Gracias | Regards Saludos - Greetings - Freundliche Gr??e - Salutations -- *Sergio Pedraja* twitter: @sergio_pedraja skype: Sergio Pedraja http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://www.quora.com/Sergio-Pedraja http://spedraja.wordpress.com https://www.xing.com/profile/Sergio_Pedraja http://www.viadeo.com http://www.avalonred.com/ ----- No crea todo lo que ve, ni crea que est? vi?ndolo todo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Tue Sep 17 09:09:17 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Tue, 17 Sep 2013 06:09:17 -0700 Subject: [Simh] PDP8 changes In-Reply-To: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> References: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C2462DE@REDROOF2.alohasunset.com> Hi David, On Monday, September 16, 2013 at 6:15 PM, David Gesswein wrote: > I'm not sure where simh development is discussed with the move to > github. I submitted a couple of bug but I have some other changes I have > made to my version and want to see if they are of interest. > > 1) Modify bin loader to read multiple section tapes. > 2) Modify breakpoint command to add breakpoint on instruction value. > 3) Raw socket for teletype console instead of telnet wrapped. Please create separate issues on the github issue system to discuss the details of each of these points. Anyone else can chime in to the discussion of any issue on that system as well. Thanks. - Mark From bob at supnik.org Wed Sep 18 12:49:29 2013 From: bob at supnik.org (Bob Supnik) Date: Wed, 18 Sep 2013 12:49:29 -0400 Subject: [Simh] OS/8 image with PIP10 AND TC08 Message-ID: <5239D999.4010005@supnik.org> In order to debug a problem with PIP10, I'm looking for a generated OS8 V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has one ready to go, please let me know. /Bob From bqt at softjar.se Wed Sep 18 13:41:58 2013 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 18 Sep 2013 19:41:58 +0200 Subject: [Simh] OS/8 image with PIP10 AND TC08 In-Reply-To: <5239D999.4010005@supnik.org> References: <5239D999.4010005@supnik.org> Message-ID: <5239E5E6.1090501@softjar.se> On 2013-09-18 18:49, Bob Supnik wrote: > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. Slightly sidesteping the issue. If you have a recent enough version of OS/8 and SET.SV, you can swap device drivers at runtime. PIP10 actually only looks at a signature for the driver in order to figure out if it is a TC08 or a TD8E. Once it has done this, PIP10 has its own code for both the TC08 and TD8E in the PIP10 image. Johnny From bqt at softjar.se Fri Sep 20 09:08:00 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 20 Sep 2013 15:08:00 +0200 Subject: [Simh] Recent bug fixes In-Reply-To: <5237B770.6020104@supnik.org> References: <5237B770.6020104@supnik.org> Message-ID: <523C48B0.5090203@softjar.se> On 2013-09-17 03:59, Bob Supnik wrote: > Message: 5 > Date: Fri, 06 Sep 2013 17:40:19 +0200 > From: Johnny Billquist > To:simh at trailing-edge.com > Subject: Re: [Simh] Various PDP11 fixes and enhancements > Message-ID:<5229F763.8090807 at softjar.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2013-09-06 17:13, Bob Supnik wrote: > >> 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. >> Only tested with RT11, as M+ and RSTS/E support requires a unique >> SYSGENs. Feel free to hack on it. > > Is this something specific to a third massbus, or just a case of the > RS03/RS04 devices as such? I mean, on M+ you can have all type of > devices on the same massbus. > >>>> The Massbus implementation links an RH to a single device type. >>>> This is an artifact of the simulator, not of real life. >>>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units. I see. So simh don't make any distinction between the RM and RP? The registers have a couple of differences between these as well, but if I remember right, they are only for error recovery, so they won't affect normal operation. But on an 11M system, I'm not sure you can even mix RM and RP on the same massbus. (I might be wrong on that one, though. I need to check.) >> 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that >> it should not track changes in floating point instructions is still open. > > I wasn't aware of any discussions. Could you, or someone sum it up? Is > it a question of whether MMR1 should reflect changes to the general > registers if a FP instruction is aborted? If so, I'm pretty sure they > should be. I think I have read it somewhere in some documentation, and > could try and locate it, if that really is the question. > > Also, MMR1 might reflect changes to the PC as well, as far as I can read > documentation... But it's "complicated". > > Johnny > >>>> Looking at the J-11 microcode: >>>> MMR1 does not track FP changes. This is because in early systems, like >>>> the 11/45, it didn't have enough bits to record an 8 byte register >>>> change. >>>> The J-11 goes through great pains to undo register changes before it >>>> springs a trap or memory management abort. >>>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction >>>> stream is read through a special microinstruction, because the hardware >>>> always prefetches the next instruction word. Even modes 47 and 57, >>>> which >>>> make no sense, don't update MMR1. Aha. So I was looking at the 11/70 processor handbook, which says that MMR1 would track changes to the PC on at least that CPU. But since change to the PC is not really important anyway I can see that either way would work just as fine. But I don't see the problem with an 8 byte change. MMR1 have 5 bits for telling the changed value. This is a signed value, so it should range from +15 to -16. What am I missing??? Johnny > > /Bob Supnik > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From simulator at swabhawat.com Mon Sep 23 10:55:15 2013 From: simulator at swabhawat.com (R. Voorhorst) Date: Mon, 23 Sep 2013 14:55:15 +0000 (UTC) Subject: [Simh] OS/8 image with PIP10 AND TC08 References: <5239D999.4010005@supnik.org> Message-ID: Bob Supnik writes: > > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. > > /Bob > If you need an OS8 image with drivers and so, I have some distribution media available with RK8E format with a config file on Windows. Please inform how you want to receive it. Best regards R. Voorhorst From simulator at swabhawat.com Wed Sep 25 14:53:48 2013 From: simulator at swabhawat.com (R. Voorhorst) Date: Wed, 25 Sep 2013 18:53:48 +0000 (UTC) Subject: [Simh] OS/8 image with PIP10 AND TC08 References: <5239D999.4010005@supnik.org> Message-ID: Bob Supnik writes: > > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. > > /Bob > Simh issue #43 Pip10/TD8,TC08 solved Best regards, R. Voorhorst From bob at supnik.org Mon Sep 30 15:52:29 2013 From: bob at supnik.org (Bob Supnik) Date: Mon, 30 Sep 2013 15:52:29 -0400 Subject: [Simh] PIP10 Message-ID: <5249D67D.9000308@supnik.org> R Voorhoost pointed out on the GitHUB mailing list that PIP10 is working correctly. The issues appear to have been cockpit errors. First, the DECtape must be attached with the -F switch, to create an 18b-formatted image. Second, the syntax for PIP10 is very finicky. For example, I was trying: *DTA0:/Z instead of *DTA0: I'm looking for IBM System801 documentation and software yet to surface. I've noticed three documents on bitsavers - http://bitsavers.trailing-edge.com/pdf/ibm/system801/ Anyone have anything? I would like to build an emulator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:08:20 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:08:20 -0700 Subject: [Simh] single cycle stepping for pdp11 Message-ID: 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? thanks, doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 01:15:04 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 22:15:04 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> 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? - Mark From dsnyder at blueshiftinc.com Thu Sep 5 01:32:29 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:32:29 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < Mark at infocomm.com> 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? > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 01:38:13 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 22:38:13 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:41:45 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:41:45 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: for pdp11s, single cycle stepping refers to single bus cycle stepping, not single clock cycle stepping. for instructions that make several memory access, the processor can be stopped at each memory access in order to examine the address and data for each memory access. this can be very useful for low-level software or hardware debugging. doug On Wed, Sep 4, 2013 at 10:32 PM, Doug Snyder wrote: > many (if not all) of the pdp11 models support single cycle stepping. to > more accurately model an actual pdp11, it would be nice if simh could model > that feature. not being able to model that feature is certainly not the > end of the world, but it is a noticeable difference. > > doug > > > > On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < > Mark at infocomm.com> 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? >> >> - Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsnyder at blueshiftinc.com Thu Sep 5 01:46:21 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Wed, 4 Sep 2013 22:46:21 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> Message-ID: it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm < Mark at infocomm.com> wrote: > OK, so the original hardware supported single cycle stepping.**** > > ** ** > > What would expect to happen in the simulator if you stepped single > cycles? What details would you want to have access to after stepping at > the cycle level?**** > > ** ** > > *From:* simh-bounces at trailing-edge.com [mailto: > simh-bounces at trailing-edge.com] *On Behalf Of *Doug Snyder > *Sent:* Wednesday, September 04, 2013 10:32 PM > *To:* Mark Pizzolato - Info Comm > *Cc:* simh at trailing-edge.com > *Subject:* Re: [Simh] single cycle stepping for pdp11**** > > ** ** > > many (if not all) of the pdp11 models support single cycle stepping. to > more accurately model an actual pdp11, it would be nice if simh could model > that feature. not being able to model that feature is certainly not the > end of the world, but it is a noticeable difference.**** > > ** ** > > doug**** > > ** ** > > ** ** > > On Wed, Sep 4, 2013 at 10:15 PM, Mark Pizzolato - Info Comm < > Mark at infocomm.com> 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? > > - Mark**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Thu Sep 5 02:12:06 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Wed, 4 Sep 2013 23:12:06 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670B@REDROOF2.alohasunset.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670C@REDROOF2.alohasunset.com> Simh doesn't expose any abstraction of the internal details at the level you are mentioning. Emulation at that level for each processor and/or device was never a direct goal. However, there certainly are some parallels to how the original hardware behaved internally which you are welcome to explore using a debugger on the simulator itself. You can set breakpoints at the components which reference memory and/or within the code which implements the device interface which the operating system expects to see. In theory, you could add code to the memory reference code path to update a blinken light display, but this would horribly impact simulator performance, and you still wouldn't have a stepping ability at the bus cycle level. In theory, you could restructure the PDP11 simulator to execute bus cycles instead of instructions. I think this would be a very significant amount of work, and would then still run much slower even if no blinken light display was being driven. On the other hand, if you're not really trying to drive a blinken light display, you can get a lot of detailed information from the pdp11 simulator using the instruction history capability: sim> set cpu history=100 sim> set bre sim> set bre 14302 sim> b rq0 Breakpoint, PC: 014302 (JMP 14064) sim> show cpu hist PC PSW src dst IR 032142 030001| 000001 DEC R0 032144 030005|032144 140010 MOV #0,R2 032150 030001|024600 000001 MOV R5,R1 032152 030001|032152 024600 ADD #0,R1 032156 030000|000000 000040 CMP R0,R2 032160 030011| BCS 32214 032214 030011| 000040 ASR R2 032216 030000|000000 000020 CMP R0,R2 032220 030011| BCS 32234 032234 030011| 000000 ASL R0 [..etc..] - Mark From: Doug Snyder [mailto:dsnyder at blueshiftinc.com] Sent: Wednesday, September 04, 2013 10:46 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm > wrote: OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark From: Doug Snyder [mailto:dsnyder at blueshiftinc.com] Sent: Wednesday, September 04, 2013 10:46 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 it would be nice to see the virtual address, physical address, instruction space/data space flag and data for each cycle a perfect result would be any data that would be visible and updated each bus cycle by a blinking light front panel such as a pdp11/70 doug On Wed, Sep 4, 2013 at 10:38 PM, Mark Pizzolato - Info Comm > wrote: OK, so the original hardware supported single cycle stepping. What would expect to happen in the simulator if you stepped single cycles? What details would you want to have access to after stepping at the cycle level? From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Doug Snyder Sent: Wednesday, September 04, 2013 10:32 PM To: Mark Pizzolato - Info Comm Cc: simh at trailing-edge.com Subject: Re: [Simh] single cycle stepping for pdp11 many (if not all) of the pdp11 models support single cycle stepping. to more accurately model an actual pdp11, it would be nice if simh could model that feature. not being able to model that feature is certainly not the end of the world, but it is a noticeable difference. doug On Wed, Sep 4, 2013 at 10:15 PM, 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? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Thu Sep 5 06:02:04 2013 From: bqt at softjar.se (Johnny Billquist) Date: Thu, 05 Sep 2013 12:02:04 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> Message-ID: <5228569C.3060307@softjar.se> 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 || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dsnyder at blueshiftinc.com Thu Sep 5 20:11:56 2013 From: dsnyder at blueshiftinc.com (Doug Snyder) Date: Thu, 5 Sep 2013 17:11:56 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5228569C.3060307@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> Message-ID: do you have any examples of what you mean when you say "different models do different amounts of work in a single cycle"? On Thu, Sep 5, 2013 at 3:02 AM, Johnny Billquist 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 || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > ______________________________**_________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.**com/mailman/listinfo/simh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at softjar.se Fri Sep 6 05:25:27 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 11:25:27 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> Message-ID: <52299F87.1030207@softjar.se> 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 > 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 || > Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > _________________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.__com/mailman/listinfo/simh > > > -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From litt at ieee.org Fri Sep 6 07:28:19 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 06 Sep 2013 07:28:19 -0400 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <52299F87.1030207@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> Message-ID: <5229BC53.4080600@ieee.org> 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 > > 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 || >> Reading murder books >> pdp is alive! || tryin' to stay hip" - B. Idol >> _________________________________________________ >> Simh mailing list >> Simh at trailing-edge.com >> 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: From bqt at softjar.se Fri Sep 6 08:46:00 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 14:46:00 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229BC53.4080600@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> Message-ID: <5229CE88.2010108@softjar.se> 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 >> > 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 || >>> Reading murder books >>> pdp is alive! || tryin' to stay hip" - B. Idol >>> _________________________________________________ >>> Simh mailing list >>> Simh at trailing-edge.com >>> http://mailman.trailing-edge.__com/mailman/listinfo/simh >>> >>> >>> >> >> > > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > From litt at ieee.org Fri Sep 6 10:32:50 2013 From: litt at ieee.org (Timothe Litt) Date: Fri, 06 Sep 2013 10:32:50 -0400 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229CE88.2010108@softjar.se> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> Message-ID: <5229E792.7090308@ieee.org> > The number of cycles above is the *total*. Read the handbook. Not really. You're confusing observed timing with which cycles happen. This is all a matter of how you account for the cycles. The instruction must be fetched. The source must be read. And the destination must be written. These all cause some sort of cycle - whether or not it appears on the external bus. The handbook is talking not about how many cycles happen, but about the effect on instruction timing. That is, accounting for their effect on observed timing. The context of the OP's question was an assumption about which cycles *happen*, not their timing. He wanted to observe/single step them, not measure how long instructions take. I chose to reply mostly in the PDP-11 context, but intentionally included some general information since this question has come up with other architectures as well. From a timing point of view, the fetch can be hidden by an i-cache, by prefetch that overlaps execution, and other tricks. The source can come from cache, from a bypassed result of a previous instruction in the pipeline, or from memory. The destination can go to memory, a write buffer, or a cache. And it can be bypassed direct to the ALU. This all has an impact on timing. And depending on precisely how you define your observation point, which cycles happen. Inside a CPU, most of them happen - except for bypassed operands. Past that point, things get wild depending on cache/write buffer effectiveness. Architecturally, all three cycles always happen sequentially. In a given instance on a given implementation, which ones appear on any particular bus and the resulting instruction timing may vary greatly. [Bypass: A machine may send a write to memory, but notice that a subsequent instruction needs the value before the value arrives in memory. In this case, the value can be sent to the execution unit before it reaches memory - completely or partially bypassing the memory/cache unit, and eliminating a memory cycle. Depending on the exact timing/microarchitecture, the value can come directly from the ALU, from pipeline stages in the CPU, from pipe stages in the memory unit, from a write queue, write buffer or cache.] > 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. You can't do this. A write requires the source operand; you can't start it until you you have the source data. (A clever machine can overlap the access checks, and maybe the address phase of an a/d external bus if the source read doesn't require the bus. But the 11s were not that smart.) You *can* disconnect the write from the next fetch with a write buffer (as I noted), but that doesn't eliminate the write, it just delays it until the write buffer is evicted. All of this amounts to accounting and buffering tricks. With buffers (and I include caches in this), you eliminate some bus cycles. But eventually things get evicted. So the bus cycle happens later - and is charged to something else. Maybe a subsequent instruction. Maybe averaged into memory overhead. With luck, there are multiple references to the the same address, and there is a reduction in external bus cycles due to coalescing. Statistically, that works. Worst case, they all happen. In any case, the details are only of interest to hardware types - they don't and never will enter SimH. > They are not rolled back on a PDP-11. Not in hardware. As you noted, the OS has to do it, which is even slower. However, the resulting memory/register fetches create bus traffic, which the OP would like to see. > Also, the 11/45/50/55 could have a separate Unibus for memory. You > could say that this would be a memory bus. Yes, I was thinking of those machines - the 11/45 counts as 'early'. > 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. We are in violent agreement on the first point. On the second, I go further: the effort would be inconsistent with SimH's goals and design. It should not be attempted. > The PDP-11s that have cache all use a write through cache. Yes. The KL10 was the first DEC machine to have a write-back cache. And it has some novel aspects for software. ['aspect' DEC jargon file: something that *just is*, v.s. a *feature* or a *bug*] This communication may not represent my employer's views, if any, on the matters discussed. On 06-Sep-13 08:46, Johnny Billquist wrote: > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5159 bytes Desc: S/MIME Cryptographic Signature URL: From bqt at softjar.se Fri Sep 6 11:01:45 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:01:45 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229E792.7090308@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> Message-ID: <5229EE59.7080007@softjar.se> On 2013-09-06 16:32, Timothe Litt wrote: >> The number of cycles above is the *total*. Read the handbook. > Not really. You're confusing observed timing with which cycles happen. > > This is all a matter of how you account for the cycles. The instruction > must be fetched. The source must be read. And the destination must be > written. These all cause some sort of cycle - whether or not it appears > on the external bus. The handbook is talking not about how many cycles > happen, but about the effect on instruction timing. That is, accounting > for their effect on observed timing. Did you even read the book? They list both execution times, and memory cycles. Yes, the chapter is about execution times. That does not change that the number of memory cycles used is also shown, and that MOV (R0)+,(R1)+, as an example, is only two memory cycles total. And that includes instruction fetch and execution, source processing and destination processing. Johnny > > The context of the OP's question was an assumption about which cycles > *happen*, not their timing. He wanted to observe/single step them, not > measure how long instructions take. I chose to reply mostly in the > PDP-11 context, but intentionally included some general information > since this question has come up with other architectures as well. > > From a timing point of view, the fetch can be hidden by an i-cache, by > prefetch that overlaps execution, and other tricks. The source can come > from cache, from a bypassed result of a previous instruction in the > pipeline, or from memory. The destination can go to memory, a write > buffer, or a cache. And it can be bypassed direct to the ALU. > > This all has an impact on timing. And depending on precisely how you > define your observation point, which cycles happen. Inside a CPU, most > of them happen - except for bypassed operands. Past that point, things > get wild depending on cache/write buffer effectiveness. > > Architecturally, all three cycles always happen sequentially. In a > given instance on a given implementation, which ones appear on any > particular bus and the resulting instruction timing may vary greatly. > > [Bypass: A machine may send a write to memory, but notice that a > subsequent instruction needs the value before the value arrives in > memory. In this case, the value can be sent to the execution unit > before it reaches memory - completely or partially bypassing the > memory/cache unit, and eliminating a memory cycle. Depending on the > exact timing/microarchitecture, the value can come directly from the > ALU, from pipeline stages in the CPU, from pipe stages in the memory > unit, from a write queue, write buffer or cache.] > >> 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. > You can't do this. A write requires the source operand; you can't start > it until you you have the source data. (A clever machine can overlap > the access checks, and maybe the address phase of an a/d external bus if > the source read doesn't require the bus. But the 11s were not that smart.) > > You *can* disconnect the write from the next fetch with a write buffer > (as I noted), but that doesn't eliminate the write, it just delays it > until the write buffer is evicted. > > All of this amounts to accounting and buffering tricks. With buffers > (and I include caches in this), you eliminate some bus cycles. But > eventually things get evicted. So the bus cycle happens later - and is > charged to something else. Maybe a subsequent instruction. Maybe > averaged into memory overhead. With luck, there are multiple references > to the the same address, and there is a reduction in external bus cycles > due to coalescing. Statistically, that works. Worst case, they all happen. > > In any case, the details are only of interest to hardware types - they > don't and never will enter SimH. > >> They are not rolled back on a PDP-11. > Not in hardware. As you noted, the OS has to do it, which is even slower. > > However, the resulting memory/register fetches create bus traffic, which > the OP would like to see. >> Also, the 11/45/50/55 could have a separate Unibus for memory. You >> could say that this would be a memory bus. > Yes, I was thinking of those machines - the 11/45 counts as 'early'. >> 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. > We are in violent agreement on the first point. On the second, I go > further: the effort would be inconsistent with SimH's goals and design. > It should not be attempted. >> The PDP-11s that have cache all use a write through cache. > Yes. The KL10 was the first DEC machine to have a write-back cache. > And it has some novel aspects for software. > > ['aspect' DEC jargon file: something that *just is*, v.s. a *feature* or > a *bug*] > > This communication may not represent my employer's views, > if any, on the matters discussed. > > On 06-Sep-13 08:46, Johnny Billquist wrote: >> 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. > > > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > From aek at bitsavers.org Fri Sep 6 11:07:33 2013 From: aek at bitsavers.org (Al Kossow) Date: Fri, 06 Sep 2013 08:07:33 -0700 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229E792.7090308@ieee.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> Message-ID: <5229EFB5.4070202@bitsavers.org> On 9/6/13 7:32 AM, Timothe Litt wrote: > This is all a matter of how you account for the cycles. The instruction must be fetched. The source must be read. And the destination must be written. These all cause some sort of cycle - whether > or not it appears on the external bus. Non-processor requests will also effect how often you can get out the Unibus. I remember the VT11 being a particularly bad bus hog. Massbus disks and I would think comms processors would be a problem too. I would imagine this would be a huge win for even the smallest caches to try keeping the CPU off of the Unibus. From bob at supnik.org Fri Sep 6 11:13:07 2013 From: bob at supnik.org (Bob Supnik) Date: Fri, 06 Sep 2013 11:13:07 -0400 Subject: [Simh] Various PDP11 fixes and enhancements Message-ID: <5229F103.605@supnik.org> 1. RK611 bug - RK07 not recognized on RSTS/E. Fixed. New version smoke-tested with VMS, M+, RSTS/E, and RT. 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. Only tested with RT11, as M+ and RSTS/E support requires a unique SYSGENs. Feel free to hack on it. 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that it should not track changes in floating point instructions is still open. As usual, look for recent checkins in the GitHub repository, or new files in the interim corrections directory on the SimH web site (http://simh.trailing-edge.com/interim). /Bob From bqt at softjar.se Fri Sep 6 11:33:20 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:33:20 +0200 Subject: [Simh] single cycle stepping for pdp11 In-Reply-To: <5229EFB5.4070202@bitsavers.org> References: <0CC6789C1C831B4C8CCFF49D45D7010FBF6090670A@REDROOF2.alohasunset.com> <5228569C.3060307@softjar.se> <52299F87.1030207@softjar.se> <5229BC53.4080600@ieee.org> <5229CE88.2010108@softjar.se> <5229E792.7090308@ieee.org> <5229EFB5.4070202@bitsavers.org> Message-ID: <5229F5C0.4050201@softjar.se> On 2013-09-06 17:07, Al Kossow wrote: > On 9/6/13 7:32 AM, Timothe Litt wrote: > >> This is all a matter of how you account for the cycles. The >> instruction must be fetched. The source must be read. And the >> destination must be written. These all cause some sort of cycle - >> whether >> or not it appears on the external bus. > > Non-processor requests will also effect how often you can get out the > Unibus. > I remember the VT11 being a particularly bad bus hog. Massbus disks and > I would think comms processors would be a problem too. > I would imagine this would be a huge win for even the smallest caches to > try > keeping the CPU off of the Unibus. Indeed. And I just realized/remembered one more thing about the separate memory bus thingy. One could also argue that the memory on the 11/24 and 11/44 are on a separate memory bus, since these machines also have 22-bit addressing for memory, which cannot be done over the Unibus. However, they share parts of the signals with the Unibus, so for those machines, it does not really offload the bus in any way. Johnny From bqt at softjar.se Fri Sep 6 11:40:19 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 17:40:19 +0200 Subject: [Simh] Various PDP11 fixes and enhancements In-Reply-To: <5229F103.605@supnik.org> References: <5229F103.605@supnik.org> Message-ID: <5229F763.8090807@softjar.se> On 2013-09-06 17:13, Bob Supnik wrote: > 1. RK611 bug - RK07 not recognized on RSTS/E. Fixed. New version > smoke-tested with VMS, M+, RSTS/E, and RT. Nice! > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. > Only tested with RT11, as M+ and RSTS/E support requires a unique > SYSGENs. Feel free to hack on it. Is this something specific to a third massbus, or just a case of the RS03/RS04 devices as such? I mean, on M+ you can have all type of devices on the same massbus. > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that > it should not track changes in floating point instructions is still open. I wasn't aware of any discussions. Could you, or someone sum it up? Is it a question of whether MMR1 should reflect changes to the general registers if a FP instruction is aborted? If so, I'm pretty sure they should be. I think I have read it somewhere in some documentation, and could try and locate it, if that really is the question. Also, MMR1 might reflect changes to the PC as well, as far as I can read documentation... But it's "complicated". :-) Johnny > > As usual, look for recent checkins in the GitHub repository, or new > files in the interim corrections directory on the SimH web site > (http://simh.trailing-edge.com/interim). > > /Bob > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From elson at pico-systems.com Fri Sep 6 11:55:25 2013 From: elson at pico-systems.com (Jon Elson) Date: Fri, 06 Sep 2013 10:55:25 -0500 Subject: [Simh] Simh Digest, Vol 117, Issue 4 In-Reply-To: References: Message-ID: <5229FAED.5080907@pico-systems.com> > Date: Thu, 05 Sep 2013 12:02:04 +0200 > From: Johnny Billquist > To: simh at trailing-edge.com > Subject: Re: [Simh] single cycle stepping for pdp11 > Message-ID: <5228569C.3060307 at softjar.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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. >>> >> >> >> 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. > > I worked for years on PDP-11s, and never heard of this single cycle stepping. I can imagine there might be a jumper on one of the boards that enables this for customer engineer's debugging, but as far as I know you only got single complete instruction stepping with the halt switch. I worked with the 11/20, 11/34, 11/45 and even the CalData emulator. Jon From bqt at softjar.se Fri Sep 6 12:14:20 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 06 Sep 2013 18:14:20 +0200 Subject: [Simh] Simh Digest, Vol 117, Issue 4 In-Reply-To: <5229FAED.5080907@pico-systems.com> References: <5229FAED.5080907@pico-systems.com> Message-ID: <5229FF5C.1070101@softjar.se> On 2013-09-06 17:55, Jon Elson wrote: > >> Date: Thu, 05 Sep 2013 12:02:04 +0200 >> From: Johnny Billquist >> To: simh at trailing-edge.com >> Subject: Re: [Simh] single cycle stepping for pdp11 >> Message-ID: <5228569C.3060307 at softjar.se> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> 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. >>> >>> 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. >> > I worked for years on PDP-11s, and never heard of this single cycle > stepping. > I can imagine there might be a jumper on one of the boards that enables > this > for customer engineer's debugging, but as far as I know you only got single > complete instruction stepping with the halt switch. I worked with the > 11/20, 11/34, 11/45 and even the CalData emulator. I would have expected the 11/45 to be similar to the 11/70 in this case. The 11/70 have one switch on the front panel labelled "S INST/S BUS CYCLE". If you are halted, and pull the CONT switch, with HALT enabled, it will single step. Either one instruction, or one bus cycle, depending on this switch. Johnny From djg at pdp8online.com Mon Sep 16 21:15:02 2013 From: djg at pdp8online.com (David Gesswein) Date: Mon, 16 Sep 2013 21:15:02 -0400 Subject: [Simh] PDP8 changes Message-ID: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> I'm not sure where simh development is discussed with the move to github. I submitted a couple of bug but I have some other changes I have made to my version and want to see if they are of interest. 1) Modify bin loader to read multiple section tapes. 2) Modify breakpoint command to add breakpoint on instruction value. 3) Raw socket for teletype console instead of telnet wrapped. From bob at supnik.org Mon Sep 16 21:59:12 2013 From: bob at supnik.org (Bob Supnik) Date: Mon, 16 Sep 2013 21:59:12 -0400 Subject: [Simh] Recent bug fixes Message-ID: <5237B770.6020104@supnik.org> Message: 5 Date: Fri, 06 Sep 2013 17:40:19 +0200 From: Johnny Billquist To:simh at trailing-edge.com Subject: Re: [Simh] Various PDP11 fixes and enhancements Message-ID:<5229F763.8090807 at softjar.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 2013-09-06 17:13, Bob Supnik wrote: > 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. > Only tested with RT11, as M+ and RSTS/E support requires a unique > SYSGENs. Feel free to hack on it. Is this something specific to a third massbus, or just a case of the RS03/RS04 devices as such? I mean, on M+ you can have all type of devices on the same massbus. >>> The Massbus implementation links an RH to a single device type. >>> This is an artifact of the simulator, not of real life. >>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units. > 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that > it should not track changes in floating point instructions is still open. I wasn't aware of any discussions. Could you, or someone sum it up? Is it a question of whether MMR1 should reflect changes to the general registers if a FP instruction is aborted? If so, I'm pretty sure they should be. I think I have read it somewhere in some documentation, and could try and locate it, if that really is the question. Also, MMR1 might reflect changes to the PC as well, as far as I can read documentation... But it's "complicated". Johnny >>> Looking at the J-11 microcode: >>> MMR1 does not track FP changes. This is because in early systems, like >>> the 11/45, it didn't have enough bits to record an 8 byte register change. >>> The J-11 goes through great pains to undo register changes before it >>> springs a trap or memory management abort. >>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction >>> stream is read through a special microinstruction, because the hardware >>> always prefetches the next instruction word. Even modes 47 and 57, which >>> make no sense, don't update MMR1. /Bob Supnik From spedraja at gmail.com Tue Sep 17 02:49:26 2013 From: spedraja at gmail.com (SPC) Date: Tue, 17 Sep 2013 08:49:26 +0200 Subject: [Simh] PDP8 changes In-Reply-To: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> References: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> Message-ID: I think they are interesting. 1 and 3 in particular. SPc. 2013/9/17 David Gesswein > I'm not sure where simh development is discussed with the move to > github. I submitted a couple of bug but I have some other changes I > have made to my version and want to see if they are of interest. > > 1) Modify bin loader to read multiple section tapes. > 2) Modify breakpoint command to add breakpoint on instruction value. > 3) Raw socket for teletype console instead of telnet wrapped. > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh > -- Gracias | Regards Saludos - Greetings - Freundliche Grüße - Salutations -- *Sergio Pedraja* twitter: @sergio_pedraja skype: Sergio Pedraja http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://www.quora.com/Sergio-Pedraja http://spedraja.wordpress.com https://www.xing.com/profile/Sergio_Pedraja http://www.viadeo.com http://www.avalonred.com/ ----- No crea todo lo que ve, ni crea que está viéndolo todo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark at infocomm.com Tue Sep 17 09:09:17 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Tue, 17 Sep 2013 06:09:17 -0700 Subject: [Simh] PDP8 changes In-Reply-To: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> References: <201309170115.r8H1F2xX020451@hugin2.pdp8online.com> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010FDF8C2462DE@REDROOF2.alohasunset.com> Hi David, On Monday, September 16, 2013 at 6:15 PM, David Gesswein wrote: > I'm not sure where simh development is discussed with the move to > github. I submitted a couple of bug but I have some other changes I have > made to my version and want to see if they are of interest. > > 1) Modify bin loader to read multiple section tapes. > 2) Modify breakpoint command to add breakpoint on instruction value. > 3) Raw socket for teletype console instead of telnet wrapped. Please create separate issues on the github issue system to discuss the details of each of these points. Anyone else can chime in to the discussion of any issue on that system as well. Thanks. - Mark From bob at supnik.org Wed Sep 18 12:49:29 2013 From: bob at supnik.org (Bob Supnik) Date: Wed, 18 Sep 2013 12:49:29 -0400 Subject: [Simh] OS/8 image with PIP10 AND TC08 Message-ID: <5239D999.4010005@supnik.org> In order to debug a problem with PIP10, I'm looking for a generated OS8 V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has one ready to go, please let me know. /Bob From bqt at softjar.se Wed Sep 18 13:41:58 2013 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 18 Sep 2013 19:41:58 +0200 Subject: [Simh] OS/8 image with PIP10 AND TC08 In-Reply-To: <5239D999.4010005@supnik.org> References: <5239D999.4010005@supnik.org> Message-ID: <5239E5E6.1090501@softjar.se> On 2013-09-18 18:49, Bob Supnik wrote: > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. Slightly sidesteping the issue. If you have a recent enough version of OS/8 and SET.SV, you can swap device drivers at runtime. PIP10 actually only looks at a signature for the driver in order to figure out if it is a TC08 or a TD8E. Once it has done this, PIP10 has its own code for both the TC08 and TD8E in the PIP10 image. Johnny From bqt at softjar.se Fri Sep 20 09:08:00 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 20 Sep 2013 15:08:00 +0200 Subject: [Simh] Recent bug fixes In-Reply-To: <5237B770.6020104@supnik.org> References: <5237B770.6020104@supnik.org> Message-ID: <523C48B0.5090203@softjar.se> On 2013-09-17 03:59, Bob Supnik wrote: > Message: 5 > Date: Fri, 06 Sep 2013 17:40:19 +0200 > From: Johnny Billquist > To:simh at trailing-edge.com > Subject: Re: [Simh] Various PDP11 fixes and enhancements > Message-ID:<5229F763.8090807 at softjar.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2013-09-06 17:13, Bob Supnik wrote: > >> 2. RS03/RS04 - third Massbus adapter with RS03/RS04 fixed head disk. >> Only tested with RT11, as M+ and RSTS/E support requires a unique >> SYSGENs. Feel free to hack on it. > > Is this something specific to a third massbus, or just a case of the > RS03/RS04 devices as such? I mean, on M+ you can have all type of > devices on the same massbus. > >>>> The Massbus implementation links an RH to a single device type. >>>> This is an artifact of the simulator, not of real life. >>>> Three RH adapters allows for 8 RP/RM units, 8 TU units, and 8 RS units. I see. So simh don't make any distinction between the RM and RP? The registers have a couple of differences between these as well, but if I remember right, they are only for error recovery, so they won't affect normal operation. But on an 11M system, I'm not sure you can even mix RM and RP on the same massbus. (I might be wrong on that one, though. I need to check.) >> 3. PDP11 CPU - MMR1 no longer tracks changes to the PC. The issue that >> it should not track changes in floating point instructions is still open. > > I wasn't aware of any discussions. Could you, or someone sum it up? Is > it a question of whether MMR1 should reflect changes to the general > registers if a FP instruction is aborted? If so, I'm pretty sure they > should be. I think I have read it somewhere in some documentation, and > could try and locate it, if that really is the question. > > Also, MMR1 might reflect changes to the PC as well, as far as I can read > documentation... But it's "complicated". > > Johnny > >>>> Looking at the J-11 microcode: >>>> MMR1 does not track FP changes. This is because in early systems, like >>>> the 11/45, it didn't have enough bits to record an 8 byte register >>>> change. >>>> The J-11 goes through great pains to undo register changes before it >>>> springs a trap or memory management abort. >>>> Likewise, the J-11 never tracks PC changes in MMR1. The instruction >>>> stream is read through a special microinstruction, because the hardware >>>> always prefetches the next instruction word. Even modes 47 and 57, >>>> which >>>> make no sense, don't update MMR1. Aha. So I was looking at the 11/70 processor handbook, which says that MMR1 would track changes to the PC on at least that CPU. But since change to the PC is not really important anyway I can see that either way would work just as fine. But I don't see the problem with an 8 byte change. MMR1 have 5 bits for telling the changed value. This is a signed value, so it should range from +15 to -16. What am I missing??? Johnny > > /Bob Supnik > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh From simulator at swabhawat.com Mon Sep 23 10:55:15 2013 From: simulator at swabhawat.com (R. Voorhorst) Date: Mon, 23 Sep 2013 14:55:15 +0000 (UTC) Subject: [Simh] OS/8 image with PIP10 AND TC08 References: <5239D999.4010005@supnik.org> Message-ID: Bob Supnik writes: > > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. > > /Bob > If you need an OS8 image with drivers and so, I have some distribution media available with RK8E format with a config file on Windows. Please inform how you want to receive it. Best regards R. Voorhorst From simulator at swabhawat.com Wed Sep 25 14:53:48 2013 From: simulator at swabhawat.com (R. Voorhorst) Date: Wed, 25 Sep 2013 18:53:48 +0000 (UTC) Subject: [Simh] OS/8 image with PIP10 AND TC08 References: <5239D999.4010005@supnik.org> Message-ID: Bob Supnik writes: > > In order to debug a problem with PIP10, I'm looking for a generated OS8 > V3D image with PIP10 and TC08, rather than TD8E, drivers. If anyone has > one ready to go, please let me know. > > /Bob > Simh issue #43 Pip10/TD8,TC08 solved Best regards, R. Voorhorst From bob at supnik.org Mon Sep 30 15:52:29 2013 From: bob at supnik.org (Bob Supnik) Date: Mon, 30 Sep 2013 15:52:29 -0400 Subject: [Simh] PIP10 Message-ID: <5249D67D.9000308@supnik.org> R Voorhoost pointed out on the GitHUB mailing list that PIP10 is working correctly. The issues appear to have been cockpit errors. First, the DECtape must be attached with the -F switch, to create an 18b-formatted image. Second, the syntax for PIP10 is very finicky. For example, I was trying: *DTA0:/Z instead of *DTA0: