Shop OBEX P1 Docs P2 Docs Learn Events
PASM and label scoping — Parallax Forums

PASM and label scoping

Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
edited 2011-11-07 16:01 in Propeller 1
One of PASM's annoyances is the fact that it permits only limited local label scoping (via the colon prefix, e.g. :local_label). For simple programs, this is somewhat effective; but for larger programs with multiple PASM cogs, its limitations are a real nuisance. In these situations, it would be nice to be able to limit the scope of all labels to the org section to which they belong. In my case, I have a need (for clarity) to have variables of the same name in multiple org sections. I can give them colon-prefix names. But that entails naming everything but the leading label in the section with colon-prefixed names, since an intervening non-prefixed name would block access to the variables at the end. While this is a solution of sorts, albeit cumbersome, what makes it even more cumbersome is that you cannot call a subroutine with a colon-prefixed name. So, instead of a convenient one-argument call you have to use the two-parameter jmpret.

What would be nice is a way to push and pop symbol dictionaries, such that the top dictionary is searched first before descending into the dictionary stack to search for a symbol. I've seen this done in other assemblers with CSEG and DSEG pseudo-ops. Something similar could be done in PASM.

I hope that Parallax has not become so distracted with GCC stuff that further Spin/PASM development gets relegated to the back burner (where it has languished for years, sadly, with the back burner turned off).

-Phil

Comments

  • plainsteveplainsteve Posts: 33
    edited 2011-11-07 14:29
    Could you give an example of your situation with a code snippet?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-11-07 14:44
    The most recent place I ran into this issue was with my color NTSC image capture code. Here's a brief illustration of how scoping has to be done now:
    DAT
    
                  org       0
    Cog_code_1    mov       :xaddr,par
                  mov       :yaddr,par
                  add       :yaddr,#4
    
    :main_lp      jmpret    :sub_ret,#:sub          '<- Can't use call here for some reason.
    
                  jmp       #:main_lp
    
    :sub
    
    :sub_ret      ret
    
    :xaddr        res       1
    :yaddr        res       1
    
                  org       0
    Cog_code_2    mov       :xaddr,par
                  mov       :yaddr,par
                  add       :yaddr,#4
    
    :main_lp      jmpret    :suba_ret,#:suba        '<- Can't use call here for some reason.
    
                  jmp       #:main_lp
    
    :suba
    
    :suba_ret     ret
    
    :xaddr        res       1
    :yaddr        res       1
    

    Here's how it could be better:
    DAT
    
                  org       0
                  cseg
    Cog_code_1    mov       xaddr,par
                  mov       yaddr,par
                  add       yaddr,#4
    
    main_lp       call      #suba
    
                  jmp       #main_lp
    
    suba
    
    suba_ret      ret
    
    xaddr         res       1
    yaddr         res       1
                  endcseg
    
                  org       0
                  cseg
    Cog_code_2    mov       xaddr,par
                  mov       yaddr,par
                  add       yaddr,#4
    
    main_lp       call      #suba
    
                  jmp       #main_lp
    
    suba
    
    suba_ret      ret
    
    xaddr         res       1
    yaddr         res       1
                  endcseg
    

    Here, labels defined within a code segment are local to that segment.

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-11-07 15:35
    Rather than repeating blocks of PASM code it would be nice to have an assembler with macro capability. The GAS assembler used in the PropGCC assembles PASM code. It might have a macro capability. I haven't really looked into it much.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-11-07 16:01
    Macros don't address the symbol scoping issues, but I definitely agree: they'd really be nice (i.e. essential) to have.

    -Phil
Sign In or Register to comment.