Pasm missing base load address

Ray0665

I know you guys are busy with a lot of great and interesting things but I just yesterday stumbled accross a very important missing feature in the propeller tool.


Working in PASM I wanted to build a linked list in cog memory defined as follows:


Dat
L1 long @L2,<data>
L2 long @L3,<data>
L3 long @L1,<data>


Try as I might I could not follow the pointers. after posting to the forums it turns out that there is no way to get the actual load address using the spin tool the pointers are actually relative offsets and without the object base load address
I have to jump thru hoops to make a simple linked list work.


This means there are an entire class of classic algorythms, stacks, fifos, lifos, linked lists etc that are now difficult to code.


Modifying the propeller tool to make this value (the objects base load address) available should not be a difficult thing to do. if BST can do it, the prop tool certainly can. I can do it in spin (Ptr := @@Long[Ptr][NxtPtr]) So I know the basic coding is available somewhere in the spin tool source code. So please add it to the PASM




And while I am on a roll please please make sure this is included in the upcoming prop 2 tools.


This should be considered of the utmost importance before sleeping and eating even (JUST KIDDING)

Mike Green

For a linked list in cog memory, the way "@" is handled is actually correct. Cog code (and data) is always loaded starting at location 0 of the cog and you normally put "ORG 0" at the beginning of any cog's DAT section. It's immaterial to the cog code where it's copied from in hub memory when the cog is started. Now if you want the list structure stored in hub memory, that's a different story. The "@" operator in LONG or WORD statements still puts in an offset for the object and the "@@" operator corrects this at run-time in the Spin code. Cog code (PASM) is indeed an issue. The Propeller Tool doesn't have the "@@@" operator that exists in BST and Homespun and it won't likely be corrected since Parallax will be switching to a different Spin compiler / PASM assembler that'll be part of the SimpleIDE / GCC package and that'll have the "@@@" operator.

Jeff Martin

Hi Ray0665,

Yes, you're right, this can be difficult to deal with. The problem is that the Spin compiler wasn't built to keep a list of addresses in need of patching (at a later pass) for items like this (instead, it emits an "address" token followed by the relative address). Since the data is just "data" and will not be interpreted at run-time, only the relative address is emitted into the data image. I believe BST achieves this with an enhancement that keeps track of addresses to patch at a later pass (once the object's base address is known; a cool feature.

I'll add this to our list of things to review and try to solve in the Propeller 2 (and retroactively to the Propeller 1).

In the mean time, though it's not desirable I admit, you could do something like this to help resolve the problem in your code:

PUB {some_initialization_method}
  REPEAT WHILE {proper_condition}
    Long[Ptr][NxtPtr] := @@Long[Ptr][NxtPtr]

the above code need only run once (and better run only once) at application start-up to manually patch the addresses.

Phil Pilgrim (PhiPi)

You can always add @@0 (the object base address) to the relative addresses in your load and store functions. It's an extra step, granted.

-Phil

Ray0665

Thanks to all for your suggestions and for the great info.
I was not aware that the simple ide will have the @@@ operator that is certainly something I will make use of.