Local Labels  ...



Note for the Tree View feature: if you use plain labels inside your routines, tree view will not give you a very good image of your source structure (each plain label is considered by tree view as a routine entry point). If you do not want 'meaningless' labels in your sources, use HLL-style macros (IF / DO /,  and so on).

     

Inside routines, meaningful labels' names are of little use and create more problems (how to find so  many new names) than they would increase readability:

         

jne L0<               ; is just as clear as:


jne tryAgain


The best is:

 

While eax a ebx

    ; ...

End_While


('While' / 'End_While' defined as user macros including local labels -beginners: You will find Assembly much easier to learn with HLL Macros, but try to use Local Labels from time to time, so that the HLL-style default Macros I propose do not become a mask between you and the code reality-).



A local label is a CODE location symbol you can use as many times as you want: one letter followed by '0...9' followed by a colon:

         

A2:

X7: 

         

are local labels. Yes, same as A86 ones, but evocations of local labels can have a direction and size specifier in all cases:


L3:

...

jc  L3>>    ; long conditionnal jmp to following L3 label

jmp L3<    ; short jmp to upper L3 label

....

....

L3:

         

At  writing time, I recommend that you set all evocations short (< or >): If long specifier (>> or <<)  is needed, RosAsm will tell you. Having to set it long is a good indication of too long unstructured constructions in most cases. 


More: 


This is sometimes a good error signal for a bad branching attempting to reach a label in another routine after some text handling mistake (RosAsm does NOT control local moves crossing over plain labels, so that you can mix local and plain labels if you wish to -you are allowed to do it dirty-).


         

If you write 'jmp L0', of course, RosAsm will suppose it to be 'jmp L0<' (default is 'up-short')


When using these meaningless Local Labels, after some time spent at modifying and re-writing a chunk of code, your Labels order may be turned confusing. As re-ordering properly many Local Labels Declarations and evocations may be painful and a good source of errors, the Source_Editor (see there, the Re-Ordering of Local Labels paragraph) has a friendly feature able to do the job for you.



I recommend you reserve 'L.' for common code and 'M.' for use inside macro definitions. One letter (10 local labels) is more than enough for code; if not, this is a good indication that source needs a more structured rewrite. I often reserve 'L9:' for 'CaseOut' and 'L8: / L7:' for 'CaseError'.


Another good rule is to reserve specific local labels letters for some macros which produced labels could conflict. One example: if you like high level style conditionals (select_case, if, on, ...) you will need  ability of mixing these macros in order to handle any complex case:



[Select_Val: 0]


; association of 'C' letter with 'Case':


[Select_Case | push #1 | pop D§Select_Val | jmp C2>]

[Case | Jmp C9>> | C2: | cmp D§Select_Val #2 | j#1 C1> | jmp C2> | C1:]

[case_Else | Jmp C9>> | C2: ]

[End_Select | C2: | C9: ]



Select_Case eax

           Case e 0

             ; ...

             ; some code lines

             ; ...

           Case e 1

             ; ...

             ; some more code lines

             ; ...

           Case_Else

             ; ...

             ; some more code lines

             ; ...

End_Select

         

Will be expanded as >>>

(If we want to be able to handle negative conditions, this is the usual writing; see more accurate formulation in Double_Negations).


push eax | pop D§Select_Val | jmp C2>>

           jmp C9>>                              ; this first one is dummy

C2:      cmp D§Select_Val 0 | je C1>

           jmp C2>

C1:        ; ...

             ; some code lines

             ; ...

           jmp C9>>

C2:      cmp D§Select_Val 1 | je C1>

           jmp C2>

C1:        ; ...

             ; some other code lines

             ; ...

            jmp C9>>


         ; ......


C2:      ; Case_Else code

C2:

C9:      ; End_Select


  

But you will not be able to nest some more 'Select_Case' inside a 'Case' (we are not in Power Basic with one simple macro...): Labels branching would conflict. So, you will be in need of adding some other macros to handle the other levels (If Else_If Else End_If  /  single-line If, Do Loop_Until, and so on). This will do without any branching conflict if you reserve one label letter to each macro construction ('I' for '.if', 'O' for 'on', and so on). These macros constructions are really great for increasing readability and what little performance is lost is, in most cases, out of purpose.


Another very good solution to this problem is to write, for example, as many macros sets as levels needed with additions of leading '.':


[.If ; .....  ]  [..If ; .....  ]  [...If  ; .....   ]    ; (highly readable...)



Again, local Labels are for Code only. You cannot use them for Data (absolutely impossible anyway). Meaningless Labels in Data may be provided by Macros Data declarations with the reserced '&0' internal Labels management of Macro Parser.


~~~~~~~