Reread about C-Instructions. The only legal destinations are A, D and M.
Times is a memory variable, so the only way to access it is by loading its address into the A Register using
and then storing the result of a C-Instruction into it:
M=D // Set Times to D
for example, or using it an operand in a C-Instruction:
D=D+M // Set D = D+Times
for example. You can also use M as a destination and an operand in the same C-Instruction:
M=M+1 // Increment Times
(R0 is also a memory variable, so the only way to set Times to R0 is to load R0 into D and store D into Times.)
Awesome, thanks so much Mark I appreciate it. Out of curiosity, how long have you been teaching this course, and in what context do you teach? At a college? Your advice is always spot on so I'm curious as to what kind of students you have.
Now that you phrase it that way I see what you mean. When I read (and re-read) the C-Instructions section (4.2.3) on my own I did not notice that A, D, and M are the *only* acceptable destinations. In fact, none of the language in that section claims that. The language is precise in saying that A, D, and M are acceptable, and that the destination bits code for them explicitly, but it leaves it to the reader to make the logical jump that because the only specification of the destination bits involves setting combinations of A, D, and M that storing to other registers directly is impossible.
A section that explicitly dealt with how to use user-defined variables was necessary and an oversight, in my opinion. It appears as though this, and other less-than-clear explanations, are likely the result of testing the book on computer science students instead of on students from other, unrelated disciplines. Hard to know how much explanation to give and how much is overkill. Overall, still an invaluable book, but greatly aided by these forums! I would go so far as to say the book would be unusable without these forums or a friendly computer scientist for those who are not in the field or a related one...
This book/course was definitely designed for Computer Science students at university level. It expects the reader to be able to learn and understand some fairly complex ideas from textual descriptions only.
There is a bit of a sequence issue with chapters 4 and 5. Chapter 4 teaches the assembly language view of the Hack computer so that the student will understand the design and be able to implement the the computer in chapter 5. Chapter 4, however, requires a basic understanding of the computer architecture to be able to write the programs.
A simplified diagram showing the overall architecture at the beginning of 4.2 would be particularly useful for visual learners. In particular, it should show the A and D Registers in the CPU and the Virtual Registers in the RAM. Also helpful would be some diagrams showing data flow in C-instructions to accompany the descriptive text on how M works.
Poor documentation for development tools is an industry wide problem. Most vendors rely on user support forums.
Very cool, thanks for the background and info. I had no idea about "CADET," what an interesting name!
I agree. At times also the text is just frustratingly sparse, at least for someone who is not a computer scientist (I studied filmmaking and philosophy). A slightly fatter mode of writing would have been appreciated for those in other fields.
Understanding that the audience is university students in computer science definitely clears that up, thanks!
Please feel free to ask questions by direct email, too, if you don't think they are appropriate for the forum. I'm happy to give explicit help to self-learners working their way through the course. I'm particularly impressed by people like you from outside the technical fields who are tackling this!