This is probably one of the simplest questions ever asked here.... but I'm tired of coming up with unique labels every two minutes in my asm file just to skip over a line for some complex comparisons... so, can I branch over a single line or so? Something like:
Code:
lda #argument0
sec
sbc #$02
bmi #$01
jmp DeleteObject
(continue code)
If it's pertinent information, I'm just doing four checks to see if my 'bullet' object travels offscreen in any direction on this tick and jumping to the deletion code if it is.
It depends on the assembler you're using. I use ca65, and here's a quote from it's manual. Other assemblers will use different syntax for that.
http://www.cc65.org/doc/ca65-6.html#ss6.5Code:
If you really want to write messy code, there are also unnamed labels. These labels do not have a name (you guessed that already, didn't you?). A colon is used to mark the absence of the name.
Unnamed labels may be accessed by using the colon plus several minus or plus characters as a label designator. Using the '-' characters will create a back reference (use the n'th label backwards), using '+' will create a forward reference (use the n'th label in forward direction). An example will help to understand this:
: lda (ptr1),y ; #1
cmp (ptr2),y
bne :+ ; -> #2
tax
beq :+++ ; -> #4
iny
bne :- ; -> #1
inc ptr1+1
inc ptr2+1
bne :- ; -> #1
: bcs :+ ; #2 -> #3
ldx #$FF
rts
: ldx #$01 ; #3
: rts ; #4
As you can see from the example, unnamed labels will make even short sections of code hard to understand, because you have to count labels to find branch targets (this is the reason why I for my part do prefer the "cheap" local labels). Nevertheless, unnamed labels are convenient in some situations, so it's your decision.
Like Memblers said, anonymous labels are better, but yes, you can branch using immediate values. Your example code wouldn't work though, because you're branching 1 byte forward when the jmp DeleteObject instruction takes 3 bytes (1 for the JMP opcode + 2 for the destination address). As you can see, you need to know exactly how many bytes each instruction takes in order to do this, so I strongly recommend you use anonymous labels instead, which are less error-prone.
If the problem is coming up with label names, you could use the line # as the name like this... (boring label at line 123)
L123:
As you edit the code, this line # would be wrong, but don't worry about it. Giving a label a real name is, on the other hand, a good way to document your code.
6 months from now, when you look at the code, and you see JMP L123, are you going to scratch your head and think "what was L123 again?"
On using absolute values for branching...DON'T.
This forum is so great.
Okay, so that's good information. Pretty huge oversight on my part to make my code so hard to read. As it stands I WAY do not comment enough. Thanks again, guys.
When I get something that has a win state and a lose state I'll post the rom you all are helping me make.
Also check out ca65's "Cheap Local Labels", which allow reusing label names multiple times.
e.g.
Code:
lda #argument0
sec
sbc #$02
bmi @Else
jmp DeleteObject
@Else:
I use these for loops sometimes (@Loop)
Even for temporary labels, it's sometimes useful to give them a descriptive name. For a parser loop, "nextCommand", for a tile fill routine, "nextRow", "nextTile", for a collision detection routine that checks pairs of objects, "nextPair", etc.
Code:
bit currByte
bpl horizontal
; vertical code here
jmp horizontal_end
.horizontal
; horizontal code here
.horizontal_end
; more code here
jmp nextCommand
I do use unnamed labels a lot, but only for short branchs/jumps and when the instructions are self-explanatory. Cheap local labels on the other hand feel pretty useless to me, since all my functions are enclosed in their own scopes, so all labels are local anyway.
I have to admit that after having switched from ASM6 to ca65, I do miss temporary named labels... They begin with - or + (depending on where they're referenced from) and can be freely reused. Those are useful in functions that perform the same operation on multiple entities, where you can find blocks of code that are nearly identical. In ca65 I end up having to incorporate the names of the entities being manipulated into the labels to set them apart. In a function that manipulates coordinates, for example, I have to include "X" and "Y" in all labels in each block of code to make sure there are no duplicates.