Propeller PASM size limits

makares

I have done several projects with propellers and have a good understanding of using PASM. However, my current project is causing me some trouble as I seem to be reaching a size limit with the code. I haven't written what I consider to be too many lines in the DAT section (assembly of course), but if I write one more it causes the code not to function correctly. This confuses me greatly as I have the fit statement at the bottom and I start the code with (ORG 0) no compile time errors. It really is as simple as adding a line at the bottom to stop the code from functioning properly. Has anyone had experience with this? Any info would be greatly appreciated. I have looked all over for an explanation of the limits of PASM code segments, but I have found nothing. Thanks in advance.

kuroneko

Could be lots of things. Most common mistake is to use initialised variables or code after res. I suggest you post your code pointing out the offending line and we go from there.

makares

Here is an example of what I am trying to accomplish. This is part of a two cog program. The first cog receives data from a serial stream and places the bytes in a byte buffer located in core memory. This cog is supposed to scan the data for two markers and then indicate through leds that they were found. Some logic is missing from the end of the file as it was the code not getting executed any way. The main problem is the inclusion of the extra lines causing the code to belly up. I think this is enough to get the conversation started. Thanks again.

''****************************************
''*  Monitor Assem. V1.0                 *
''*  Author: Makares                     *
''*  Date: Oct. 7, 2013                  * 
''****************************************
PUB start(stack,CID)
'stack is the pointer to buf_head
  coginit(CID,@mon, stack)                                 'Open new cog
DAT
'Initialization
                        org     0
mon                     mov     m1,par                'Get first address of contiguous longs.
                        mov     headptr,m1            'This device uses a head and tail buffer system.
                        add     m1,#1 << 2
                        mov     tailptr,m1
                        add     m1,#3 << 2
                        mov     buffptr,m1
                        add     m1,#1 << 2
                        mov     test1mask,#1
                        rdlong  m2,m1
                        shl     test1mask,m2          'This creates a mask for setting an output led.
                        or      dira,test1mask
                        add     m1,#1 << 2
                        mov     test2mask,#1
                        rdlong  m2,m1
                        shl     test2mask,m2          'This creates a mask for setting an output led.
                        or      dira,test2mask
                        add     m1,#1 << 2
                        mov     test3mask,#1
                        rdlong  m2,m1
                        shl     test3mask,m2          'This creates a mask for setting an output led.
                        or      dira,test3mask
:markerscan             rdlong  head,headptr          'Get current head location.
                        rdlong  tail,tailptr          'Get current tail location.
                        cmp     head,tail       wz
              if_z      jmp     #:markerscan          'Wait until head <> tail.
                        mov     m2,#0                 'Grab the next byte off the buffer and increment tail.
                        mov     m1,buffptr
                        add     m1,tail
                        rdbyte  m2,m1
                        add     tail,#1
                        or      tail,#$FF
                        wrlong  tail,tailptr
                                
                        shl     currentword,#8        'Shift out the top byte of the long.
                        or      currentword,m2        'Shift in new byte
                        cmp     currentword,PAT1 wz   'Compare to pattern 1
              if_z      jmp     #:testblock
                        cmp     currentword,PAT2 wz   'Compare to pattern 2
              if_z      jmp     #:testblock
                        jmp     #:markerscan          'Return to markerscan if neither patern is found.
:testblock              or      outa,test3mask        'This is a test stub to light an led to see this location was reached.
                        rdlong  head,headptr          'Get current head location.
                        rdlong  tail,tailptr          'Get current tail location.       
                        mov     m1,head
                        cmp     m1,tail         wc
              if_c      add     m1,#256
                        sub     m1,tail               'Check for gap between head and tail.
                        cmp     m1,#24          wc
              if_c      jmp     #:testblock
                        add     tail,#20              'Move to the desired byte location.
                        mov     m2,#0                 'Grab the next byte off the buffer and increment tail.
                        mov     m1,buffptr
                        add     m1,tail
                        rdbyte  m2,m1
                        add     tail,#1
                        or      tail,#$FF
                        wrlong  tail,tailptr
                        
                        or      outa,test3mask
                        or      outa,test1mask  
                        '''Any extra lines here causes the code to not run properly.  I believe that it may
                        '''cause the jmp to be ignored and so the code finishes.
                                             
                        jmp     #:markerscan
                        
PAT1                    long    $0F0F0F0F
PAT2                    long    $F0F0F0F0                        
m1                      res     1
m2                      res     1
test1mask               res     1
test2mask               res     1
test3mask               res     1
head                    res     1 
headptr                 res     1
tail                    res     1
tailptr                 res     1
buffptr                 res     1
currentword             res     1
                                fit     496  

Dave Hein

You should put the "fit 496" after the last item that will be used in the cog, and not just after the last instruction. In this case you should put the FIT instruction after the statement where currentword is reserved. Even though the extra code is not being executed it may be causing your cog variables to be beyond the first 496 locations in the cog.

makares

Thanks for the advice. I have implemented the change, but I am still having the same problem.

Dave Hein

When you increment the tailptr you add 1, and then or it with 255. Shouldn't this be an and instead of an or?

kuroneko

Dave Hein wrote: »

When you increment the tailptr you add 1, and then or it with 255. Shouldn't this be an and instead of an or?

+1 (since you are only using a byte index (assuming the intention was & $FF) it may be beneficial to just use rdbyte/wrbyte in addition to the increment)

Also, you use currentword uninitialised (res). IOW there is a chance (however small) that it contains part of a pattern you check against which means a single incoming byte may complete the pattern and you detect one where there isn't one.

makares

Thanks for the help today kuroneko and Dave. You have both been alot of help. The or was throwing things off and I was rolling through some memory that caused the rest of the program to be flaky. Thanks again for all of your help.

Mark_T

Is there a reason to call coginit rather than cognew?

makares

That is a habit of mine I suppose. For this particular application I did not need coginit. I have worked on a couple of applications though where I needed firm control over which cog these things were started on as cogid was the only parameter I could use to distinguish one from the other. Think of launching the same process on 7 cogs at once and you need to be able to control which input and output lines that cog will interface with. You can use cogid to "figure out" what cog the current code is running on and run the same generic code rather than creating 7 specialized codes.