Two things happen before the time 8 state is displayed.
1) The clock event occurs and the instruction executes; the sequential logic updates.
2) The combinatorial logic updates.
Since the instruction is being set by the test script, it does not change so the ALU is still computing D-1. The ALU output, 11109, appears on outM.
When the CPU is tested in the Computer environment, when the combinatorial logic updates, because the pc changed, the next instruction is decoded and its ALU control bits cause the ALU to compute whatever your CPU decodes for @1000. (Mine sets all control signals to 0, computing D&A resulting in a rather strange value.)
There is no problem with the Hardware Simulator demonstrated here.
This is the same testing artifact already explained above. M=D-1 and M=D+1 do not show the artifact because they do not modify D. MD=D-1 and MD=D+1 show the artifact because they modify D and the ALU recomputes D-1 combinatorially.
I’m sorry, I don’t understand the term “testing artifact”; guess I’ve been on the wrong side of the office.
The book says: “The value computed by the comp part of the C-instruction can be stored in several destinations, as specified by the instruction’s 3-bit dest part (see figure 4.4).”–– page 66.
That gives me the impression that the same value computed is stored in all of the specified destinations.
If the “comp part of the C-instruction” is D-1, and the current value of D is 12345, is the computed value not 12344?
If the destination is M or MD, CPU Emulator stores 12344 in RAM, as described in the book.
If the destination is MD, why does Hardware Simulator not store 12344 in outM? Is it operating according to what the book says above?
What you say is correct and is what your CPU is doing. The same value is stored in all destination registers.
A testing artifact is something that happens in a test setup that is, or appears to be, at variance from the way a circuit works in its intended application. The "erroneous" value that you see on outM during the CPU.tst is caused by the script using "set" commands to apply instructions to the CPU since there is no ROM. There is no RAM so the value on outM is not stored anywhere.
When the ALU is used in Computer, with proper connections to ROM and RAM, incorrect values are not stored in RAM.
Also note the PC and ARegister display bug I described a couple posts ago. I expect it also affects the displayed DRegister value.