global data, pointers, the DAT section and cogs

PaulForgey · 2016-03-18 02:04

I'm rather new to the Propeller (and thus also Spin) and so hopefully this is a really stupid question.

I've got 2 objects on their own cogs trying to share a large-ish amount of global memory.

My first object, called "display", holds 1K of character tile data in the DAT section as well as an array of 80 longs. I point this out because the DAT section is ultimately going to be longer than the 2K worth that gets copied into COG ram, and that's fine, as the assembly bits will fit. The rest of the data I wish to use as global assets.

It starts off like:

VAR

    LONG    Cog
    LONG    Params[5]
    WORD    VLine

PUB Start(ModePtr, DisplayPtr)
    Stop
        
    Params[0] := ModePtr
    Params[1] := @Vline
    Params[2] := @Tiles
    Params[3] := @Screen
    Params[4] := DisplayPtr
    Cog := cognew(@entry, @Params) + 1
    
    if Cog
        crt.Start(ModePtr, @Vline, @Screen)
..

DAT
    org
    
entry
    mov r0, PAR
    rdlong mode_ptr, r0
    add r0, #4
    rdlong vline_ptr, r0
    add r0, #4
    rdlong tiles_ptr, r0
    add r0, #4
    rdlong screen_ptr, r0
    add r0, #4
    rdlong display_ptr, r0

' and then the main loop 

..

' about 1K worth of BYTE data

Screen long 0[80]

The second object, called "crt", also takes a pointer to this array of longs:

VAR

    LONG    Cog
    LONG    Params[3]
  
PUB Start(ModePtr, VlinePtr, ScreenPtr) : okay

    Stop
    Params[0] := ModePtr
    Params[1] := VlinePtr
    Params[2] := ScreenPtr
    okay := Cog := cognew(@entry, @Params) + 1
 
...
       
DAT
    org
 
entry
..
    mov r0, PAR
    rdlong mode_ptr, r0
    add r0, #4
    rdlong line_ptr, r0
    add r0, #4
    rdword screen_ptr, r0
..

The "crt" object sees a perfectly valid view of screen_ptr. If I modify Screen from spin, I see it reflected in the "crt" object when it does

mov ptr, screen_ptr
..
rdlong ptr, r0

The problem is the "display" object does not. The following code will not modify the same location both Spin in the "crt" object are seeing:

' in "display":
wrlong screen_ptr, #0 ' do not know where this is going

screen_ptr at this point is not the same value as the other's

Cluso99 · 2016-03-18 05:37

The VAR section will reside in hub, and if you use the object more than once, then you will get a VAR section for each instance of the object.

A DAT section (for data) will reside in hub, and you will only get one instance for all instances of the object. Therefore, this becomes globals.

A PASM DAT section is compiled and gets loaded into the cog (496 longs get loaded into cog memory).

SPIN section(s) are PUB(s) and PRI(s). They get compiled into byte codes and remain in hub. A PASM spin interpreter gets loaded from HUB ROM into the cog and it executes your bytecode spin program.

Cluso99 · 2016-03-18 05:43

Now, with your code, you need to post it between [ code ] and [ /code ] tags without the spaces to preserve indentation. Next you have two instances of PASM code with the same start labels (entry).

Sorry I cannot help much more than this for now as I am on an iPhone.

PaulForgey · 2016-03-18 06:03

What you say lines up with my understanding. Between the Spin pointer syntax and the location of DAT objects, I guess a more concise way to ask my question would be: is there anything obvious I am getting wrong? An accidental extra indirection or such? I just can't see how the second cog could be seeing the wrong pointer value, yet it is.

PaulForgey · 2016-03-18 06:25

I am definitely doing something fundamentally wrong with the pointers. My program's Spin bytecode appears to be getting scribbled.

PUB ..

    PtrToStuff := @Stuff

DAT

Stuff long 0[5]

In this example, PtrToStuff is the address of 'Stuff', thus pointing to the first long in the array, no? What is it if not?

PaulForgey · 2016-03-18 06:28

D'oh! It was pointed out to me (and thank you!) that wrlong dest, src dest is the VALUE to put into the location at SRC. No wonder I was scribbling my program data.

Cluso99 · 2016-03-18 06:33

I would bet its an indirection problem. You have not shown where ModePtr nor DisplayPtr get set.

I see you found the problem. Read and Write are different to normal instructions...
rdxxxx <cog_addr>,<hub_ptr> 'reads hub into cog
wrxxxx <cog_addr>,<hub_ptr> 'writes cog into hub

There is a easy way to find out what is where for debugging. Use the x := long[@screen] to show what is there, and you can even set it with long[@screen] := $xxxx.
The same applies to your params..
x := long[Params][0]

This way you can see which part is incorrect. For PASM, I use a fixed part at the top of hub, say $7F00.

You can also use a fixed location for the screen display until you get it working. Use a CON section with SCREEN

global data, pointers, the DAT section and cogs

Comments