getting different results for address in LONG (answered)

ericball

For my sprite driver the sprite table format is addr[noparse][[/noparse]16]:xpos[noparse][[/noparse]8]:ypos[noparse][[/noparse]8] (lsb) (all 0 for unused)

The following SPIN code works:

sprite_tab.BYTE[noparse][[/noparse]0] := Constant((240-8)/2) ' ypos, sprite[noparse][[/noparse]0]
sprite_tab.BYTE[noparse][[/noparse]1] := Constant((240-8)/2) ' xpos, sprite[noparse][[/noparse]0]
sprite_tab.WORD[noparse][[/noparse]1] := @sprite
But trying to do the same in the DAT section the address is wrong:

DAT
sprite_tab···········LONG··· @sprite<<16+((240-8)/2)<<8+((240-8)/2)
sprite················· BYTE··· 00, 00, 00, 05, 05, 00, 00, 00
Based on the output, instead of @sprite, I'm getting @sprite-??

Post Edited (ericball) : 4/7/2009 7:25:09 PM GMT

localroger

@ericball, LONG @ references have to be dword aligned. Bit me in the posterior a few times before I figured it out. Spin quietly zeroes the low 2 bits of your address. To retrieve a non dword aligned LONG from a table you might try a bytemove to a LONG var and retrieve the value from there.

ericball

@localroger, I'm not certain what you are saying.
sprite is LONG aligned (because it's after a LONG), thus the low 2 bits should be zero. What I can't figure out is why "sprite_tab.WORD := @sprite" gives a different result from "sprite_tab LONG @sprite<<16".

Mike Green

The difference is that @sprite in Spin code is dynamically computed. When the compiler compiles the code, it doesn't know the actual address of sprite. It has to add a base address at run-time. When the table is compiled, the compiler also doesn't know the actual address, so it uses the offset of sprite in the object's data space. The "@@" operator is intended to correct this at run-time. Read the descriptions of the "@" and "@@" operators in the Propeller Manual.

ericball

Thanks Mike. That makes more sense. So the solution is - don't do that.

Although, isn't DAT statically addressed? I know VARs are dynamic and per object, but I thought DATs weren't per-object.

Anyway, I guess I will have to revise my code so the @sprite is done at runtime. A minor annoyance.

Mike Green

DATs are indeed shared among instances of an object, but the compiler still doesn't know where the DAT will be located when it's being compiled. Even though the compiler manages the actual compilation of the Spin code and the assembly of the DAT sections, there's separate phase where the compiled objects are "linked" together to produce the final object program and this "link" phase doesn't change what's already compiled/assembled. It allocates space for the various objects and builds the run-time tables that have the actual addresses of the objects.