Instruction MD=D-1 again

[gs99]

This was commented before, but I don’t understand the answer.
http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/Instruction-MD-D-1-td4025933.html#a4025961

In CPU.tst, when the @1001 occurs, D=11111.
The next instruction is MD=D-1.
Doesn’t that mean “Subtract 1 from D; store result in M and D”?

CPU spec: "OUT outM[16],        // M value output"

If I put these instructions in CPU.asm, and run in CPU Emulator, RAM 1001 is changed to 11110.

CPU.cmp calls for DRegister to be 11110 but outM to be 11109.
Why isn’t outM 11110?

[cadet1620]

gs99 wrote

In CPU.tst, when the @1001 occurs, D=11111.
The next instruction is MD=D-1.
Doesn’t that mean “Subtract 1 from D; store result in M and D”?

CPU spec: "OUT outM[16],        // M value output"

If I put these instructions in CPU.asm, and run in CPU Emulator, RAM 1001 is changed to 11110.

CPU.cmp calls for DRegister to be 11110 but outM to be 11109.
Why isn’t outM 11110?

This is an artifact of testing the CPU in isolation.

Time 7+ shows the state before the MD=D-1 instruction executes.

|time| inM  |  instruction   |reset| outM  |writeM |addre| pc  |DRegiste|
|7+  |     0|1110001110011000|  0  |  11110|   1   | 1001|    7|  11110 |

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.

|time| inM  |  instruction   |reset| outM  |writeM |addre| pc  |DRegiste|
|8   |     0|1110001110011000|  0  |  11109|   1   | 1001|    8|  11110 |

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.)

| time |PC[]|ARegister|DRegister|  outM   |RAM16K[1000]|RAM16K[1001]|
| 6+   |   7|    1001 |   11111 |     864 |    11111   |        0   |
| 7    |   7|    1001 |   11111 |   11110 |    11111   |        0   |
| 7+   |   8|    1001 |   11110 |   11110 |    11111   |    11110   |
| 8    |   8|    1001 |   11110 |     864 |    11111   |    11110   |
| 8+   |   9|    1000 |   11110 |     864 |    11111   |    11110   |
| 9    |   9|    1000 |   11110 |      -1 |    11111   |    11110   |

Why the PC is 1/2 clock out of sync is a mystery I still need to investigate!

[Two posts cross in the night. Your latest just came in while I was typing this. I had just finished the same experiment that you did.]

--Mark

[cadet1620]

Interesting... there is a clock phase error bug in the Hardware Simulator.

At times T_n+ the output from the HDL and the output from the built-in parts' test interfaces are different.

| time |PC[]| pc |ARegister|addressM |
| 0    |   0|   0|       0 |       0 |
| 0+   |   1|   0|   12345 |       0 |
| 1    |   1|   1|   12345 |   12345 |
| 1+   |   2|   1|   12345 |   12345 |
| 2    |   2|   2|   12345 |   12345 |
| 2+   |   3|   2|   23456 |   12345 |
| 3    |   3|   3|   23456 |   23456 |
| 3+   |   4|   3|   23456 |   23456 |
| 4    |   4|   4|   23456 |   23456 |
| 4+   |   5|   4|    1000 |   23456 |
| 5    |   5|   5|    1000 |    1000 |
| 5+   |   6|   5|    1000 |    1000 |
| 6    |   6|   6|    1000 |    1000 |
| 6+   |   7|   6|    1001 |    1000 |
| 7    |   7|   7|    1001 |    1001 |
| 7+   |   8|   7|    1001 |    1001 |
| 8    |   8|   8|    1001 |    1001 |
| 8+   |   9|   8|    1000 |    1001 |
| 9    |   9|   9|    1000 |    1000 |
| 9+   |  10|   9|    1000 |    1000 |
| 10   |  10|  10|    1000 |    1000 |
| 10+  |  11|  10|      11 |    1000 |
| 11   |  11|  11|      11 |      11 |
| 11+  |  11|  11|      11 |      11 |

The CPU.hdl used contains

ARegister(in=a-in, load=aLd, out=aReg, out[0..14]=addressM);
PC(in=aReg, reset=reset, inc=true, load=jmp, out[0..14]=pc);

--Mark

[gs99]

I did the following test that indicates a possible problem with dest M when included with D.

// M only
@12345
D=A                     // D=12345, outM=0
@1001                 // D=12345
M=D-1                // D=12345, outM=12344
@1001                // D=12345
M=D+1               // D=12345, outM=12346

// M & D
@12345
D=A                    // D=12345, outM=0
@1001                // D=12345
MD=D-1              // D=12344, outM=12343 (CPU Emulator RAM has 12344)
@1001                // D=12344
MD=D+1             // D=12345, outM=12346 (CPU Emulator RAM has 12345)

It appears that Hardware Simulator adds or subtracts 1 from D twice.  

[cadet1620]

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.

--Mark

[gs99]

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?

[cadet1620]

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.

--Mark