Interest in Cycle-Realistic version of PiDP-8/I?

[Steve Tockey]

All,

In about November/December of 2021 I published a version of the PiDP-8/I emulator that makes the Sing Step switch on the front panel work the same as on a real -8, namely it executes a single CPU cycle (Fetch, Defer, Execute) then stops. You can read all about it here:

https://groups.google.com/g/pidp-8/c/EdqMPILxRnM/m/Kb7ycuI5AwAJ

The reason for this post is to ask if anyone else is interested in having this version become part of the standard PiDP-8/I software distribution?

A direct consequence of this change is that Oscar's front panel functions of Mount USB Media, Restart SIMH, and Reboot the Pi got re-mapped into different front panel switch sequences. So from a PiDP-8/I end user perspective, it probably boils down to a question of preferring the existing Mount USB/Restart/Reboot key sequences at the expense of no cycle-realistic emulation vs. cycle-realistic emulation but at the expense of having to learn different switch sequences for Mount USB/Restart/Reboot behavior.

I see a couple of possible responses:

1) No, I'm happy with the current behavior and I am not interested in any other behavior.

2) I would be ok with making it available to others to use as some kind of selectable option but I am not interested in using it myself.

3) I would be interested in using it myself, but I think others will still want the current behavior.

4) I think this version should become the "standard" behavior for the PiDP-8/I.

Cheers,

-- steve

[Mike Katz]

Steve,

I think emulating the PDP-8 as accurately as possible is a worthy cause and I strongly support adding it to the PiDP-8/I version of SIMH.  If memory serves I believe that the single step, single instruction and halt switches work differently on different models of the family of 8 (some have single instruction, some have halt, etc.).  As a future project it would be cool to emulate them all.

Regardless of what is implemented  I would recommend making it some kind of option that can be enabled or disabled.

Thank you for your continued time and effort in keeping this project alive.

Thanks,

        Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/70f77115-ffde-4a47-8002-552992bc3c7en%40googlegroups.com.

[William Cattey]

I plan to sync the branch, build it and try it out.

QUESTION:  Is there much of a performance hit by switching to cycle-realistic emulation?

-Bill

[Steve Tockey]

Mike,

"I think emulating the PDP-8 as accurately as possible is a worthy cause and I strongly support adding it to the PiDP-8/I version of SIMH."

Thanks for voting.

"If memory serves I believe that the single step, single instruction and halt switches work differently on different models of the family of 8 (some have single instruction, some have halt, etc.)."

On the "Classic" -8, the -8/I, -8/L, and -8/S the Stop switch is momentary so you need a Single Inst toggle to execute one (whole) instruction at a time when Cont is pressed. On the -8/e, /m, and /f the Halt switch was changed to a toggle so just leaving it down has the same effect when Cont is pressed: execute a whole machine instruction. On the 8/a there is a HLT/SS push button. It looks like they abandoned Single Step mode on the -8/a.

-- steve

[Bill Saltzstein]

I'd prefer (4), but probably better to make it optional so those who like it the way it is can keep the status quo.

Thanks Steve!

[Steve Tockey]

Bill,

"QUESTION:  Is there much of a performance hit by switching to cycle-realistic emulation?"

Good question, but as far as I can tell there's no penalty, at least when SIMH is run throttled. To be sure, I always run mine throttled to 413K instructions per second to approximate the performance of a real 8/e. The original PiDP-8/I and Cycle Realistic code both run on a Pi 3B+ (with ILS enabled) at around 8-11% CPU load. I suspect you might notice it being slower if you run it unthrottled, possibly on the order of 80% slower. This is because it makes a full pass through the main instruction loop once for each memory cycle instead of once for each machine instruction. Assuming about 40% of instructions are Fetch-only, 40% Fetch-Execute, and 20% Fetch-Defer-Execute that would add 80 additional SIMH instruction loop cycles per 100 actual -8 machine instruction.

-- steve

[Rick Murphy]

I think this should be the standard behavior. The emulator should work like a real PDP-8/I when possible.

    -Rick

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/66925c7a-b3a7-4b1c-97ec-2ba6a28a7466n%40googlegroups.com.

--

Rick Murphy, D. Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA

[Nigel Williams]

On Tue, May 2, 2023 at 1:22 PM Rick Murphy <k1mu....@gmail.com> wrote:
> I think this should be the standard behavior. The emulator should work like a real PDP-8/I when possible.

I agree, +1 vote to enable this behaviour.

[thunt...@gmail.com]

I too prefer (4) and I am fine with re-mapped switches for mount, restart & reboot.

Thanks for all your work on this!

Tom Hunter

[Randy James]

I agree with Bill.  Add it as an option but retain the existing methods.  

The switch panels are great, but are extremely lightweight and easily be pushed over.   

Let’s not injure a bunch of machines and/or people in the process.

On May 1, 2023, at 6:30 PM, Bill Saltzstein <bills...@gmail.com> wrote:

I'd prefer (4), but probably better to make it optional so those who like it the way it is can keep the status quo.

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/20a6a36b-d275-4068-82ac-29612b2edbfcn%40googlegroups.com.

[Vincent Slyngstad]

I have been working on another aspect of SIMH that is likely of interest here.  My version implements 'set cpu' commands for various models.  So 'set cpu pdp8i' means that you are no longer emulating an 8/E, but rather the 8/i.  Various other models are also supported, especially with respect to the CPU.  The support for PDP12 and DECmate should theoretically enable massive changes to the I/O environment, but those are nowhere near complete as yet.  (Also, LINC/8 isn't very complete, and I don't really have a test suite to debug it against either.)

My early effort is available here:

https://svn.so-much-stuff.com/svn/trunk/pdp8/simh

Soon I will be moving it to the openSIMH code base, where I hope to eventually submit the code.  That also fixes an issue where a PDP-12 interrupt handling hook was confused by CAF instructions (which broke 8/E and later emulation).

Anyway.  How extensive are your changes, Steve?

Vince

[Randy Mongenel]

On Mon, May 1, 2023 at 4:29 PM Steve Tockey <steve...@gmail.com> wrote:

 

 On the 8/a there is a HLT/SS push button. It looks like they abandoned Single Step mode on the -8/a.

The HLT/SS push button on the optional 8/a Programmers Console will stop operation and put it into single machine cycle step mode. Each subsequent press of the button will run a single cycle, according to the documentation.
Is this not the same function?

[Steve Tockey]

Randy,

You are right. SS on the 8/a does single step. I assumed it was single instruction. I haven't used an 8/a since 1984.  :^)

-- steve

[Curtis Dean Smith (史國興)]

I apologize if this is the wrong place to ask, but I am not clear on the difference single step and single instruction.  Is there a dummy's explanation?

[Randy Mongenel]

On Mon, May 8, 2023 at 4:30 PM Curtis Dean Smith (史國興) <smi...@gmail.com> wrote:

I apologize if this is the wrong place to ask, but I am not clear on the difference single step and single instruction.  Is there a dummy's explanation?

Instructions can take many machine cycle steps, depending on what they do, how long they are, etc. A single machine step could be part of an instruction, like loading an operand for an arithmetic instruction before taking the step to perform the arithmetic.

 

On Monday, May 8, 2023 at 3:43:56 PM UTC-7 Steve Tockey wrote:

Randy,

You are right. SS on the 8/a does single step. I assumed it was single instruction. I haven't used an 8/a since 1984.  :^)

I recently acquired one. It's not running just yet, it'll be a restoration project.

 

-- steve

On Monday, May 8, 2023 at 2:08:23 PM UTC-7 mong...@gmail.com wrote:

On Mon, May 1, 2023 at 4:29 PM Steve Tockey <steve...@gmail.com> wrote:

 

 On the 8/a there is a HLT/SS push button. It looks like they abandoned Single Step mode on the -8/a.

The HLT/SS push button on the optional 8/a Programmers Console will stop operation and put it into single machine cycle step mode. Each subsequent press of the button will run a single cycle, according to the documentation.
Is this not the same function?

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/d6fd809a-45e4-4ef8-a509-7e1492594de5n%40googlegroups.com.

[Curtis Dean Smith (史國興)]

Ah-ha!  Thank you!

[Vincent Slyngstad]

In this case (as for pdp8 in general), the "step' is nearly always the memory cycle.  So SS lets you see the memory during the fetch, defer, and execute cycles. SI stops just at the end of the instruction (often execute, except for JMP, etc. which don't need the extra steps).  I believe there's an exception for some EAE instructions, which take multiple cycles to multiply or normalize or whatever.

Vince

[Obsolescence]

Steve,

My vote also would be for option 4 (it becomes the standard distribution). I can easily update the manual and web site, and those hidden functions can still be achieved with some 'magic' double switch combination, so no loss of functionality.

OTOH, making it as an easily chosen-and-installed alternative to the default version is also not a bad idea, that is fine too.

It would be good to also wedge in Vince's CPU option functionality. (Although, it should be rolled into the regular simh as well).

I'm kind of preoccupied with the upcoming PiDP-10, but it is rather clear that right after that, the PiDP-8 needs some work done. Over the last few years, the graphics options have improved, lots of interesting software came out that deserves to be bundled in too, so those also point to the need to upgrade things a bit.

Maybe this is too optimistic, I might be running ahead of what is feasible given people's time schedules and the hassle of travel. 

But:

I was thinking of doing a four or five day PDP-8 meetup in October, and see if some of the passionate PDP-8 aficionados would join for such a thing. 

All these new developments could be a nice side project in such a PDP-8 meeting, one of the topics/projects. And it just so happens that I can use a resort hotel for free for this purpose, so nothing else but travel cost to attend :-) 

More to come soon on this idea!

Kind regards,

Oscar.

[Steve Tockey]

Vince and all,

Yes, PDP-8 instructions take between 1 and 3 memory cycles. All instructions need at least 1 cycle, Fetch. For the "OPR" instructions (op code 7) and the direct JMP (and, IIRC direct JMS) that's all they need, These fully execute in the one Fetch memory cycle. Direct-addressed "Memory Reference Instructions" (the "MRI"s, AND, TAD, ISZ, DCA) need the Defer cycle when indirectly addressed thus they are 2 cycle instructions. Indirect JMP (and, IIRC indirect JMS) also take 2 memory cycles but I would need to check if it goes Fetch-Execute or Fetch-Defer. Indirectly addressed MRIs take 3 cycles, Fetch-Defer-Execute.

The Cycle Realistic version implements the Fetch, Defer, and Execute cycles and should properly display the CPU status on the PiDP-8/I front panel when the Sing Step switch is used. Again, see the referenced thread in the first message of this thread for all of the details.

-- steve

[Steve Tockey]

Sorry. To be more correct:

The OPR instructions (op code 7), direct JMP (op code 5) and, I believe, direct JMS, op code 4) are single-cycle instructions requiring Fetch only.

Directly addressed MRIs (AND (0), TAD(1), ISZ(2), DCA(3)) are all 2 cycle, Fetch-Execute.

Indirectly addressed JMP(5), and I believe JMS(4) are 2 cycle but I don't remember if it is Fetch-Execute or Fetch-Defer.

Indirectly addressed MRIs are 3 cycle, Fetch-Defer-Execute.

-- steve

[Steve Tockey]

Vince,

Apologies for the delayed reply. The Cycle Realistic code changes are really not all that extensive in terms of the total number of lines of code. It really is just a matter of re-arranging the lines of code so that they align with the Fetch, Defer, and Execute major states. Where the original SIMH PDP-8 code is a switch-case inside of a big loop, one case for each op code, the Cycle Realistic code has the same user loop but has an inner switch-case for each major state and inside each major state case is another switch-case for the relevant op codes in that major state. So it really was mostly a matter of moving the lines of code around more than anything.

Let me know if you need more detail.

-- steve

[Mike Katz]

Vince,

Does an indirect access to the auto index words insert an extra cycle?  Also does the increment affect the link bit?

Thanks,

      

       Mike

--

You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/4583756c-4603-467d-9f3d-dddafc317815n%40googlegroups.com.

[Vincent Slyngstad]

An indirect access inserts a memory cycle (defer), to access the value.  The increment for auto-index takes place during the "modify" part of the read-modify-write memory cycle, by generating a carry-in to the usual add of 0000.  The carry-out, if any, is not propagated to the Link bit during defer cycles.

Vince

[Vincent Slyngstad]

In the interim I had a look at your code, and how it relates to the code in openSIMH. I hadn't realized the extent to which the PiDP SIMH and the mainstream release have diverged.  It would be a worthy project to get a PiDP running off the current openSIMH code base.  There are hooks for front panels and such now, but I don't know enough about how it was done for PiDP.  My hands are pretty full already with various projects and ideas.

Vince

[Randy Merkel]

So an indirect + auto-index adds two defer cycles, I.e. the CPU has to write the index to core?

Thanks!

[Vincent Slyngstad]

No, just one.  The increment (autoindex) takes place during the"modify" part of the read-modify-write for the defer cycle.

[Randy Merkel]

Not following, but maybe my core memory knowledge is rusty. By read-modify-write, are you referring to core destructive read? I assumed that the core subsystem did the write back automatically.

Here’s what I was thinking:

1st cycle - fetch

2nd cycle - defer - read effective address from core 

3rd cycle - defer?? write back eff address + 1 to core

Execute

Or is it:

1st cycle - fetch (destructive read, write back)

2nd cycle - defer - (destructive read, increment, write back)

Execute

Sorry for the PDP8/core 101 question.

BTW I think cycle-realistic PiDP-8/I is a great idea!

[folke...@gmail.com]

Hi,

for my implementation of the PDP-8/I in VHDL and software (running on https://pdp8.app/ and soon coming to the PiDP/8), I used the actual schematics so I can explain how it works in the PDP-8/I. The destructive read of the core memory is handled by the CPU as you explained, it always writes back a value to memory. But it goes through the central adder circuit, i.e. the value is not gated back directly. And if auto indexing is active, the "carry insert" signal is generated and gated to the adder, thereby adding 1 to the value written back to core. This circuit allows a free (as in cycles) increment of 1 to any core value that is read.

You can study this part of the CPU on page 5 of this schematic: PDP8-I_CPU_blueprints_1969.pdf (uni-stuttgart.de)

The lower part shows how the auto index signal is generated while the central part shows that this causes the carry insert signal to be activated. This signal is connected to the adder circuit of the central register bus that sits between core memory read and write (back).

Hope that helps,

Folke

[Vincent Slyngstad]

Yes, every core read requires a write, otherwise contents of memory are lost (zeroed).  So every cycle is defined to do a read, possibly modify the buffer, then write.  Consider a DCA I FOO, which would do FETCH, DEFER, and EXECUTE CYCLES:

FETCH READ: Read (and destroy) the instruction

FETCH MODIFY: Do nothing, leaving instruction value in buffer

FETCH WRITE: Restore the instruction, (next comes DEFER, because indirect)

DEFER READ: Read (and destroy) the pointer FOO

DEFER MODIFY: Increment pointer if auto-index, otherwise don't

DEFER WRITE: Restore the (possibly indexed) pointer FOO

EXECUTE READ: Read (and destroy) what FOO points at

EXECUTE MODIFY: Replace the buffer contents with the value of AC

EXECUTE WRITE: Store the buffered value where FOO points to

Hope that clarifies things; details like the timing of DCA clearing AC, etc are omitted, to focus on what's gpoing on with memory.

[Ian Schofield]

Hi all,

 Folke, your web page is FAB.  And yes and the only ways to get cycle realism is using an FPGA or, a single task on a microcontroller both with timing pads.

 The VHDL bit can be a bit daunting so if you want a trivial implementation see https://opencores.org/projects/pdp8l. The cpu bit is reasonably simple.

 Having said this, I would note that the PDP8 is not a synchronous (clocked) CPU and the overall cycle time is determined by the length of a memory cycle using a monostable.

 The cycle of destructive read to the MB and then a writeback meshes nicely with the ISZ instruction where the MB is incremented prior to writeback.

 This useful mode is also used for 3 cycle DMA where the CA and WC locations are incremented in the same way. To emulate this requires

 a timing pad for each memory cycle and there may be a few.  To extend Vincent's outline above .... Minimum ... NOP (read/write instruction) to Maximum eg DCA I 10

  (read/write instruction, read and increment loc 10, write loc 10, read @incremented address in loc 10, write (ACC)). The fact that all cycles end with a core write

 does mean that other things eg IAC can occur during the write cycle which give time for registers to settle. There are multiple time states here

 for the sequencing of the OPR instructions eg CLA then CMA then RAL etc.

 Overall, this is achievable and given that micros running at many MHz are around these days, I think a C app would be OK rather than resorting to machine code.

 And, the granularity of the timing delays would be reasonable. However, to synchronously drive all the lights is simpler using an FPGA (lots of I/O pins).

Regards, Ian.

[Mike Katz]

DCA I 10 is a memory write what about the following instruction:

ISZ I 10

For this instruction the following things need to happen (not necessarily in this order):

• Fetch instruction (writing memory back after read)
• Update the PC
• Decode Instruction
• Read Memory for address of data (write after read)
  
• Read memory for data (write after read not necessary because the value will be written back after incrementing)
  
• increment data
  
• Read memory for address of data (no write after read because the auto index will write it back)
• Write data to memory
• increment address of data
• write address of data to memory
• if Z flag is set increment PC

Vince, et. al.  I would love to lean how the PDP=8 handles all of the above operations.  Even down to the bus signals in each phase if possible.  My digital logic abilities are not up to discerning what is going on from the schematic.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/40ce4a5c-8d05-4b64-b00d-e82c30df4baen%40googlegroups.com.

[Ian Schofield]

Absolutely! This is a gem instruction with even more things happening.

A place to start is:  ia902907.us.archive.org/17/items/bitsavers_decpdp8pdpManualFeb66_21177111/F-87_PDP-8_Maintenance_Manual_Feb66_text.pdf

This is the best I can find that explains what is happening but it is difficult to follow. Hope it helps....

Anyway, if you can write a state table as above for ISZ I 10 then you are well on the way towards an implementation.

[Randy Merkel]

Thanks Vincent and Folke!

I've been reading Prosser's Art of Digitial Design which shows a another memory cycle to write the index back, but that's for IC memory and not core.

BTW, I'd be interested in a "Straight-Eight" version of the kit as well. I guess there was a thought to have one orignally?

Randy

[Vincent Slyngstad]

On Thursday, February 8, 2024 at 10:52:23 AM UTC-8 justme...@gmail.com wrote:

DCA I 10 is a memory write what about the following instruction:

ISZ I 10

For this instruction the following things need to happen (not necessarily in this order):

• Fetch instruction (writing memory back after read)
• Update the PC
• Decode Instruction
• Read Memory for address of data (write after read)
  
• Read memory for data (write after read not necessary because the value will be written back after incrementing)
  
• increment data
  
• Read memory for address of data (no write after read because the auto index will write it back)
• Write data to memory
• increment address of data
• write address of data to memory
• if Z flag is set increment PC

Vince, et. al.  I would love to lean how the PDP=8 handles all of the above operations.  Even down to the bus signals in each phase if possible.  My digital logic abilities are not up to discerning what is going on from the schematic.

Well, all the finest details about bus signals and such vary a bit depending on the model.  The details are also so numerous as to be mind-numbing. The document Ian points to has what I think may help on page 286.  It is a kind of flow diagram for each type of cycle, breaking down the alternative paths and register transfers with coarse and relative timing for each major-cycle type.  Each different model will have a diagram like this, with minor variations.

[Mike Katz]

I was thinking the PDP-8/I because that is what we are talking about.

It would be an academic interest so see how the Straight-8, 8/I, 8/E and 8/A all handle it differently.

As mentioned in an earlier message how a non-microcoded machine handles the combined instructions is beyond my ken.

The state diagrams and tables they much have had at DEC must have been wall sized.

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/c2eab6ae-3012-457d-9782-a234564ade35n%40googlegroups.com.

[Vincent Slyngstad]

On 2/8/2024 2:44 PM, Mike Katz wrote:

> I was thinking the PDP-8/I because that is what we are talking about.

OK, the comparable diagram can be found on page 9 of this PDF:
http://bitsavers.org/pdf/dec/pdp8/pdp8i/PDP-8I_RevCY_Engineering_Drawings_Dec71.pdf

For ISZ I 10, then:

FETCH T1: PC <= MA +1 Meanwhile, memory is reading
FETCH T2: MB <= MEM Remember core contents in MB
FETCH T2: IR <= MEM Remember some of it in IR as well
FETCH T3: Not an OPR, IOT, or JMP, just write MB
FETCH T4: MA[5:11] <= MEM[5:11] Forming effective address for next read
FETCH T4: MA[0:4] <= 0 Page zero reference doesn't copy from MA
FETCH T4: D <= 1 Set up DEFER
DEFER T1: Rest a moment so read can happen
DEFER T2: MB <= MEM+1 Autoindex
DEFER T3: Rest a moment, allows write of MB
DEFER T4: MA <= MEM+1 Do the indirection
DEFER T4: E <= 1 Set up EXECUTE
EXEC T1: Rest a moment for read
EXEC T2: MB <= MEM+1 Form new memory value in MB
EXEC T2: SKIP <= CARRY If addition carried, set SKIP
EXEC T3: ISZ just writes new MB
EXEC T4: MA <= PC+1 SKIP
EXEC T4: F <= 1 Set up for next FETCH

Note that I have assumed no DMA (Data Break) or Interrupt are requested. Hopefully I've got the clear and correct rationale for each step.

Vince

[Mike Katz]

Vince,

Wow, thank you.  I cannot imagine how to do that in gates.

Thanks,

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/774a53c7-87c2-415b-aeae-94419ba723e8n%40googlegroups.com.

[Vincent Slyngstad]

Well, have a look at the M220 module, which is where a lot of it is done
in the 8/I. Basically, it consists of a couple of large and-or-invert
trees which select two operands, which are fed to an arithmetic unit
(adder, as far as we care here), and the output can be latched into AC,
PC, MA, MB, etc. Each module implements a two bit slice with carry-in
and carry-out. This is the register transfer engine.

The rest is basically a big state machine to enable the inputs and latch
the outputs at the right moments, per the diagram we've been talking about.

Vince

[Digby R.S. Tarvin]

I would go for maximum accuracy, but equally happy with it being made the standard  configuration, or just an option.

At some point I would love to find time to interface an FPGA version to the PiDP panel. There seem to be implementations out there:

https://hackaday.io/project/179357-pdp-8-fpga

Probably a lot easier than trying it with the PDP-10

Regards,

Digby

On Tue, 2 May 2023 at 04:21, Steve Tockey <steve...@gmail.com> wrote:

All,

In about November/December of 2021 I published a version of the PiDP-8/I emulator that makes the Sing Step switch on the front panel work the same as on a real -8, namely it executes a single CPU cycle (Fetch, Defer, Execute) then stops. You can read all about it here:

https://groups.google.com/g/pidp-8/c/EdqMPILxRnM/m/Kb7ycuI5AwAJ

The reason for this post is to ask if anyone else is interested in having this version become part of the standard PiDP-8/I software distribution?

A direct consequence of this change is that Oscar's front panel functions of Mount USB Media, Restart SIMH, and Reboot the Pi got re-mapped into different front panel switch sequences. So from a PiDP-8/I end user perspective, it probably boils down to a question of preferring the existing Mount USB/Restart/Reboot key sequences at the expense of no cycle-realistic emulation vs. cycle-realistic emulation but at the expense of having to learn different switch sequences for Mount USB/Restart/Reboot behavior.

I see a couple of possible responses:

1) No, I'm happy with the current behavior and I am not interested in any other behavior.

2) I would be ok with making it available to others to use as some kind of selectable option but I am not interested in using it myself.

3) I would be interested in using it myself, but I think others will still want the current behavior.

4) I think this version should become the "standard" behavior for the PiDP-8/I.

Cheers,

-- steve

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/70f77115-ffde-4a47-8002-552992bc3c7en%40googlegroups.com.

[folke...@gmail.com]

At some point I would love to find time to interface an FPGA version to the PiDP panel. There seem to be implementations out there:

The project I linked above *is* an FPGA implementation that connects directly to the PiDP-8 panel. And I implemented it from the actual schematics and CPU blueprints, so it's not an emulation or simulation but rather an implementation of the hardware, I believe it can't get more accurate than that. The version I linked above (pdp8.app) is just an in-browser emulation of the VHDL model, but of course it also exists for FPGA boards: https://github.com/fpw/SoCDP8 with the CPU code being here https://github.com/fpw/SoCDP8/tree/master/src/fpga/rtl/cpu

It runs on SoC boards that also integrate an ARM CPU. That way, the FPGA can be controlled via browser; when using it, the interface of your PiDP-8 will become the same as on the pdp8.app page, i.e. you can graphically change the CPU configuration, select peripherals and mount disk images etc.

A handful of people on this list are using it for their PiDP-8. If you want to try it, I suggest getting the Pynq2 board instaed of the Zynqberry as the latter isn't supported by latest Vivado tools anymore.

Since these boards are more expensive than Raspberrys, I'm now working on porting the software implementation of the schematics to the Raspberry so that we have a cycle-correct alternative to the default PiDP-8 image. It's already running and working correctly, I just need to connect the console to it (which is already working in the FPGA version).

 

[Glenn Babecki]

Folke,

Like most of the people on this forum group, I was "raised" on DEC PDP computers.  My first encounter was with a PDP-8 (straight 8) at a local computer club for high school students in my senior year.  Because I was into electronics, I managed to repair a teletype interface card after which I gained some notoriety; however, that's another story and a long, long time ago.

I was intrigued by your posts on this thread regarding your FPGA implementation of the PiDP-8/I.  There are some FPGA implementations for Oscar's PiDP-11/70, but I haven't seen a faithfully complete version for the 8/I as yours, plus it interfaces to the PiDP-8 panel.  This brings me to my questions regarding your FPGA implementation.  I visited your GitHub site and was looking for a bit more documentation (diagrams, prose, etc.) that might illustrate how some of the suggested FPGA boards actually interface to the PiDP-8 panel.  I suppose the FPGA constraint files contain the GPIO signal assignments, but I was hoping to find something more readily accessible to get started.  I am currently thinking of using a Pynq2 board as you suggested, but any additional thoughts or specifications of other viable FPGA boards would be appreciated.  I suppose some general specifications like number of Logic Elements, number GPIO ports, amount of memory, and so on would be useful to evaluate other potential boards.  I know you qualified the ZynqBerry, Pynq2, and DEC-Nano-SoC and I would stick with the Pynq2 because I'm somewhat embedded with Xilinx tools.

Additionally, it would also be useful if there was some documentation on how to pull the source and build files together to construct the FPGA image.  I know there is some software for the embedded CPU applications and of course the VHDL source forms the 8/I logic, but some guidelines for organizing the build would be helpful.

Any additional information you can provide would be deeply appreciated.

Regards,

Glenn Babecki

[Glenn Babecki]

Folke,

I just wanted to post an addendum to my inquiry because I think I answered my question regarding the FPGA-to-PiDP8 connections.  It seems in my hasty search on the project GitHub repository, I neglected to do the obvious thing and look at the Pynq-Z2 documentation.  I didn't have to go deep into the literature to find that the Pynq-Z2 sports a Raspberry Pi I/O connector; hence a simple ribbon cable between the Pynq board and the PiDP8 would suffice.  I think this was a case of the old acronym "RTFM" coming back to bite me.  ;-)

That said, I still would like to get a little more how-to documentation for setting up the project to build the FPGA image.  I have been dabbling with FPGA development, but I am not quite adept enough to be comfortable setting up a project from a pile of files.

Thanks,

Glenn

[Randy Merkel]

Latest status on this effort? No hurry, just still interested.

Thanks,

-- Ra ndy

[folke...@gmail.com]

Latest status on this effort? No hurry, just still interested.

If you were addressing my efforts: The Pynq-Z2 build has been ready since 2020, it can be downloaded here: https://folko.solhost.org/socdp8/

Creating an SD card from the .wic file using dd or any other tool that can write images to SD cards is enough to get a running system, it should work out of the box on a Pynq-Z2 board.

These days, I'm working on an integrated assembler so that programs can be assembled and loaded right in the web frontend. A little demo is available on the browser-based simulation on https://pdp8.app
The third menu icon on the left brings up an assembly editor, the code can be assembled and loaded into the machine.

It requires some more tweaks like saving the assembly text when switching back to the machine, but the core assembler is done. After I'm happy with the integration, I'll work on the final step of getting everything into a package for the Raspberry Pi that can be installed as an alternative to the current SIMH-based distribution. Then the same browser frontend can be used for all my variants: A pure browser-based version where the PDP-8 runs in the browser, the FPGA / SoC variant with the Pynq-Z2 and the upcoming Raspberry Pi version.

[William Cattey]

I have come out of my PiDP-8/i slumber, and am interested in moving forward on updates/improvements to the PiDP8i system.

Apologies for having been away so long.

I see that there was a branch on tangentsoft that had the cycle-accurate emulator checked in.  Apparently the last work on that branch was December 2021, when Warren corrected a bug.

I see that, some time ago, Steve answered my question, "What performance hit?" with a back-of-the-envelope average guestimate of roughly half as fast (180 SIMH cycles for what would have been 100 SIMH cycles.)  The major impact of this will be on the build process where we construct the virtual rk05 and tu56 images.  Even so, I think the primary purpose of the PiDP-8/i is to give a good simulation.  Half as fast, but the lights doing what they're supposed to seems like a perfectly sensible tradeoff to me.

The cost of offering both options is conditionalizing all of Steve's re-arrangements of code, or having two versions of PDP-8: cycle accurate, and instruction accurate. To be honest, computers are STILL getting faster, so I personally think "twice as fast" isn't worth the cost of maintaining two code lines. Therefore, unless significant issues arise, I'm putting my effort into an investigation of converting to the cycle-accurate emulation.

That brings up several follow-on questions to make it real:

1. What is the state of Open SIMH?  At VCF East, Oscar said to me that the rift was healed and we don't have to go to a different SIMH. Can someone point me to relevant discussions to verify that we should consider proper upstream going forward?

2. Steve, Has there been further evolution of your code?  Have you made any outreach to whatever is upstream SIMH, investigating them taking your changes?

3. What do we have as validation to confirm that, if we adopt Steve's new emulation that it properly implements the instruction set at least as well as the instruction-accurate emulation we've used up to now?

4. While we are opening up the SIMH PDP-8 emulation, what is the status of Vince's PDP-8 set-cpu work?

Let's wake this up and move it forward!

-Bill Cattey

[Vincent Slyngstad]

1. I don't know if the rift is healed so much as people have tired of repeating themselves. I'd definitely prefer that things be based on the open-simh project. My understanding is that (since open-simh is open) code moves freely from open-simh to simh, but not so much in the other direction, except when Mark is willing to also commit changes to the former . (That is, simh/simh isn't "free" in the sense that would allow you or I to do that.) To be clear, I try to follow the discussion for both, but have never actually contributed to either.

4. My code is in the SVN at https://svn.so-much-stuff.com/svn/trunk/pdp8/simh, for what it is worth. Much of the CPU-specific model dependencies are there, and the model switching seems to work fine. A number of models pass their respective diagnostics. The parts that are definitely not done are the harder I/O devices for the PDP-12 (LINCtape or analog stuff), or much of anything about DECmates. At one point I tried to rebase to newer code (from open-simh, of course) and resume development, but there have since then been changes by others that haven't been included in my code yet.

Vince

[William Cattey]

Hi Vince!  Nice to hear from you!

After my posting, I did some research into the state of open-simh vs. simh.  I would characterize them as, "open-simh established explicit governance", and "simh harvests what open-simh publishes."

Governance in Open Source matters.  I prefer the stuff I work on to interface to other projects with explicit governance whose principles I agree with, rather than ad-hoc governance that can change suddenly or create problems.  (Ask me about the shift from IBM AFS to Open AFS some time, over Adult Beverages.)

So, putting another stake in the ground with regards to Q1: I think we have an answer: Functionally they seem to be equivalent, but open-simh has a better governance structure and is to be preferred going forward.

You say your mods, for a number of models "pass their respective diagnostics."  I was thinking that the os8-progtest framework ( https://tangentsoft.com/pidp8i/file?name=doc/os8-progtest.md&ci=tip ) might be a useful way to automate running basic maindec programs to confirm goodness.

How did you do your testing?  Did you have to connect the virtual paper tape reader to some of your .pb maindecs one at time?

It seems like the steps forward would be:

1. Clone the current open-simh into a branch, integrate that into our current trunk, and confirm that it works.  (Warren wrote a script that does a lot of the heavy lifting here.)
   
2. Take the fully working subset of your set-cpu stuff, integrate it, updating as necessary, test it, and do a pull request on open-simh to add it.

In addition to the cycle-accurate stuff, there are two things I've been working on:

1. Changes to the integration of the pidp8i hardware support so that, on platforms that aren't going to get the hardware it quits including it, and thereby quits running a bunch of gpio code that limps along until it finally fails and THEN marks the run-time as not having the hardware.
2. Integrating gpio support that works on current and future pi hardware.  (Although CHANGELOG.md says Pi 4 support was added, apparently Pi 5 support is problematic.  Oscar provided a new gpio layer based on pinctrl, and I've got it half working.  If it passes muster, I want to pull this in.)

At the present moment, it's unclear what order my two tasks and the set-cpu tasks should hit trunk.

As big a task as it seems to be, I wonder if integrating open-simh into trunk first might be best, since otherwise we have to re-do all the other integration to the new baseline, some of which we see does need updating.

-Bill

[folke...@gmail.com]

3. What do we have as validation to confirm that, if we adopt Steve's new emulation that it properly implements the instruction set at least as well as the instruction-accurate emulation we've used up to now?

I ran into that question as well when creating my FPGA implementation for the PiDP-8. For verification purposes, I transcribed the entire original schematics into a digital logic simulator. That allows for easy testing of certain edge cases, front panel behavior, etc.

The project for the digital simulator is shared here: https://github.com/fpw/antares-pdp-8i

Hope it helps!

 

[Vincent Slyngstad]

> How did you do your testing?  Did you have to connect the virtual paper tape reader to some of your .pb maindecs one at time?

SIMH has an existing regression test suite, with some diagnostics in it. I took PDP8/tests and added diagnostics and infrastructure to test various models.  Essentially it runs the "acceptance tests" that DEC would have run for each model.  Mostly each test is "loaded" from the -pb/.bin and run with the correct model settings and such. Existing SIMH mechanisms (some are not well documented, or at least were unknown to me) are used to check that the output is as required.

Vince

[Steve Tockey]

All,

First, regarding performance hit, I don't know if the cut in half statement is that accurate after all. When I ran the original version on a Pi 3B+ throttled to 416K IPS (expected to be the speed of a real -8/e) the Pi CPU monitor showed between 8% and 12% load IIRC. When I first ran the cycle realistic version it was showing 10% to 14% load. However, for the last year or more the cycle-realistic version seems to be averaging the same 8% to 12% CPU load as the original version. I guess the most fair test would be to benchmark both versions un-throttled, but as Bill said, given that computers keep getting faster ("Thank you, Gordon Moore"--smile) maybe performance is a non-issue anyway. Both versions un-throttled run substantially faster than real DEC hardware, and both run comfortably with lots of spare Pi CPU capacity when throttled realistically on a "mid-range" Pi.

Second, would someone without a PiDP-8/I really even be interested in a cycle-realistic version? I did it because I wanted all the switches and lights to behave as real as possible. But someone without switches and lights seems unlikely to care? Now, having said that, could the cycle-realistic version just be treated as a "different model of CPU" for code base purposes?

Finally, as far as diagnostics go and whether we should trust the cycle-realistic code, it has successfully passed all of the MAINDECs that I could get my hands on. And in one respect, it did expose a defect in the core SIMH PDP-8 code with getting TSS-8 to run under it (I'm pretty sure that's why Warren submitted that change in December, 2021). It's maybe not a fair claim, necessarily, but I have been using the cycle realistic version exclusively since it's been available for several hours each week and I've never noticed so much as even a hiccup.

-- steve

[timr...@gmail.com]

I'd prefer the cycle realistic as I do run it on my PiDP-8.  And I run TSS/8 as that's this is the type of machine I learned computers on (TSS/8 running on an 8i).

[William Cattey]

Well Steve,   It's your code.  How hard is it to make it switchable?

[Steve Tockey]

Bill,

That will depend entirely on the strategy used for the other switchable options. Is it done now with #define and #ifdef's sprinkled through the code base? If so, that might be tricky. On the other hand, if it involves different build scripts then it could be fairly trivial.

Is it safe to assume that the code base you are referring to is not the one in Fossil? Would it be a separate code base in GitHub? Please point me at the code base which has the version you want cycle realistic merged into and I'll let you know how difficult it would likely be.

Thanks,

-- steve

[William Cattey]

I have not read Vince's cpu-set code yet, but I suspect we might be able to do something what that framework.

[Mike Katz]

Though a compile time option for cycle accurate simulation does solve the problem.  That requires keeping two separate builds or at least binaries and the associated complications of dealing with two different setups.

As I see the following options
1.  Compile time option
2.  Command line option
3.  Configuration file option
4.  SiMH shell command

#'s 2, 3 & 4 can all be in the same binary because all they have to do is set a flag.  I feel that this is the best because offers the most flexibility of switching between cycle accurate and full speed.

I don't know how the internal simulation engine in SiMH works but considering how simple the PDP-8 instruction set is, there are a very small number of different cycle possibilities.  There could be a table with the timings (in units of 125nS or something like that) for each instruction type and each of the different possible PDP-8's (straight 8, 8/S, 8/I, 8/L, 8/E, 8/A, 6100, 6120, etc.).  I don't know how many different possible timings there are but I doubt there are more than 50 different combinations (direct, page 0, auto increment, indirect, combined instructions, etc.) so the table would be less then 1 or 2 K.  This doesn't count I/O instructions or Data Break.

One question to ask is "Do you want cycle accurate simulation for instruction timing or for accurate simulation speed?"   All of the CPU simulators I've used in the past were only concerned with counting cycles so that the user would then know how much time something took.  In my experience this was used for either code optimization or for deterministic code, when things had to happen in a specific amount of time.

Creating an accurate simulation speed is just a matter of subtracting the emulation time from the actual instruction time and inserting the appropriate delays. 

On the PDP-8 cycle accurate simulation can be taken a step further and emulate each CPU cycle accurately, rather than just each instruction.  The PDP-8 CPU Instructions are made up of one or more of three cycle type (Fetch, Execute and Defer).  As was pointed out here, earlier in this thread, different instructions use different cycles.

Bill, Steve, et al.  As a software development manager I would ask the following questions:

1.  What is the objective (Instruction timing, true sub-instruction cycle timing or real time simulation)?
2.  What is the easiest way to integrate this into the existing code with a minimum of potential impact on the code?
3.  How can we add these changes so that they don't break any existing installations that are upgraded to this new version?
4.  What are the projected specific difficulties (I/O, Interrupts & data break are the ones that I see).
5.  What changes to the build and test scripts will need to be done?

I don't know if this helps to clarify anything but here is my two cents.

             Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/383a534d-2c34-485a-af9d-31c5c3edcb0en%40googlegroups.com.

[thunt...@gmail.com]

Mike,

the idea of this cycle realistic implementation is to make the PiDP-8/i behave like a real PDP-8/i in the context of single stepping. The original code was a simple instruction level emulation.

Tom

[Mike Katz]

Tom,

Are you looking for real world accuracy at the single instruction or single step (cycle) level? 
Are you working on actual real world timing based on the T1 thru T4 timing cycles? 
What is your base unit of time? 
What about write after read for Core?
What about interrupt handling?  On the 8/E the interrupt is held off until the initiation of the next Fetch cycle.  I presume the 8/I is the same.
What about Data Break (single and three cycle)?
What about I/O.  Each device controller responds differently with different timings?
What about front panel delays (run to halt, run to single step, run to single instruction, actual single step and single instruction, deposit, examine, etc).  All of these have timings from the time the button is pressed until the hardware reacts.
Have you thought of expanding the cycle accuracy to total bus timing accuracy?  This could be made as a simulated bus trace.

I'm sure you have thought of all of this.  I'm just curious how you want to do it?,

Thank you,

    Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/570d6e53-2697-4282-97cb-8af0360ee1b9n%40googlegroups.com.

[thunt...@gmail.com]

Mike,

What is desirable is during single stepping instructions or steps that the PiDP-8/i looks and feels like a real PDP-8/i. No need for real word accuracy/timing/delays/etc.

Importantly the work has already been done, the question is if/how to integrate it into the mainstream SIMH/OpenSIMH.

Tom

[Mike Katz]

Tom,

Sorry to be asking so many questions.

Does making the changes noticeably affect the execution speed of the simulation?
Is there a reason not to include it in the main line code and have a conditional based on a flag that can be set (via command line parameter, config file parameter or shell command)?
What are the risks of breaking something with the new additional feature?

I'm sorry I drop into software development manager mode too easily sometimes i guess.

Please let me know if I can help in any way.

Thank you,
 
             Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/1699402c-5198-4733-b5d6-bd8dccaeb6a0n%40googlegroups.com.

[William Cattey]

The deltas for the  initial proof-of-concept that wasn't merged into trunk can be found here:

https://tangentsoft.com/pidp8i/info/f5d7f8b691de068a

That code line assumed a change from instruction-accurate to cycle-accurate behavior, with the goal of making the pidp8 blinking lights for the major states be accurate in "single step mode".  The changes are spread throughout the simh code base.  To make this code a run time selection would probably require significant refactoring.

[Steve Tockey]

Mike,

As Tom stated, yes, the entire purpose of "cycle realistic" was to merely to emulate the PDP-8 at the Fetch-Defer-Execute instruction step (Major State) level rather than at the complete instruction level. There was nothing beyond that. No desire to manifest TP1-TP4, TS1-TS4, etc. because those are deep hardware level and not visible at the front panel. The PiDP-8/I has the Sing Step switch on the front panel and it seemed a shame to me for it to be nonfunctional. I did it purely to make the Sing Step switch behave the same as on a real -8. What can I say? I'm fascinated by blinkenlights and this made for more, and more interesting, blinkenlights. The original thread discussing the cycle realistic version is here, you can read that whole background if you haven't already:

https://groups.google.com/g/pidp-8/c/EdqMPILxRnM

I've also been kicking around the idea of tweaking the SIMH RK05 code to have it flash the front panel Break light. If someone could describe how the Word Count and Current Address lights flash during RK05 disk access I might try to make them blink realistically as well.

This had nothing to do with realism in timing, although having implemented emulation at the machine cycle level it could be a foundation for someone making that happen if they wanted to.

"Does making the changes noticeably affect the execution speed of the simulation?"

The only definitive performance measure I have is running Oscar's version against the cycle realistic version (both with ILS, https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Simulator) on a Pi 3B+ with SIMH throttled to 416K instructions per second. Both versions show around 8-12% average CPU load in the RPi desktop widget. So there appears to be no major performance hit. A more accurate test would be to run both completely unthrottled and see how long they take to complete the same benchmark tasks (e.g., I have an OS/8 Fortran 4 version of Whetstone for one example).

"Is there a reason not to include it in the main line code and have a conditional based on a flag that can be set (via command line parameter, config file parameter or shell command)?"

Sorry to be wishy-washy here but that's probably the most important question. While a total of 5 files are affected by the change, the most significant is in pdp8_cpu.c. If you look at the original version the main part of the emulation is one big loop containing at the top level a switch-case where the cases are the instruction op code (bits 0-2). Each of these cases runs through the entire instruction emulation for that op code. In the cycle realistic version, there is an outer switch-case with cases for Fetch, Defer, and Execute. Within each of those cases are inner switch-cases for the relevant op codes in that major state (i.e., all op codes are relevant in the Fetch major state, op codes 0-5 are relevant in the Execute major state and only op codes 0-3 are relevant in the Defer major state.

While 99% of the lines of code are the same between the original and the cycle realistic version they are organized completely differently. You can think of a matrix of emulation code with the op codes as the columns and the major states as the rows. Each cell in that matrix would hold the emulation code for that op code in that major state (if any). The original code is organized by column, i.e., take all of the emulation code for each op code and append it in one place). The cycle realistic version is primarily organized by row--by major state.

There are on the order of 1600-1700 total lines of code (including a lot of comments) in both versions of pdp8_cpu.c. The main loop in the cycle realistic version is about 868 lines. If you really, really wanted to have both versions sit side by side then it might make sense to factor out that main loop code and have two ~870 LOC functions called from pdp8_cpu.c based on whether or not they wanted the original or the cycle realistic version. it would not make any sense at all to have both versions of that main loop in pdp8_cpu.c as this would make it on the order of 2500 LOC where realistically 2 of every 3 lines of code is duplicated somewhere else in the same file. It would also add yet another decision to the emulation loop, slowing it down even more (although whether or not that would be perceptible remains to be seen).

"What are the risks of breaking something with the new additional feature?"

I don't see any, myself. But others might have different opinions on that. As I said, the cycle realistic version passes all relevant MAINDEC diagnostics (see the list in that other thread) and from a simple operational reliability perspective I have never seen nor heard of any undesirable behavior at all. I would welcome others banging on the cycle realistic version to see if they can find any problems with it.

So on thinking about all of this while writing this response, it might be argued that there are only reasons for keeping two versions

1) potential defects in the cycle realistic version vs. the original

2) possibly significant performance differences between the two

If the cycle realistic version were as trustable as the original version and any performance difference were negligible then wouldn't it make more sense to just abandon instruction level simulation and use the cycle realistic version alone? If that's the case then

A) who are the "right people" who would ultimately make the decision on which way to go?

B) what would it take to convince those "right people" that cycle realistic is as reliable as the original version (beyond passing MAINDECs and not crashing in years of operation)?

C) what kinds of benchmarks would need to be done to get an suitably accurate measure of performance between the two versions?

For C) I think we would need to consider, for example, low end hardware like a Pi Zero (which I don't have, and don't appear to be beefy enough to even run ILS)

 

Let me know what all y'all think,

-- steve

[William Cattey]

Hi Steve,

Let me try and provide insight into you A, B, C questions:

A. "The right people" should be upstream open-simh.  I say open-simh rather than simh, because the governance structure is clearer.

B. On the Contacts page, https://opensimh.org/contacts/ it says: under "Code Contributions":

If you have code that you’d like to contribute, fork the appropriate repository, make your changes, and submit a pull request. Discussion will be in the pull request.

If you would like to discuss a potential contribution before it’s coded (which is wise for larger efforts), please open a GitHub issue.

There are guidlines for acceptance at https://opensimh.org/contributions/ but one sticking point may be that a primary principle they follow is, "Preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation." (Bold emphasis mine.)

I think it's worth making a pull request to do this and see what conversations happen around it.  I think being able to say, "We've benchmarked this, and it's not a significant degradation in performance, and allows hardware simulators like the PiDP-8/i to give a more faithful rendition of operation."  If our contribution is reasonably complete, has value, and shows no significant downsides, it might be accepted upstream.

C. Amenable to further discussion.  Perhaps experience with operation on our PiDP-8/i hardware, and maindec output reports will be good enough.

For the PiDP-8/i, indeed we should find someone with a Pi Zero to try it out, and see if it's acceptable.

-Bill

[Steve Tockey]

Bill,

Thanks for the reply.

FWIW, I would interpret their principle of

"Preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not cycle-accurate, simulation."

to mean that they don't require cycle-accuracy. I am inclined to interpret it as,

"Preserve the ability to run old/historically significant software. This means functionally accurate, sometimes bug-compatible, but not necessarily cycle-accurate, simulation" (bold emphasis mine).

I mean, if it happens to be cycle-accurate and still complies all of their other principles, why would they say no?

Do you think it would be better for you to propose it given that you're the authority for the PiDP-8/I software?

And regarding Pi Zero, I think they are cheap enough that I could easily buy one for experimentation purposes. I'm sure I could find something else to do with it when I'm done.

-- steve

[William Cattey]

Another loosely related question:

Why did we cut into pdp8_cpu.c and scp.c instead of using the front panel interface that comes with SIMH?

-Bill

[William Cattey]

Status report:

I've merged the latest upstream Open SIMH into Trunk.  It runs fine on my Mac and Pi3b PiDP-8/i system.

Other people should update to it and also test.

Meanwhile Heinz-Berndt Eggenstein provided the key insight into getting pidp8i-test working with the new pinctrl stuff.  Theres a bit of sanity checking, but that should be getting published to the pi5 branch very soon.  Looks like it should slide right into trunk now without problems.

-Bill

[Mike Katz]

Bill,

Thank you for your work.

Please let me know if I can help.

          Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/34a22e98-f763-4bc9-a47e-f5dfae0d456cn%40googlegroups.com.

[William Cattey]

Hi Mike,

Heinz-Berndt has noticed that the new pinctrl stuff sends the load on his Pi2b to 150% with OS/8 just idling.  This performance impact was not on my radar and is concerning.

Heinz-Berndt suggested that the performance impact might be because in-line bit-banger macros were replaced with procedure calls.

I've just checked the fix for scanswitch and pidp8i-test into the pi5 tree.

The most helpful thing now is for others to test on other platforms, and for us to address this performance hit.  I don't want to drop Pi Zero support. I want the universal support to work reasonably well on old and new platforms.

-Bill

[Mike Katz]

Bill,

Today I have to do yard work (that damn grass just keeps growing and the weeds just won't listen to reason).

My Pi 5b is on loan to my son but I can check out the PI 2b, Pi 3b and Pi 4b later this week.  I will have to try and find my PI Zero's.

I have an extra PiDP-8/I, maybe this is a good time to put it together so I don't have to take apart the one that is nicely sealed in a case already.

I will keep in touch.

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/d71db596-2578-4f95-8971-34c93d8d36f3n%40googlegroups.com.

[William Cattey]

Hi Mike,

Re: priorities: Alas, home comes before play.  I totally get that.  The benefit of a bit of delay is that it gave me a chance to pull Open SIMH into the pi5 branch from trunk, and to fix the two mistakes I made with that merge.

Open SIMH is now established as the baseline going forward.

I think the performance fix-up for the pinctrl support should proceed in parallel with the next steps in cycle-accurate and cpu-set functionality.

Ideally we'd get pinctrl sped up and into trunk first, because Oscar says there are buyers of his PiDP-8/i hardware today who want the Pi 5 inside, but who can't really get it.

-Bil

[William Cattey]

And a bit more investigation leads me to believe the pinctrl performance isn't as bad as I feared.

I chose to gather my own performance measurements on my Pi3b system:

In one terminal window I started pidp8i-sim, booted into OS/8 and let it go idle. In another window I ran top.

Sure enough, the pidp8i-sim job said it wanted 141% of the CPU, within striking distance of what Heinz-Berndt reported (which was 150%).

But going to the old pidp8i-sim from trunk, the job reported 138% CPU.

I think what really may be happening is that the Incandescent Light Simulator may be being the hog.

[William Cattey]

I conclude it's not pinctrl that's the cpu hog.

I just build pidp8i-sim with nls instead of ils.

top said that the process took 100% CPU with nls and pinctrl, or 101% of the cpu with nls and the current gpio interface.

[Heinz-Bernd Eggenstein]

Ah I see... so  (depending on throttling, see below) the actual sim takes one full core all the time. And the NLS and ILS take almost nothing and about a third of a core, respectively, on older PIs. And yes, it's already documented :-) https://tangentsoft.com/pidp8i/doc/trunk/README-throttle.md

Cheers

HB

[William Cattey]

I've skimmed the deltas from Vince to add SET MODEL to SIMH to select members of the PDP-8 Family.

I've also skimmed the deltas from Steve Tockey to change the PDP8 emulation to more cycle accurate.

There seems to be no advantage to integrating one or the other first.  The SET MODEL framework is super simple to follow if cycle-accurate behavior was to be a run-time option, but doesn't require any of Vince's code to do it that way.

By way of starting off a series of conversations with the Open SIMH community, I've opened an issue seeking interest in adopting what I described as, "Our prototype to support other members of the Family of 8."  I'm pretty sure they'll consider this a no-brainer and give it a green light subject to integration review.

I figured the cycle-accurate code, though of greater interest to the PiDP-8/i community than "Family of 8", was a harder sell on initial contact.  I'm using the "Family of 8" proposal as a way to test the waters for a proposal to add "Fetch/Defer/Execute" sub-cycles within instruction-level emulation.  I.E. I wouldn't describe it as cycle-accurate necessarily because they say up front they don't seek cycle-accurate emulation.  But maybe we can get it adopted as an enhancement that offers some greater fidelity at modest performance cost.

Steve, I hope you find the approach I'm planning to take reasonable.

-Bill

[William Cattey]

I forgot to provide the link to the issue I opened:  https://github.com/open-simh/simh/issues/377

[Steve Tockey]

Bill,

Apologies for my late reply. Your approach sounds perfectly reasonable.

Thanks,

-- steve

[Mike Katz]

Bill,

The Pi Zero 2 is a Pi Zero with the Pi 3B CPU on it but only 512K of RAM.  And the Pi Zero 2W adds the Bluetooth/WiFi chip.

       Mike

On 5/17/2024 5:54 PM, Bill Cattey wrote:

Hi Mike,

I don't know the difference between a Pi-Zero and a Pi-Zero 2.  Is one faster or slower than the other? 
Are there I/O differerences?
The project has always provided the caveats about limited ability to test owing to limited ownership of hardware.

I'd say climb aboard the tangentsoft train, install fossil on your Pi-Zero 2 system, and pull in the build tree.
See: https://tangentsoft.com/pidp8i/wiki?name=Home
Follow the building from source instructions at: https://tangentsoft.com/pidp8i/doc/trunk/README.md

All:

I will note in passing that my Mac and Raspberry Pi 3 Model B Rev 1.2 have just finished building and testing an integration of the latest Open SIMH into the tangentsoft build tree as a simh4 branch.  So now it's just a matter of pulling it into trunk. (I'm going to double check our procedure docs to see if there's any more due diligence I need to do first.)

-Bill

Mike Katz wrote on 5/17/24 5:23 PM:

Bill,

Very good points.  Can it be a Pi-Zero 2 or does it have to be a Pi Zero.  All of my old Pi-Zeros have been replaced by Pi Zero 2's.

If there are no real adverse effects except for running 450 times faster than a PDP-8/I rather than 500 times faster than a PDP-8/I then I would say upstream should like it.

I gave up on the NON opensimh when simh would not compile on after an OS update.

I like your idea of not duplicating the code but still offering the old style and the new style, just in case there turns out to be some kind of backward compatibility issue.

         Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/29310062-8697-4f69-bcb9-08546c924e47n%40googlegroups.com.

[Mike Katz]

Bill,

Very good points.  Can it be a Pi-Zero 2 or does it have to be a Pi Zero.  All of my old Pi-Zeros have been replaced by Pi Zero 2's.

If there are no real adverse effects except for running 450 times faster than a PDP-8/I rather than 500 times faster than a PDP-8/I then I would say upstream should like it.

I gave up on the NON opensimh when simh would not compile on after an OS update.

I like your idea of not duplicating the code but still offering the old style and the new style, just in case there turns out to be some kind of backward compatibility issue.

         Mike

On 5/17/2024 2:39 PM, William Cattey wrote:

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/29310062-8697-4f69-bcb9-08546c924e47n%40googlegroups.com.

[Bill Cattey]

Hi Mike,

I don't know the difference between a Pi-Zero and a Pi-Zero 2.  Is one faster or slower than the other? 
Are there I/O differerences?
The project has always provided the caveats about limited ability to test owing to limited ownership of hardware.

I'd say climb aboard the tangentsoft train, install fossil on your Pi-Zero 2 system, and pull in the build tree.
See: https://tangentsoft.com/pidp8i/wiki?name=Home
Follow the building from source instructions at: https://tangentsoft.com/pidp8i/doc/trunk/README.md

All:

I will note in passing that my Mac and Raspberry Pi 3 Model B Rev 1.2 have just finished building and testing an integration of the latest Open SIMH into the tangentsoft build tree as a simh4 branch.  So now it's just a matter of pulling it into trunk. (I'm going to double check our procedure docs to see if there's any more due diligence I need to do first.)

-Bill

Mike Katz wrote on 5/17/24 5:23 PM:

Bill,

[Steve Tockey]

All,

I got my Pi Zero W yesterday and installed the stock version of PiDP-8/i SIMH using Bullseye as the OS. The Pi Zero W is single core with 512K ram. I intentionally got the smallest, weakest Pi I could in order to benchmark the bottom end of the performance curve. I got some initial data yesterday and will re-verify it today. I will also try to add in the cycle-realistic numbers. Then I will circle back and do the same under Bookworm. 

Data coming soon . . .

-- steve

[Mike Katz]

Steve,

What are you using for your timing tests.  I will duplicate them on the
systems that I have, this week.

Thanks,

          Mike

[Steve Tockey]

(Re-posting here as my initial was a reply only to Mike)

Mike,

For CPU load numbers I have a second PiOS command line window open and I'm looking at whatever TOP is reporting for either total CPU load or PiDP8i-specific load as appropriate. For run time performance tests I have a couple of very compute-heavy custom applications (a Solitaire card game simulator in Pascal and some matrix algebra in Algol using EAE). I'm measuring run-time as best I can using the stopwatch app on my cell phone--it won't be perfect but will be within a second or two for 40 sec to 120 sec run times. I also have a Fortran 4 version of Whetstone that I could run but haven't yet. Were you interested in running my compute-heavy applications, or do you have your own?

-- steve

[William Cattey]

This is exciting!

Remember to update to the latest trunk that has Open SIMH.

Do please also try the same tests with the pi5 branch, so we can review the impact of the pinctrl griot interface.

-Bill

On May 23, 2024, at 12:47 PM, Steve Tockey <steve...@gmail.com> wrote:

(Re-posting here as my initial was a reply only to Mike)

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/7M1XMbchbfs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e46ca2f1-3b98-48d7-a6db-9dc1a5879689n%40googlegroups.com.

[Mike Katz]

Steve my goal is to duplicate what you and Bill (and anyone else) are doing so we have relatable results on all Pi's tested.   That way we can compare SiMH version as well as Pi OS versions and PI hardware versions, etc.

If we are not all using the same tests then the results won't correlate.

I don't know how different PDP-8 programs execute differently within SiMH;.  But if we were to run some kind of combination CPU MAINDEC that tests all of the instructions repeatedly and then measure the Pi overhead, that might be one common way to benchmark how much Pi CPU is being used.

This could be done with Incandescent Lamp Emulation turned on and then turned off.

Do we need an actual PDP-8 CPU benchmark as well.  I would think that cycles per second that SiMH gives us would be all we need there.  Unless the performance falls below 1:1 with an actual PDP-8.

I think any one of us could whip up a quick instruction exerciser that executes most of the instructions in a small loop.  With only 6 Memory Reference Instructions and 5 possible addressing modes (page zero, current page, indirect page 0, indirect current page and indirect page zero auto index) and a complete set of combined micro-instructions.

There are 511 possible combined micro-instructions, some of them are illegal and others don't make sense (like HALT).   I would think for these we only need to worst case combination since we are not exercising the CPU but rather measuring the simulator performance.

Let me know what you guys think.

         Thanks,

                   Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e46ca2f1-3b98-48d7-a6db-9dc1a5879689n%40googlegroups.com.

[Steve Tockey]

Mike,

I don't see the need to benchmark at that low of a level.

First, the timings of the AND, TAD, ISZ, and DCA instructions in real hardware are all invariant across identical addressing modes (direct, indirect, auto increment) because they are determined by memory read-write times. Differences in current page vs. zero page and auto index vs. not are all buried inside TS1 .. TS4 logic. For example, AND with a current page address and DCA with a zero page address both take exactly the same time. Direct vs. Indirect addressing adds the DEFER major state independent of whether the instruction is AND, TAD, ISZ, or DCA. JMS and JMP are also invariant across identical addressing modes. The difference JMS and JMP have compared to AND, TAD, ISZ, and DCA is that JMS and JMP with direct addresses are single cycle (FETCH only) and with indirect addresses are two cycle (FETCH + EXECUTE). AND, TAD, ISZ, and DCA are two cycle (FETCH + EXECUTE) when direct and three cycle (FETCH + DEFER + EXECUTE) when indirect.

Second, knowing what I know about how pdp8_cpu.c (both regular and cycle-realistic) emulate PDP-8 instructions, the code that emulates all addressing modes for AND vs. the code that emulates all addressing modes for TAD, ISZ, and DCA is exactly the same except literally the one line of SIMH code that emulates that instruction's final behavior. Here's the snippet of code out of cycle-realistic for the final part of AND ... DCA emulation:

                if (IR & 00400)                             /* is AND .. DCA, direct or indirect */
                    MA = DF | (MA & 07777);                 /* indirect, use DF */
                else
                    MA = IF | (MA & 07777);                 /* direct, use IF */
                MB = M[MA];                                 /* get the data word */
                switch ((IR >> 9) & 07) {
                    case 0:                                 /* AND */
                        LAC = LAC & (MB | 010000);
                        break;
                    case 1:                                 /* TAD */
                        LAC = (LAC + MB) & 017777;
                        break;
                    case 2:                                 /* ISZ */
                        M[MA] = MB = (MB + 1) & 07777;
                        if (MB == 0)
                            PC = (PC + 1) & 07777;
                        break;
                    case 3:                                 /* DCA */
                        M[MA] = MB = LAC & 07777;
                        LAC = LAC & 010000;
                        break;
                    }  // end of switch ((IR >> 9) & 07)
                }

Whether you are emulating an AND vs. TAD vs. ISZ vs. DCA instruction in the same addressing mode, the difference comes down to literally a single line of SIMH code. 100% of the remainder of the lines of SIMH emulation code are the same.

So, IMHO, the important thing for benchmarking SIMH performance under different configurations of host OS, original vs. cycle-realistic, ILS vs. not, and so on really only depend on having it do the same amount of benchmark work, independent of what that work ends up being. And, this is even only relevant for the benchmarks when SIMH is unthrottled--i.e., the question is how long does it take to get that fixed amount of work done. Benchmarking when throttled, OTOH, is concerned with what % of the host CPU capacity is taken up under those conditions. As long as the unthrottled benchmark execution time is less than the throttled benchmark execution time then the host CPU has spare cycles so the benchmark execution time is 100% determined by throttle setting not by host CPU speed.

One quick data point is that for my Pi Zero W (single core) running Oscar's standard PiDP-8/I (non ILS) unthrottled it's on the order of 2x faster than when throttled to 416K IPS (pdp-8/e speed). As long as there is no ILS, Oscar's original PiDP-8/I has spare capacity over the fastest real -8 even with the weakest Pi host CPU. I will try benchmarking cycle-realistic this afternoon and report back.

-- steve

[Mike Katz]

Steve,

I was unaware how SiMH interpreted the instructions.  So any simple program such as an AC "incrementer" or my "cylon" AC shifter would also work.

I think for the most usable results I think we should all be doing the same thing.  As per your suggestion here is a list of all of the possible combinations/permutations of Pi, throttling and ILS.  We can have two copies of this table, one for the original and one for cycle accurate:

			Results (% Idle)
Pi Model	32 Bit/64 Bit OS	Pi RAM (MB)	No Throttling/No ILS	Throttling/No ILS	No Throttling/ILS	Throttling/ILS
Pi Zero W	32	512
Pi Zero 2 W	32	512
Pi Zero 2 W	64	512
Pi A	32	256
Pi A+	32	256
Pi A+	32	512
Pi B	32	256
Pi B	32	512
Pi B+	32	512
Pi 2B	32	1024
Pi 3A+	32	512
Pi 3A+	64	512
Pi 3A+	32	1024
Pi 3A+	64	1024
Pi 3B	32	1024
Pi 3B	64	1024
Pi 3B+	32	1024
Pi 3B+	64	1024
Pi 4B	32	1024
Pi 4B	64	1024
Pi 4B	32	2048
Pi 4B	64	2048
Pi 4B	32	4096
Pi 4B	64	4096
Pi 4B	64	8192
Pi 400	32	4096
Pi 400	64	4096
Pi 5	32	4096
Pi 5	64	4096
Pi 5	64	8192
Running 32 bit OS on 8GB units should yield the same result as if run on the 4GB units so they are not included in this table

I can forwared this table as a spread sheet or word doc if anyone wants.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/54d570d8-cddc-4148-9ea4-e6836091fff5n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

That looks like a massive effort..I'm not sure all of this is actually needed? E.g. why would anyone want to see what a PDP-8 would look like with realistic incandescent lamps simulated, but at an unrealistic super-high, unthrottled, instructions per seconds rate?

Also a word of caution:

I'm experimenting with a new ILS code variant (based on the "pI5" branch that also has the OpenSIMH code base, but not the cycle-accurate simulation, running on 32bit userland "Bookworm", so your values will vary). When benchmarking with a single core Pi Zero W throttled to 333k IPS, I noticed that it can happen that (e.g. when you (auto)start the simulation at a time when there's still CPU load from other activities at boot-time), SIMH will notice that the simulation runs *slower* than the requested throttle value. It will then unthrottle it... not what you want to measure. So I guess It's wise for all the throttled benchmarks to check the actual state of throttling after taking benchmark values by escaping back to the SIMH prompt (^E) and type

SHOW THROTTLE

You will get some output like this (here on a Pi Zero W) if the throttling is still active

sim> show throttle
Throttle:                      333 kiloinstructions
Throttling by sleeping for:    1 ms every 1269 instructions

or on a Pi 2B or faster PI something like:

sim> show throttle
Throttle:                      333 kiloinstructions
Throttling by sleeping for:    1 ms every 355 instructions

which will also tell you something about how SIMH is pushing the brakes to get to the desired execution speed.

Cheers

HB

[Mike Katz]

HB,

I agree.  We should add that all measurements should be done on a quiescent system running without a GUI.  Either console serial port or telnet port.  I understand that some people may want to run without networking and there for might see a slight decrease in overall Operating System overhead which can affect the results but that is a nit I don't care to pick🙂.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/949e09cf-3b9c-4e8c-bf20-167bac150been%40googlegroups.com.

[Steve Tockey]

HB,

I noticed a couple of examples of SIMH overriding throttle settings in the benchmarking work I've been doing. First, it does seem that SIMH will never silently change throttling (at least in my experience). It appears to only override a throttle setting when it thinks it is incapable of supporting that speed and will always then tell you that it is changing it before going back to emulating (i.e., after you SET THROTTLE X then type GO).

The other thing I noticed was a series of completely bogus SIMH throttle setting complaints when I asked for a setting and it said it was incapable of many times more than that. Something similar to this:

.^E

simh> set throttle 333k

simh> go

SIMH is not capable of supporting 333K instructions per second.

SIMH is only capable of supporting 2M instructions per second, throttling is disabled

.

I would even say something like this:

.^E

simh> set throttle 30k

simh> go

SIMH is not capable of supporting 30K instructions per second.

SIMH is only capable of supporting 2M instructions per second, throttling is disabled

.

This appears to be something in the *.script file that gets run when SIMH starts. The README.MD file on the Tangentsoft website (https://tangentsoft.com/pidp8i/doc/trunk/README.md) talks about a ./configure --throttle option,

"See README-throttle.md for the values this option takes. If you don't give this option, the simulator runs as fast as possible."

If you then re-do the ./configure with

PiOSprompt$ ./configure --throttle=pdp8i

 

It sets up the *.script files with different content so that changes to throttling are allowed. I need to do a detailed compare to see what's changed but the fix does seem to be to simply re-do the ./configure with the --throttle=CPUTYPE option as discussed on the Throttling page (https://tangentsoft.com/pidp8i/doc/trunk/README-throttle.md). As long as it allows one throttle setting then it will allow all other reasonable settings.

Cheers,

-- steve

[Heinz-Bernd Eggenstein]

Hi Steve!

Maybe I can help with benchmarking, I have a Pi Zero W, 2B, 3B, 4B ,5B  ...

> The other thing I noticed was a series of completely bogus SIMH throttle setting complaints when I asked for a setting and it said it was incapable of many times more than that. Something similar to this:

That sounds soooo familar: some time ago I had participated in a  discussion of a filed bug, upstream in SIMH because of this. The logic for this is in the generic part of SIMH that is independent of particular CPUs. I had even submitted a patch that was partially fixing this at least, but as I said this was upstream in SIMH and not in PiDP8i stuff specifically, and it was before the great fork to OpenSIMH happened, so it would be worthwhile to check whether that patch actually made it downstream to your current SIMH code. Let me lookup the issue .....

ah, here it is: my pull request
 https://github.com/simh/simh/pull/1086

 

and the issue this was mentioned in:

https://github.com/simh/simh/issues/815

The way I remember is that SIMH has two methods to probe the execution speed of the simulation: one is by executing a  short "benchmark" piece of code that is configurable per CPU, ideally this should be representative of the instructions-per-second performance. This first method is used to bootstrap the throttling mechanism. The second mechanism is used continuously to monitor executing speed and then fine-tune the throttling accordingly. If both methods give vastly different results, SIMH stumbles and produces very misleading diagnostic messages like the one you mentioned.

The setting that you mentioned in the boot script that makes a difference is probably the configurable delay that SIMH will wait before it starts said benchmark code evaluation. If there are other activities going on in parallel to the start of SIMH, it can lead to a slowing down at exactly the  time when the benchmark happens to be executed and it skews the results. Waiting a bit for the system to settle via the configured delay will then help.

As least that's my recollection of the whole affair...

Perhaps that helps. But I think it's also possible that the cycle-accurate code might change the way that "instructions" are counted and perhaps there is a real issue to be solved / accounting to be adjusted after all.

Cheers

HB

 

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2ff924dd-029c-4b2d-a098-f4d43628f0f9n%40googlegroups.com.

[Michael Thompson]

I have access to a PDP-8/I so I could run some baseline tests.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAOjdp-pE-A8Hd0EoQihGOCPHLHWznSYwM4uEek%2BW0_3J-%3Dji7A%40mail.gmail.com.

--

Michael Thompson

[Vincent Slyngstad]

On 5/27/2024 11:21 AM, Steve Tockey wrote:
> The other thing I noticed was a series of completely bogus SIMH throttle
> setting complaints when I asked for a setting and it said it was
> incapable of many times more than that. Something similar to this:
>
> .^E
>
> simh> set throttle 333k
> simh> go
> SIMH is not capable of supporting 333K instructions per second.
> SIMH is only capable of supporting 2M instructions per second,
> throttling is disabled

My relatively recent SIMH just omits that middle line, reporting only
that "throttling is disabled".

Vince

[Heinz-Bernd Eggenstein]

I think I know what's happening: If Steve is using the "cycle-realistic" branch in the fossil repo for tests, then indeed that branch does not include the code change I submitted to SIMH (which then got merged back into PiDP8i) to fix the weird SIMH throttling error message because it was branched off earlier. So this weird behavior will hopefully go away after merging in the (Open)SIMH code.

Cheers

HB

[William Cattey]

When did you last update your copy of the tangentsoft trunk?  I merged in Open SIMH last week.

-Bill

[Heinz-Bernd Eggenstein]

The trunk is up to date all right, but the "cycle-realistic" branch builds on an outdated SIMH from the time the cycle-realistic branch was started. 

After bringing the cycle-realistic code in sync with the recent (Open)SIMH code, some of the testing and benchmarking will have to be repeated, so maybe it would be wise to do the full scale testing and benchmarking only after that update.

HB   

[Bill Cattey]

The program tools/simh-update does a very good job of cloning upstream simh and merging in the PiDP8 changes.

It's a one-line change to make it fetch from Open SIMH:

    git clone https://github.com/simh/simh "$CURR_SIMH_DIR"

becomes:

    git clone https://github.com/open-simh/simh.git "$CURR_SIMH_DIR"

It didn't like merging in our license for the PiDP8 stuff, and that had to be done by hand.
At which point the update of SGID and SGTM needed to be done by hand:

In your build output look for a line of the form:
    Pulled XXX as curr, authored YYY; prev is ZZZ.
Then do this:
NEW_SGCID=XXX
NEW_SGCTM=YYY
sed -e "s/^SGCID=.*/SGCID=$NEW_SGCID/" \
    -e "s/^SGCTM=.*/SGCTM=$NEW_SGCTM/" \
    -i tmp @srcdir@/Makefile.in
touch src/SIMH/scp.c

and then rebuild:

make reconfig
tools/mmake


'Heinz-Bernd Eggenstein' via PiDP-8 wrote on 5/28/24 4:02 AM:

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/7M1XMbchbfs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/59b601e3-652b-4651-b05b-361d31b38d89n%40googlegroups.com.

[Warren Young]

On May 28, 2024, at 08:12, Bill Cattey <bill....@gmail.com> wrote:
>
> It didn't like merging in our license for the PiDP8 stuff, and that had to be done by hand.

…once only, so long as OpenSIMH doesn’t change their license comments again.

If that changes once a year due to a copyright year update, it might merge cleanly regardless, but if not, then it’s a one-line manual change.

> At which point the update of SGID and SGTM needed to be done by hand:

That shouldn’t be necessary again until/unless simh-update next fails.

[Steve Tockey]

HB,

I agree that final benchmarking needs to be done on fully up-to-date software. On the other hand, I will look a the time I spent benchmarking so far as an investment in determining whether or not it even made sense to proceed with merging the Cycle-realistic branch. Based on my tests (preliminaries discussed with some people off-line), here are the results I am seeing so far for various combinations of Pi Zero W and Pi 3B+ CPUs with Bookworm, Bullseye and Stretch:

*) In terms of increased CPU load when running throttled, Cycle-realistic adds 12% over the old Trunk version when everything else is in the same configuration (e.g., CPU, OS, old Trunk ILS vs. NLS).

*) In terms of increased CPU load when running throttled, old Trunk ILS adds 87% over old Trunk NLS when everything else is in the same configuration (e.g., CPU, OS, old Trunk vs, Cycle-realistic).

*) In terms of increased execution time when running unthrottled, Cycle-realistic adds 87% over the old Trunk version when everything else is in the same configuration (e.g., CPU, OS, old Trunk ILS vs. NLS). I am very confused by this result. I don't understand where the extra execution time is coming. When the increased CPU load is only 12% running throttled, I would have expected a similar order of 12% increase in unthrottled run time.

*) In terms of increased execution time when running unthrottled, Old Trunk ILS adds 18% over old Trunk NLS when everything else is in the same configuration (e.g., CPU, OS, old Trunk vs. Cycle-realistic). This makes sense because old Trunk ILS  runs in a separate core so the 18% overhead could be core switching overhead.

When considering Cycle-realistic on Pi Zero W alone, the CPU load overhead when throttled is about 18%. The increased run time when running unthrottled is about 63% I'm not entirely sure why it would run so much slower when unthrottled but it does. On the other hand, even slowed by 63% it is still many times faster than real hardware.

So at least I would conclude that even on the weakest available CPU the overhead of Cycle-realistic is not that unbearable that we should abandon the effort due to poor performance.

-- steve

[Mike Katz]

Steve, Bill, HB, et al.

Do we have a script or procedure we can use for the bench marking.  This is so we are all testing the same thing.

Some time back I wrote two scripts for OS/8 Serial Disk.  One script insured that all of the necessary prerequisites and source latest source code for building were installed and a second script to build SIMH, test it, build OS/8 Serial Disk and configure it.

Something like that, for this, would make it easier to test and make the tests and benchmarks consistent.

If you have a procedure with a list of prerequisites I am happy to write the script to check out, install and run the tests and even possibly email the results to someone to compile them.

                 Mike

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/d3cab523-c181-4124-9513-1cd5e55e407bn%40googlegroups.com.

[Steve Tockey]

Mike,

The simple answer is, "not yet". I think that eventually we will want to be sure we are getting consistent results with everyone using the same benchmark test configurations, but before that I do think it would be good for different people to approach the testing from different perspectives (i.e., running different benchmarks) to see if the results are compatible at that level. I mean, I am using a set of three different non-trivial programs:

1) A Pascal program that self-plays solitaire using randomly-generated decks of cards. This program is compute intensive at some points and slightly terminal I/O intensive at others.

2) An Algol program that does some heavy matrix algebra. I specifically chose this because I set up a version of Roger Abbott's PDP-8 Algol compiler so that it uses EAE (Mode A). I don't have a good sense of how long it takes for the EAE instructions to execute in real hardware so in SIMH mode they always execute as if they take a single memory cycle. I thought it would be good to have a data point that considered EAE heavy work. This code is very compute intensive most of the time.

3) A Pascal equivalent to the Algol matrix algebra that does the same job without using any EAE.

I run these three programs and measure peak CPU load during the compute-intensive sections at 416K IPS (the fastest real PDP-8 speed). I also measure time-to-complete for these same programs when running unthrottled.

I think it would be good for others to try different computing tasks and see if your results are generally similar to what I am seeing. I mean that if you are getting significantly different results using different benchmark programs (e.g., Fortran or Basic or something else) then we should first understand why different benchmark programs would be giving such different results. Once we are all in sych with general repeatability of any kind of benchmarking, then we can zero in on a specific set of actual benchmark programs for us to run.

It will be easy for me to set up a sample RK05 system disk with benchmarks on it when we've decided what they will be. I'm also happy to share the benchmark code I've been using so far.

-- steve

[Mike Katz]

Steve, Bill, HB, et al.

I have on order or already have in my lab the following Raspberry Pi's

Model      Speed  Cores  RAM
Zero W     1GHz    1    512MB
Zero 2W    1GHz    4    512MB
A+         1GHz    1    512BM
B+         1GHz    1    512MB
2B         900Mhz  4    1GB
3B+        1.4GHz  4    1GB
4B         1.5GHz  4    4GB
5          2.4GHz  4    8GB

If you guys an give me a procedure (I will write the script) or script to download, build and run some test and aquire the results I will run the tests on current head and cycle accurate branch.

Steve,  you commented on everyone running their own programs or tests.  It occurred to me that running almost anything that does not read/write to a peripheral will yield nearly identical results.

Once a peripheral is involved, things get complicated.  A serial I/O device will go though some kind of serial stream.  However, disk I/O will also involve the file system and reading/writing off of the SD-Card.  Currently my 4B and 5 are booting up from SSD and not the SD card.  This will most likely affect the benchmark if the PDP-8 program is doing some kind of mass storage I/O.

Without I/O will there be much difference in emulated instructions/second between a complicated focal program and a simple program that just executes each possible instruction path.

It is my understanding that TAD I DATA and AND I DATA will take the same amount of time in SIMH (assuming that the compiler optimized the switch/case statement into a jump table and not incremental comparisons).

As Steve pointed out, all we need is one of each type of SiMH interpreted instruction since SiMH does effectively the same thing, from a timing standpoint, for many different instructions.

Thanks,

            Mike