is inM delayed?

Let's say we have a c-instruction ADM=D+A

Based on my understanding, in the tick phase the ALU computes D+A from the values emitted by the D and A registers, and then sends it back to D and A and also to M through outM. D and A don't immediately emit the new value (D+A)

Then in the tock phase, D and A emit the new value, however inM will be based on the old value of A (the old address, as opposed to address A+D). This is because A didn't immediately emit its new value. Thus the next instruction will have a stale value for M or inM

I believe this will make the CPU not work as intended

Consider this example. We start with mem[1] = 0, mem[2] = 7

@2
D = 1
A = D
AMD = M+D

Here, we expect A, M=mem[1] , D to be all be 1 at the end.

Let's assume the first two lines run as exepcted (so we know at this point that mem[1] = 0, mem[2] = 7, D = 1, A = 2) and let's start at the third line. During tick, the ALU computes D=1 and sends it to A. In this stage, A is emitting addressM=2 to memory. During tock, A emits the new value 1, while memory emits inM=mem[2]=7 because in the tick phase it received the old value addressM=2. Thus, M+D would equal 8, instead of 1.

For the duration of any instruction, M will always refer to the same memory location (what A pointed to at the start of the instruction). If an instruction updates A, then at the start of the next instruction the contents of memory address (A) are in M.

You can test the behavior with code like this:

    @1
    MD = 0
    D = A
    AMD = D+A

At the end of this sequence, 2 will be stored into A, D, and MEM[1] (because A was 1 at the start of the last instruction).

Or to put it another way, A only gets updated at the very end of the tock, after everything else gets done.

PS: The current assembler is picky about the order in which destination operands are specified. AMD works, but other variants like the ADM you use above will generate an assembly error. Only the destination operand variants listed in lecture 6 will be accepted.