Shop OBEX P1 Docs P2 Docs Learn Events
Passing data in PAR rather than a pointer — Parallax Forums

Passing data in PAR rather than a pointer

BradCBradC Posts: 2,601
edited 2007-09-30 07:11 in Propeller 1
Just been playing with PAR and using it to pass data to a cog rather than a pointer.
We all know it zero's bits [noparse][[/noparse]0..1], (Propeller Tricks & Traps page 7)

but did anyone know it only passes the next 14 bits? Bits 16..31 seem to be masked.

(Or they were in my tests here).

ie
COGNEW(@asm_prog, 1 << 15) shows what it should in the COG, $00008000 while
COGNEW(@asm_prog, 1 << 16) shows PAR == 0

Can someone point me to the bit in the doc where it says this?

Comments

  • RaymanRayman Posts: 14,789
    edited 2007-09-28 17:57
    Well, I think all addresses are 16 bit words. Guess that's why it shouldn't matter in the usual usage...
  • RaymanRayman Posts: 14,789
    edited 2007-09-28 18:04
    Quote from manual:

    It’s important to note that the Parameter field is intended to pass a long address, so only 14-
    bits (bits 2 through 15) are passed into the cog’s PAR register.
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-28 18:08
    .. and around ten further spots from this forum to quote, as well as deSilva's Tutorial smile.gif

    The very deep rational behind this becomes totally obvious when you look at Table 5.1 on page 366 in the Manual. There is just no more space in a 32 bit word.
  • RaymanRayman Posts: 14,789
    edited 2007-09-28 18:09
    I'm just trying passing an address parameter for the first time right now. My question is: How do I know that the long variable from a "VAR" section, whose address I'm sending, is long aligned? It's working for me, even if I add a byte var before it, so I guess the compiler sees to it that this works...
  • BradCBradC Posts: 2,601
    edited 2007-09-28 18:09
    Thanks for that.. need to get Phil Pilgrim to update his Tricks & Traps document as it states...

    "Of course, this effectively limits argument size to 30 bits, instead of 32"
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-28 18:11
    All long variables are LONG aligned.. Please forget this funny "byte adressing" you are used to from other processors.

    And also remember: VARs are re-sorted by the compiler according to size!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2007-09-28 19:27
    The Tricks 'n' Traps error has been corrected. Thanks to Rayman for pointing out the correct info in the manual and to BradC for pointing out my error in TnT!

    -Phil
  • bambinobambino Posts: 789
    edited 2007-09-29 22:58
    deSilva,

    I was under the understanding that Var Memory was continous and·I am banking on that being true in a project of my. Are you saying that if I pass an assembly routine an Array, that using " sub par_,#4" may or may not get me the var declared before the array?
  • Mike GreenMike Green Posts: 23,101
    edited 2007-09-29 23:37
    bambino,
    That should work. All long variables in an object are allocated in the order declared, so a long variable declared just before a long word array should be located just before the array in memory. Subtracting 4 from PAR should give you the address of this long variable.
  • bambinobambino Posts: 789
    edited 2007-09-30 03:26
    PHhhhhhhhhh!blush.gif

    Another Disaster avoided. Thanks.
  • deSilvadeSilva Posts: 2,967
    edited 2007-09-30 07:11
    Mike Green said...
    bambino,
    That should work. All long variables in an object are allocated in the order declared, so a long variable declared just before a long word array should be located just before the array in memory. Subtracting 4 from PAR should give you the address of this long variable.

    True, true ... but not if it were a WORD or a BYTE.

    BTW: The complete VAR area of all objects is assembled all together to be located at the end of the binary.

    16 "special bytes", then DAT then code then VAR...

    As there can be no preset with VAR this area is NOT transmitted when loading the RAM from the PC, the bootstrap loader seems to look after a preset of the complete RAM. It is however stored into the EEPROM (always 32k!)

    Post Edited (deSilva) : 9/30/2007 7:16:26 AM GMT
Sign In or Register to comment.