what is a nameless label and what is a temporary label as opposed to something like this:
Code:
someramval equ $01
...
...
lda someramval
cmp #01
bne someaddr
...
...
someadder: rts
i've heard these terms before but dont really know what type of label they are refering to. i assume that a nameless label is:
Code:
lda #0
ldx #$FF
@ sta $00,x
dex
bne @
rts
where the '@' would be the label. but as for temporary labels, my only guess would be one that has a limited scope?
In some assemblers, you can define local labels within a particular block of code (whether said block is a single procedure or a large number of them) to start with some special character like a period or underscore - this gives them actual names, but once you switch to a different code block, you can reuse them.
never-obsolete: Which assembler are you using?
CA65 has three kinds of local symbols:
- procedure level symbols, visible within a defined scope, described here;
- local symbols with the sigil @, visible only between one label and the next, described here; and
- unnamed labels, visible to the code immediately preceding or following the label, described here.
ok i get it. so if an opcode outside of a any code block references a label on the inside of a code block, it should generate an error. whereas if an opcode on the inside of a block references a label not in any code block(global varaible so to speak), it would be in its scope?
edit: not using any assembler, im writing my own. now that its reached bare-bones minimum, im adding common features to it and i ran across those terms.
Everything can see a global symbol.
I use WLADX and I use + and - for when I'm needing nameless lables. I wonder if I can use an @ symbol...
This varies from assembler to assembler. I remember NESasm having dots for locals symbols, wich can be used between each normal symbol.
WLA-DX has a better system (I find). It has sections (wich are code or data that will be assembled in one chunk, typically you have a set of procedures and tables per section), and inside them, you can put localy symbols, begining with underline. You can also use + and - for unnamed labels, wich is VERY usefull. + will refer to the next "+" symbol inside the section, and "-" to the previous. Also, you can use ++ so refer to the next "++" symbol, and -- to refer to the previous "--". You can do in theory align up to 8 + or -, but I'd never do that because the code will be confusing and unreadable. I never have more than 3 + or - at the same time. If I need more, I try to find names for normal labels.
Actually, I think I tried doing ++ and -- and it didn't work. Maybe I just did something weird. But you say that it would be confusing, and difficult to read if you had those lables going up to 8 characters. I can't see how that'd work. Do you think comments make it more understandable and easier to read? I actually have like 4 comments on my huge sidescroller code. I can't stand looking at comments. It looks SO ugly. Does anybody agree? I don't think so, but just checking.
Celius wrote:
Do you think comments make it more understandable and easier to read? I actually have like 4 comments on my huge sidescroller code. I can't stand looking at comments. It looks SO ugly. Does anybody agree? I don't think so, but just checking.
Comments above a subroutine should explain what the subroutine does, the preconditions (inputs), and the postconditions (outputs). Yes, comments in assembly language have to be written differently (try for 40 columns?) than comments in a higher-level language such as C++ because each line of code is so narrow.
I like comments in small quantity, either to explain pre-condition and post-condition parameters such as what tepples said, or either to explain maths when you're doing something ticky.
I hate comment heavy code where all comments are such about "load something in A, shift it right, etc..." because you can just read the code for the same result.
Fairly commented code is sometimes anoying to make, but after all you're happy to still have a trace of your work once you re-use your subroutine months later and don't remember exacly in what way you wrote it. Explain what it does and how it works make you gain a lot of time.
A lot of useful comments will show
why the code is doing something. The code shows what and how.
For some kind of made-up example, you can look at these 2 lines of code and they'll make sense without having to check the context it was used in.
Code:
bad:
CMP #$E8
BCS drop
ok:
CMP #floor
BCS drop
good:
CMP #floor ; don't fall through the floor
BCS drop