Jump directive expected error - mult.asm

[bizobo]

I'm trying to write the mult.asm file symbolically (not in binary) and I keep getting a "jump directive expected error."

It happens at the following line of code:

D=D*M

That line of code appears just after I have stored R0 to D (my first move) and then called @R1 (with the hopes of multiplying R0 and R1).

I don't know what is going on! Any help appreciated, thanks.

[cadet1620]

D=D*M is not a legal command; there is no multiplication operation built in to the Hack computer.

For Mult.asm you need to implement a simple multiplication algorithm using repeated addition.

--Mark

[bizobo]

Awesome, thanks so much Mark. Now I get an error saying "Destination expected"

It happens after the line

Times=M

This is the first time I've invoked "Times" which I would like to be its own variable. I'm trying to set it equal to M, and M should be the contents of R0 (I just called @R0).

Again, no idea what this means :(

[cadet1620]

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

--Mark

[bizobo]

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

[bizobo]

Also helpful would have been a glossary of compiler error messages and what their likely causes are!

[cadet1620]

See my about me post.

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.

--Mark

[bizobo]

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!

[cadet1620]

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!

--Mark

[bizobo]

Mark, thanks so much for your help. I have a working mult.hack file, now on to Fill!