It is currently Sun Oct 22, 2017 6:01 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu May 05, 2016 3:41 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1405
rainwarrior wrote:
My : usage is similar to how I would use C's { and } with control structures.

Only in C you cannot jump from one } back to a { that it doesn't belong to. Unlike unnamed labels, they always come in pairs.

rainwarrior wrote:
One thing you might not know is that ca65 will generate an error if there is no reference to an unnamed label. This catches a lot of the potential errors when making code revisions around these things.

I pretty much assumed that the compiler will catch a jump to an unnamed label that doesn't exist (i.e. using :+++ even though there are only two : after it). I mean, what else should the compiler do but give an error? I was exclusively talking about situations where the code is still syntactically correct.

rainwarrior wrote:
Yes, there are always potential errors, but I think I've only had to debug an erroneous : maybe 2 times in the past year, whereas I think the assembler has caught unreferenced unnamed label errors maybe 10 times?

O.k., sorry, but that comparison is beyond faulty. Really. That's so absolutely apples vs. oranges:

"I had 10 compiler errors with named labels and 2 runtime errors with unnamed labels. 2 errors < 10 errors. Therefore unnabed labels win."

You cannot do this because having a compiler error is a good thing. It means the compiler caught something before it slipped into your program.
So, instead the calculation goes:

"I had 2 runtime errors with unnamed labels. And I was prevented 10 times from having a runtime error with named labels. So, the score is 10 points for named labels. And 2 minus points for unnamed labels. The end result is 12:0 for named labels."

Pokun wrote:
The only advantages over local labels I can think of is that they are fast to type, fast to read and doesn't require any global labels around them.

Fast to type: Yes.

Fast to read (i.e. faster than named labels): Definitely no. It is much faster to read @end and to find the other @end in the code than it is to read :+++ and to count three : until you're at the destination location.

And do you really have those many labels of the same type (i.e. where the names would clash) within the same function (i.e. within the same global label)?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu May 05, 2016 5:43 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Multiple loop: in one .proc? Certainly, and it causes an assembly error until I rename at least all but one.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 6:25 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10066
Location: Rio de Janeiro - Brazil
Yes, it's quite common to need several "loop" and "skip" labels, in which case local labels won't be of any help. Like Bisqwit said, sometimes a loop if just a loop, and an if is just an if. If you can get by without naming every if and every loop in high-level languages, you can do the same in assembly.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 11:41 am 
Offline
User avatar

Joined: Fri Oct 14, 2011 1:09 am
Posts: 248
As for documentation: I usually explain in comments what the code does*, even going as far as writing the task out in pseudo code (or even real C). This comes naturally, as I usually prototype the difficult parts in C++ or PHP before writing them out in assembler.
Example:
Code:
        ; To save RAM, the second plane was put into stack, in reverse order.
        ; We can't just use PLA+STA in a loop, or we'll reverse the data.
        tsx
        ; OldStackPointer     = X
        ; CorrectStackPointer = X+8
        ; for(Y=CorrectStackPointer; Y!=OldStackPointer; Y--) Send($100[Y]);
        @old = RowsRemaining ; reuse as temp
        txa
        sta @old
        adc #(8-1) ; C was set. Clears C.
        tax
:       ldy $100,x
        sty $2007
        dex
        cpx @old
        bne :-
        ; Restore stack pointer _after_ reading $100, so that
        ; a possible interrupt happening in the middle of the
        ; loop will not clobber our stack data.
        tax
        txs

*) This principle may slip if I have spent so much time with the code that the code seems blatantly obvious.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 11:55 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
DRW wrote:
rainwarrior wrote:
[...]I've only had to debug an erroneous : maybe 2 times in the past year, whereas I think the assembler has caught unreferenced unnamed label errors maybe 10 times?

[...]
"I had 10 compiler errors with named labels and 2 runtime errors with unnamed labels. 2 errors < 10 errors. Therefore unnabed labels win."

Pardon the interruption, but there's some confusion here. Rainwarrior was talking about unnamed labels only, he wasn't comparing unnamed and named.

@Bisqwit: I do the exact same thing for the same reasons. I also leave comments when I try an optimization that doesn't work, so I don't see that optimization again two years later and try it out again.

Named labels help out with documentation, unless it really is just a supershort loop or a single-instruction skip, but even if you prefer using unnamed labels as much as you can, you could also leave a comment explaining the branch, and that'd be just the same.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 12:16 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1405
Drag wrote:
Pardon the interruption, but there's some confusion here. Rainwarrior was talking about unnamed labels only, he wasn't comparing unnamed and named.

In a way, he was. He said this:
rainwarrior wrote:
Yes, there are always potential errors, but I think I've only had to debug an erroneous : maybe 2 times in the past year, whereas I think the assembler has caught unreferenced unnamed label errors maybe 10 times?

The way he says it, it sounds like he compares the times that named labels bothered him with the time that unnamed labels bothered him and comes to the conclusion that it's 10 vs. 2.
Which is not a fair comparison because the two errors were actual bugs while the 10 errors were prevented bugs.
The unnamed labels probably wouldn't have prevented the problems in those 10 instances. Instead, they would have shifted the error from compile time to runtime.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu May 05, 2016 12:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
DRW wrote:
rainwarrior wrote:
My : usage is similar to how I would use C's { and } with control structures.

Only in C you cannot jump from one } back to a { that it doesn't belong to. Unlike unnamed labels, they always come in pairs.

No, I'm not talking literally about the characters { and } but the scoped structure they represent. There is a clear start and end (which I tend to indicate with indentation), structures like: for, while, if. The cases where I use : are very similar to those.

DRW wrote:
rainwarrior wrote:
One thing you might not know is that ca65 will generate an error if there is no reference to an unnamed label. This catches a lot of the potential errors when making code revisions around these things.

I pretty much assumed that the compiler will catch a jump to an unnamed label that doesn't exist (i.e. using :+++ even though there are only two : after it). I mean, what else should the compiler do but give an error? I was exclusively talking about situations where the code is still syntactically correct.

No, it gives errors in the opposite way from that.

The assembler will catch an unnamed label with no references to it. If you type : and then nothing branches to it, this indicates that you've made a logical error, so it fails for you.

The case you just brought up is actually a problem, because unnamed labels are unscoped. A :+++ to nowhere will reach down through your code until it finds a suitable unnamed label to attach to. Because the common use case for this is with branches often this will produce a range error, but not if it's with a jump instead.

The other thing is, if you meant to type :++ and accidentally typed :+++, often this makes an orphan of the : you were actually intending to jump to, thankfully creating the unreferenced unnamed label error. If there's other references to it, though, you're out of luck.

Here's how this error usually manifests for me:
Code:
; original code with a simple loop

   ldx #10
   :
      stx $2007
      dex
      bne :-
   lda #11
   sta $2007

; later I revise this code to add a special case,
; and I didn't think about the enclosing unnamed label loop

   ldx #10
   : ; this now has no references, assembler error
      cpx #3
      bne :+
         lda #11
         sta $2007
      :
      stx $2007
      dex
      bne :- ; this now points to the wrong one (no direct error)
   lda #11
   sta $2007


DRW wrote:
rainwarrior wrote:
Yes, there are always potential errors, but I think I've only had to debug an erroneous : maybe 2 times in the past year, whereas I think the assembler has caught unreferenced unnamed label errors maybe 10 times?

O.k., sorry, but that comparison is beyond faulty. Really. That's so absolutely apples vs. oranges:
"I had 10 compiler errors with named labels and 2 runtime errors with unnamed labels. 2 errors < 10 errors. Therefore unnabed labels win."

No. I was comparing two different types of errors with unnamed labels, to give you an idea of the practical problems they do and do not create, in my own experience. There is no comparison against named labels here.

DRW wrote:
Fast to read (i.e. faster than named labels): Definitely no. It is much faster to read @end and to find the other @end in the code than it is to read :+++ and to count three : until you're at the destination location.

This is why I favour indentation. If the control structure is clear, you can just look to the end of the indent. If you're using :+++ with spaghetti then you deserve the problems you get.


You seem to be arguing that things you don't use are error prone. I don't see the point of this. I use them constantly, and I don't find them a significant source of programming problems for me. Any programming construct is subject to errors if you make a mistake, the question is how often you make these mistakes, and how much time they consume for you. I make lots of mistakes while programming, but unnamed label mistakes barely register on the scale of time wasted.

You asked why people use them, and those of us who answered seem to be in consensus: less typing, less thinking about names, they look nice to us.

If you wanna tell me you used them a bunch and had a lot of problems with errors, great, that's a reason for you not to use them, and I'd love to hear about your experiences, but if you're gonna just tell me they're useless because they're error prone from some detached theoretical position, you can stuff it. If you wanna know what kinda problems they create, try them out. If you're afraid, leave them alone. I think they're well worth using.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 12:22 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 808
Location: Sweden
DRW wrote:
Pokun wrote:
The only advantages over local labels I can think of is that they are fast to type, fast to read and doesn't require any global labels around them.

Fast to type: Yes.

Fast to read (i.e. faster than named labels): Definitely no. It is much faster to read @end and to find the other @end in the code than it is to read :+++ and to count three : until you're at the destination location.

And do you really have those many labels of the same type (i.e. where the names would clash) within the same function (i.e. within the same global label)?

Yeah well more than two plus-/minus-signs and the readability is starting to decline. I'd probably never use more than three or four (if the assembler even allows that many?). But I think one or two pluses in a short jump is pretty much instantly read.

If I need several @loop or @skip labels within the same "function", I usually just number them (@loop1, @loop2 etc), or think up a more unique name for the situation (like @loop_outer, @loop_nested or something).

Edit: Fixed quote errors.


Last edited by Pokun on Fri May 06, 2016 6:29 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu May 05, 2016 12:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5732
Location: Canada
You've inserted me into that quote erroneously.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 12:49 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1405
rainwarrior wrote:
No. I was comparing two different types of errors with unnamed labels, to give you an idea of the practical problems they do and do not create, in my own experience. There is no comparison against named labels here.

Oops. Right, I read that wrong.

Yeah, for me, I'll indeed leave unnamed labels alone. You might find them practical, but I'm much better when I have actual names to read for labels.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu May 05, 2016 1:43 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
I actually like the way WLA does it:

Code:
   ldx var
---
   iny
   dex
   bne ---     ;this will loop to the label above
   jmp +

++
   rts    ;this line will be ignored
+
   lda #3


The number of + or - doesn't need to correlate to how many nameless labels are in front of or behind your branch statement. It always just looks for the closest occurrence of what you type (for instance, with the "jmp +", it skips right past the "++" because it's simply looking for the next occurrence of just "+").

I would probably die without nameless labels. I have so many little branches in my code that the thought of coming up with a name for each one is just horrible. I make up for it though by defining the exact location in RAM for every single variable. I can't stand that .DS 1 crap, not knowing where the hell anything is when you're trying to debug.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 1:57 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1405
Celius wrote:
I actually like the way WLA does it

But as far as I see, these aren't unnamed labels. It's just that the names don't consist of letters. If you want that and you don't have it, you could easily workaround it by giving the labels names like @a, @aa, @bbb.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu May 05, 2016 2:15 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2131
Location: Minneapolis, Minnesota, United States
Well it's not exactly the same as a named label. Something like this works:

Code:
   ldx var
---
   iny
   dex
   bne ---     ;this will loop to the label above
   jmp +

++
   rts    ;this line will be ignored
+
   lda #3
   jmp +  ;this will go to the NEXT occurrence of +

++
   rts    ;this line will be ignored
+
  lda #4
  ....


You can reuse the + and - label names as many times as you want. The key is that when it is a + label, it can only be referenced by instructions behind it. When it is a - label, it can only be referenced by instructions ahead of it. So if you have a label you want to jump ahead to, but later you also want to jump back to that label, you'd need to do it like this:

Code:
   jmp +
   ...
+
-
   lda #4
   sta var
   ..blah code
   dex
   bne -


It's not as clear as a named label, but it definitely saves time once you're comfortable using them.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 2:21 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10066
Location: Rio de Janeiro - Brazil
Celius, that's how ASM6 works too, which's the way I prefer.

DRW wrote:
It's just that the names don't consist of letters.

That and the labels are completely reusable, even within the same scope.

Quote:
you could easily workaround it by giving the labels names like @a, @aa, @bbb.

Not really, because you can only have one "@a" label in the same scope (or between non-local labels). The code would look much messier as you used random letters for the labels.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 5:02 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:52 pm
Posts: 361
Location: UT
tokumaru wrote:
Celius, that's how ASM6 works too, which's the way I prefer.


And X816, where I stole the idea from ;)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group