Shop OBEX P1 Docs P2 Docs Learn Events
Initialization state of COG RAM? — Parallax Forums

Initialization state of COG RAM?

epmoyerepmoyer Posts: 314
edited 2009-03-01 23:42 in Propeller 1
Is the initialization state of COG RAM guaranteed, and if so, what is the initialization value (zero perhaps ?).

I'm trying to determine whether, when writing Propeller Assembly, I can count on the initial state of "uninitialized" data words (i.e. like r1 in the example below) to be some known value (i.e. does the spin interpreter wipe all of Cog RAM to some known value before loading and starting ASM code in a new cog, or is the memory left in whatever state it was in before the load/start was performed?)

r1                        res     1             ' General purpose register



Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com

Comments

  • mctriviamctrivia Posts: 3,772
    edited 2009-03-01 06:38
    yes cog ram is garanteed. it is the same as what the hub ram was when the cog was loaded. 496longs are copied every time no mater how long the code was.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Need to make your prop design easier or secure? Get a PropMod $50CAN has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module.
  • mctriviamctrivia Posts: 3,772
    edited 2009-03-01 06:39
    in that case it would be a 0

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Need to make your prop design easier or secure? Get a PropMod $50CAN has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-01 07:22
    REServed cog memory is initialized to whatever comes after all the RESes. Typically, this will be code or data that's not really part of your assembly program, since RESes virtually always come last. So whatever comes next in hub RAM is what the RESed cog RAM will be initialized to. The take-home is this: if you want cog RAM initialzied to known values, use BYTE, WORD, and LONG, not RES.

    -Phil
  • epmoyerepmoyer Posts: 314
    edited 2009-03-01 07:30
    Ah, then it's not necessarily zero (and generally won't be). If a piece of ASM code is, say, 200 Longwords in length, then when you load it into a cog the copy will take whatever 296 longs follow the ASM code in hub ram and copy them as well. Generally that space will be occupied by other ASM code, or other Spin code, or "heap" RAM being used by other spin code for data storage. Unless you're particularly careful/clever, you can't depend on it's value.

    It makes sense that it works that way, since the COG load call doesn't specify a code length.

    Given that it always copies 496 longs, that says you can't expect a known initialization of uninitialized COG ram data. Of course, you can always declare it as pre-initialized data in ASM at the cost of a Longword of storage (i.e. the ASM code footprint gets 1 longword bigger), but generally it costs you a longword to pre-initialize the data programatically anyway, so in the general case it's a toss up and in specific cases one or or the other may be more efficient depending on whether there are multiple sequential words to initialize, and whether initialization needs to be performed more than once.

    Thanks

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    The World's First Open Source Guitar Pedal:··http://www.OpenStomp.com
  • AribaAriba Posts: 2,690
    edited 2009-03-01 07:47
    When a cog is loaded, 496 longs are copied from HubRAM, also if the PASM code is shorter, and the last 16 longs are forced to zero (the SPRs).
    So: Yes all cog memory is set to a known value, no random data is in a cog.
    But: The cog-ram data behind your Assembly code depends on the following DAT, PUB or PRI sections that the compiler links into that HubRAM. To know the values, you have to look at the HexDump which you get with F8. It's not so easy to find the correct addresses, and the data can change, if you change your Spin code.

    The RES directive just increments the cogram pointer of the assembler, but writes no data in HubRAM and does not increment the hubram pointer. So the labels get the right cog address, but no hub ram is occupied. The main purpose of the RES is to spare HubRAM.

    Andy
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-03-01 17:16
    Phil Pilgrim (PhiPi) said...
    REServed cog memory is initialized to whatever comes after all the RESes. Typically, this will be code or data that's not really part of your assembly program, since RESes virtually always come last. So whatever comes next in hub RAM is what the RESed cog RAM will be initialized to. The take-home is this: if you want cog RAM initialzied to known values, use BYTE, WORD, and LONG, not RES.

    -Phil
    Phil, you say this is so, and so does Ariba.· I lean a little towards the safety of doubting it, since the manual (page 398) says nothing of the kind, not even by implicatiion·-- yet I know that you and Ariba are among the most knowledgeable and articulate who post here, and I have learned not to trust the manual, for completeness especially.· Dadgum!· I think I'm going to have to run an experiment.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-01 18:20
    Carl Hayes said...
    I lean a little towards the safety of doubting it ... I think I'm going to have to run an experiment.
    I don't blame you one bit. Besides, you'll remember it longer if you go to the trouble of trying it. smile.gif

    -Phil
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-03-01 23:42
    Phil Pilgrim (PhiPi) said...
    Carl Hayes said...
    I lean a little towards the safety of doubting it ... I think I'm going to have to run an experiment.
    I don't blame you one bit. Besides, you'll remember it longer if you go to the trouble of trying it. smile.gif

    -Phil
    Just ran the experiment -- by golly, you're right.· Who'd'a thunk it?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net

    Post Edited (Carl Hayes) : 3/2/2009 2:55:35 AM GMT
Sign In or Register to comment.