Chapter 4: Multiple Destinations

[faIan36]

In the symbolic language, figure 4.5 shows that the dest registers should be listed in the order A, D, then M. The Assembler expects A, M, D instead and will fail with "In line [line], Destination expected".

[faIan36]

By the way, I think it would be a good feature to allow all orders of destination letters. However, I'm not at that chapter yet so I don't know how hard it would be to implement.

[WBahn]

The original specification had an inconsistency in that the definition for the dest bits in a C-type instruction were ordered ADM, while the mnemonics for the assembly instructions were ordered AMD (see Fig 4.4 and Sec 6.2.2 of 1Ed). This was an annoying inconsistency in nomenclature, but not an actual error in semantics.

There is nothing that says that the letters in the mnemonic have to be in the same order as the bits in the generated machine code instruction -- it's merely convenient if they are. After all, a mnemonic is just a name and seven completely arbitrary names could have been chosen for the dest field. But, as I say, it IS convenient if the chosen names make sense and are consistent and coherent.

In the second edition, they addressed this within the constraint of not wanting to change the hardware, which means they changed the official mnemonics to match the ordering of the dest bits (see Figures 4.5 and 6.2 of 2Ed).  

If you write an assembler in strict compliance with 1Ed, it will require the order AMD.

If you write an assembler in strict compliance with 2Ed, it will require the order ADM.

I'm pretty sure (going from memory here) that the supplied assembler, even for 1Ed, recognizes all of the possible orderings, which allowed the authors to make this change without drawing a lot of attention to it.

If you are saying that the supplied assembler is requiring AMD and will not accept ADM, let me know and I will look into it further and get with the authors.

[WBahn]

faIan36 wrote

By the way, I think it would be a good feature to allow all orders of destination letters. However, I'm not at that chapter yet so I don't know how hard it would be to implement.

It's not hard to implement, but it is harder to implement than a strict implementation of the given mnemonics. Keep in mind that the complexity has been kept intentionally as low as possible and that many students taking this course have very limited programming experience (and that it is taught at the high school level in many places). Also, the course covers such a breadth of material, that the amount of time and effort spent on any one aspect is kept to a minimum so that they can do what is required and move on. You might have noticed that there was no requirement to build a 2-input Nor gate in Chapter 1, even though that is a very fundamental building block gate (in fact, the course could have been called Nor2Tetris). The reason is simply because the project doesn't actually need a 2-input Nor gate, so since it's not needed, it's not there.

The supplied tools are a bit schizophrenic when it comes to the mnemonics, and hence buy the worst of both worlds to some degree. By accepting multiple orderings of some mnemonics, it blurs the distinction of what a mnemonic is. For instance, the assembler accepts both A+D and D+A. This creates the impression that these are not mnemonics, but rather expressions that are being evaluated. But they aren't. In other instances, like D+1, the alternative 1+D is NOT accepted by the supplied tools.

Personally, I would argue that the supplied tools should be strictly-conforming to the language specification, that way if a student writes a strictly-conforming assembler, they will be able to correctly assemble any program that the supplied tools assembles. If the supplied assembler accepts programs with alternate orderings, then that student is faced with a situation in which there are programs that the supplied tools will assemble but that their assembler won't, and will likely jump to the conclusion that there is something wrong with their assembler.

[faIan36]

WBahn wrote

If you are saying that the supplied assembler is requiring AMD and will not accept ADM, let me know and I will look into it further and get with the authors.

The version of the tools that I downloaded a few days ago (I think it's version 2.5.7) will only accept AMD and otherwise fails with the error message given above. This is also true for two-letter combinations, where only AM/AD/MD are allowed.

[WBahn]

I've confirmed that the present tools don't accept the new specification. I'll pass that along to the authors.