Doubt about static

Whenever we are handling a static variable, I am entering it as a variable in the symbol table with '@filename_index' command. I have written my assembler code such that it would enter all the labels in the symbol table and allocate each label with corresponding next line number with it next it would enter all the new variables it sees after @ symbol and for each label assigns an address which starts from 16, also if in my program there is a variable other than static variable then that would also be in the symbol table with an address associated with it.

My question is that the labels occur at various line numbers which can range from 0 to more than 239, in our assembly program and each label must be assigned an line number to which the control should jump if it is been called elsewhere in the program also we are assigning each variable with an address in ascending order starting from 16, therefore there is a chance that a variable and label may get same address, so in this case what should be done so that they don't overlap.

should I write my assembler code such that at first all line numbers are assigned to each label and then when assigning address to the variables I should assign it to hem such that it is not same as the line number of some other label and if it is same increment the address and check again and so on...

//Example:
(Label 1)
@sum
@i
.
.
.
Here in this program (Label 1) is assigned address 17 and variable sum is assigned address 16 but variable i is assigned address 17 which is same as address of (Label 1)

[WBahn]

It's a non-issue. A variable named "Variable_Bob" that is assigned to address 16 is referring to RAM[16] where data is stored. A label named "Instruction_Bob" that is assigned to address 16 is referring to ROM[16] where program instructions are stored. To completely different things. Just like someone with phone number 123-4567 in one area code is completely unrelated to the same phone number in a different area code.

This is why your assembler makes two passes. The first identifies all of the labels and records them along with the ROM address associated with them. The second pass knows that anything else must be a variable and assigns it to a RAM address starting at RAM[16].

Ok then, suppose I  have assigned address to all variables and labels, but now in the symbol table, every variable and label look same(I mean, once the address is assigned, you cannot tell which one is variable and which one is a label!) at least for my assembler code. If so then should I write my assembler such that it can differentiate between variable and label or is it fine if it doesn't?

[WBahn]

There are some advantages to keeping them separate, such as being able to print out a more meaningful symbol table if you want, but that isn't necessary.

Once a number is associated with a name all the assembler has to do is replace the name with that number in A-type instructions.

Consider the following:

@18
D=D+A
@18
D=D+M
@18
D;JGT

The most likely meaning of those three A-type instructions is very different. In the first one, 18 is just a value being added to the current contents of D. In the second, 18 is a RAM address where a value is stored that is being added to the current contents of D. In the third, 18 is a ROM address where execution will jump to if the current value of D is strictly positive.

But this code would be identical to

@18
D=D+A
@my_varname
D=D+M
@MY_GOTO_LABEL
D;JGT

if the pseudo-instruction

(MY_GOTO_LABEL)

were located above the instruction that will get stored in ROM[18] and if @my_varname was the third variable name encountered by the assembler on its second pass.

Both would be in the symbol table and both would be associated with the value 18. So what. When the assembler comes across either, it looks in the symbol table for that name and replaces it with the associated value.

Yes, that does mean that you could swap them, or use one of them for all three A-type instructions, including the literal constant 18 in the first line, and you will generate the exact same code. That would not be very smart from a code readability or maintainability standpoint, but it would still produce the exact same code.

Thank you so much for your explanation and I guess I need not change my code!