Kx10: idle when UUO handler is 0.

[larsbrinkhoff]

As explained in the comment.

A particular use case I have in mind is the auxiliary PDP-6. For the master PDP-10 to be able to load and start programs, the PDP-6 is started running. The PDP-10 will then clear the PDP-6, eventually causing the PDP-6 to execute a 0 instruction. This will cause the UUO handler to be called. Since location 41 is 0, it will then loop around. Next the PDP-10 can write a program to PDP-6 core and finally write the start instruction to location 41.

[rcornwell]

This will not work. UUO 0 is a valid "invalid" instruction. I am not sure it will be possible to get good display results with DPY and idle support. Since the display needs to be constantly refreshed.

[larsbrinkhoff]

So what do you mean happens when UUO 0 is executed?

[rcornwell]

Yes... UUO 0 is a valid instruction. It causes a MUUO trap.

[larsbrinkhoff]

And a MUUO trap executes the instruction at location 41. What if that location is UUO 0? It goes back to 41 again. And again and again. This is the situation I want to capture.

[larsbrinkhoff]

I got the user mode flag wrong. I though the AOJA idle loop ran in exec mode. Does TOPS-10 and WAITS idle in user mode too?

[rcornwell]

Null jobs typically ran in user mode.

Location 41 should never be zero. This would hang the machine.

When a UUO is executed the Instruction is saved in location 40 and the instruction at 41 is executed.

The better method to fix the problem is to either shut the DPY down when it is not being used, or to have it detect a blank page and not schedule anything for some time.

[larsbrinkhoff]

ITS does write zero to PDP-6 location 41. Can you please explain why you don't want to handle this case?

Again, this issue has nothing to do about the DPY device.

[larsbrinkhoff]

Maybe I should explain in more detail.

When ITS (running on a PDP-10) wants to load a program into the auxiliary PDP-6, it first does a "reset" on the PDP-6. The ITS code is at PDPRST in SYSTEM; ITSDEV >

What is does is first to clear all PDP-6 memory locations from 20 to 16K. If the PDP-6 was running, this will cause it to execute 0 as an instruction. Since 0 is an MUUO, it will execute location 41. Location 41 will also contain 0. Thus the PDP-6 will, sooner or later, end up spinning on location 41.

Next, ITS will copy some code to PDP-6 core location 20:

20/   CONO PI,11577   ;CLEAR PI
21/   CONO 655550     ;CLEAR PROCESSOR
22/   DATAO 20,.+1    ;RELEASE DEVICES
23/   SETZ            ;CLEAR 0, ALSO BIT FOR DEASSIGNMENT (^)
24/   HRRZI 1,1       ;BLT POINTER 0,,1
25/   BLT 1,41        ;CLEAR AC'S, SELF, AND 41

Then, ITS will write JRST 20 to PDP-6 location 41. This will cause the PDP-6 to jump to the code at location 20. As you can see, it will reset the PDP-6 PI and APR, release devices on the shared I/O bus, and clear accumulators and core up to and including location 41.

[larsbrinkhoff]

So what I'd like to do with this pull request, is to have the auxiliary PDP-6 start running from ITS' "./start" script. I want to avoid the pdp6 simulator to consume a lost of host CPU when it's not doing anything. So I'd like it to trigger SIMH idling when the spin-41 situation happens.

I also want this to work when the PDP-6 is already running a random program. In which case clearing core will not make the PDP-6 jump to location 0.

[rcornwell]

Try this:

/* Check if possible idle loop */ if (sim_idle_enab && ((FLAGS & USER) != 0 && PC < 020 && AB < 020 && (IR & 0760) == 0340)) || (uuo_cycle && (IR & 0740) == 0 && AB == 041)) { sim_idle (TMR_RTC, FALSE); }

I have not tested this, but this should detect a UUO in 041 during execution of a UUO. This will effectively hang the CPU until an interrupt occurs.

[larsbrinkhoff]

Thanks. I just looked at the CPU internals and discovered the uuo_cycle stuff. AB seems to be set to 0 at this point. I'll step around in the simulator and see which of the internal registers is 41.

[rcornwell]

The instruction will be fetched from 041 (which will be AB or IA) during a UUO cycle. Any instruction in the range 0-37 in location 041 will loop. On the KI things are a bit more complex because 40-100 will be MUUO's which will be vectored the EB/UB 420+x. Note it really does not matter what PC is in this case since this will be a LUUO which will vector through 40/41.

[larsbrinkhoff]

AB is set from MB & RMASK on line 2740. IA still holds 41.

[rcornwell]

I try to avoid messing with UUO code since breaking it cause no end of trouble!

IA is used in one or two places. It is the address the last instruction was fetched from.

[larsbrinkhoff]

It works your code above when AB is replaced by IA. Note that it takes around 10 seconds for SIMH to enter idle mode. Some calibration or something, I recall.

So, I'll get the TOPS-10 stuff and test that. And rebuild ITS.

[rcornwell]

Ok... it takes some time for iDLE to kick in. However once working, it response pretty quick.

[larsbrinkhoff]

Full ITS build is OK.

Downloading TOPS 5.03 and 6.03 for testing.

[larsbrinkhoff]

• [x] ITS
• [x] TOPS-10 5.03
• [x] TOPS-10 6.03

[rcornwell]

If this change is working on the PDP6 (I don't have test cases yet). I will commit my change tonight. The code will be similar to above but AB replaced with IA.

[larsbrinkhoff]

It does idle on the pdp6. My testing is just go 0 and watch the process in top.

I'm running your TOPS-10 scripts now.

[larsbrinkhoff]

If you don't want to merge this pull request, please use the commit for reference to ensure all details are right.

[larsbrinkhoff]

Zzzz.... this is taking forever.

[larsbrinkhoff]

5.03 and the first 6.03 KA10+RP10 passed.

[rcornwell]

Merged.

[larsbrinkhoff]

All builds passed.

[larsbrinkhoff]

I get this warning with clang:

PDP10/kx10_cpu.c:2799:23: warning: '&&' within '||' [-Wlogical-op-parentheses]
    if (sim_idle_enab &&
        ~~~~~~~~~~~~~~^~

[rcornwell]

Ok... fixed the error. Thanks