|15:56||• Closed ticket [f961906a5c]: HLT instructions are handled incorrectly plus 4 other changes artifact: 6719eb9432 user: tangent|
|15:52||Fixed a couple of problems in the way SING INST and CONT were handled. These are related because in the old way of doing things, these two switches had a kind of lock-step operation that tried to split instruction execution over two separate passes of the PDP-8 sim's CPU instruction decoding loop. Now these two switches are handled more or less the same way as all the others, in a single cycle of the instruction loop. With the prior scheme, while the processor was stopped with a HLT instruction, pressing CONT would basically jump 2 instructions forward, rather than continue to the instruction after the HLT, skipping it. This fix closes [f961906a5c]. While in there and reading the DEC documentation describing the proper operation of the switches, I found that we weren't handling SING_INST properly at all. When flipped with the processor in free-running mode, it is supposed to stop the processor just as if you'd pressed STOP. Now it does. (I could have checked this in separately, but the two fixes are in overlapping and interrelated sections of code, so it doesn't make sense to check in a purposely-written erroneous SING INST handler just to get a separate checkin comment.) check-in: 9a12773270 user: tangent tags: trunk|
|15:04||• Ticket [f961906a5c] HLT instructions are handled incorrectly status still Verified with 3 other changes artifact: 633f2e5361 user: tangent|
|15:03||A prior checkin accidentally changed the way HLT instructions are handled. It was an attempt to fix bug [f961906a5c] which wasn't intended to be checked in; the fix doesn't work, so it's now back to the way the code worked yesterday, which is still broken. check-in: 6155a4b535 user: tangent tags: trunk|
|04:21||• Verified ticket [f961906a5c]: HLT instructions are handled incorrectly plus 5 other changes artifact: ce4b44026f user: tangent|
|03:14||• New ticket [f961906a5c]. artifact: 1383b0d8a0 user: tangent|
|Title:||HLT instructions are handled incorrectly|
|Last Modified:||2017-01-21 15:56:43|
|Version Found In:||v20151215+|
tangent added on 2017-01-08 03:14:57:
Given the following test program:
1 0100 *100 / start addr 2 00100 7301 CLA CLL IAC / Link=AC=0, AC++. AC now 1 3 00101 7004 LOOP, RAL / rotate the bit left 4 00102 7402 HLT / wait for user 5 00103 5101 JMP LOOP / again 6 $
There are two related problems:
Running it normally, it hits the HLT instruction with AC=2, as expected. If you press START or CONT to get past the HLT instruction you see AC go to 0.
If you try to run it in SING INST mode to try and figure out what's going wrong, the PC sails straight through the JMP instruction. Since the next value past JMP is 0000, and that means AND AC with 0, that's probably how the AC is getting cleared. However, simply inserting an NOP after the HLT doesn't fix it. It sails through the JMP again and zeroes AC again.
Something about how the modified PiDP-8/I simulator is operating is breaking the JMP instruction handling after a HLT.
This program does work as expected in the stock SIMH pdp8 simulator as well as in Baehr's PDP-8/E Simulator. This problem affects all versions of the PiDP-8/I simulator tested: v20151215, v20161128, and v20170105.
tangent added on 2017-01-08 15:04:45:
I tried adding a "continue" statement on line 1209 of pdp8_cpu.c.in, but that doesn't fix it. (I thought maybe the problem was all the other code that runs after the swStop=1 line.) So, the problem is more complicated. Something about the way the simulator normally handles the "reason = STOP_HALT" case differs from the way we handle "swStop == 1".
tangent added on 2017-01-21 15:56:43:
Closed by [9a12773270]