Direct address reference and symbol mapping

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Direct address reference and symbol mapping

Bill Thackston
I've been working on the Hack Assembler and learning a new language at the same time, so it's taking a bit longer than I'd hoped.  I've also read the chapter very carefully and I noticed one aspect of the memory assignment that seems to have been overlooked.

The project instructions suggest that user defined symbols other than labels can be assigned to register addresses incrementing from 16.  However, it is still allowable for the coder to use a direct address such as @16, in which case there would be a conflict.  So shouldn't there also be a check for numerical register assignments above 15?
Reply | Threaded
Open this post in threaded view
|

Re: Direct address reference and symbol mapping

cadet1620
Administrator
There is nothing that the assembler can do to warn about this because there is no way to know how you are going to use the value of an @ command.  For example:
// j = i+16
@i
D=M
@16
D=D+A
@j
M=D
If 'i' happens to be the first allocated RAM variable, the first two @ instructions in the snippet are identical machine instructions, both loading 16 into the A register.

It's also quite possible that a ROM label will have the same value as a numeric constant.

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Direct address reference and symbol mapping

Bill Thackston
I understand that using @xxx to enter a number or as a ROM label won't conflict with an address assigned to a user symbol by the assembler.  However, as you show in the example below, the coder would probably expect that address 16 and symbol i would have different A and M values.

So if I understand you correctly, good coding practice would be to avoid using both direct register addressing and user symbols in the same program.  

I'm attempting to add another layer of checking during the second pass.  So in your example, "@16" would be identified and the first user symbol i would be assigned to 17, and so on.
Reply | Threaded
Open this post in threaded view
|

Re: Direct address reference and symbol mapping

cadet1620
Administrator
Bill Thackston wrote
So if I understand you correctly, good coding practice would be to avoid using both direct register addressing and user symbols in the same program.
Yes it is good practice not to mix RAM variables and absolute RAM addressing, but there are many cases when you need to do so. For example to address memory-mapped resources like the Screen and Keyboard, and to address objects that have been assigned a fixed location in memory.

The Hack assembler provides built-in symbols for the Screen and Keyboard, but has no facility to define new symbols for fixed resources. An example of such a resource is the heap which resides from 2048-16383 (dynamically allocated memory for the Jack OS--chapter 12) . A more comprehensive assembler would allow a way to set such symbols.

Assemblers are not generally intended for people to write large programs; they are a way to get exact sequences of machine instructions when you need to deal directly with the computer hardware or achieve specific goals like highest possible execution speed or fixed code execution time.
I'm attempting to add another layer of checking during the second pass. So in your example, "@16" would be identified and the first user symbol i would be assigned to 17, and so on.
When you get to writing your Jack compiler you will find that the direct RAM that the assembler can use via named variables is limited to 16-255, so it is a precious resource. You don't want to throw any of it away because there is an direct numeric reference to it. (There wil be lots of these because all characters in string constants will appear as their numeric code in an '@' statement.)

--Mark
Reply | Threaded
Open this post in threaded view
|

Re: Direct address reference and symbol mapping

Bill Thackston
Mark,

Thanks for the additional insight.  I finished the assembler this morning (with the conflict checking) and as you would expect, failed the comparison test for Pong.asm.  I wrote a replacement method for my SymbolTable class with a simple increment from 16, and it matched on the first run.

I'm pretty fired up to be finally working my way through this course, after starting and stopping a couple of times over the past three years.  I started over again about three weeks ago, and I'm finding it to be a genuinely rewarding intellectual pursuit.

--Bill