Prepackaged Cogs

M.Earnshaw

Hi all,

I was just wondering if its possible to write a dedicated object in spin/asm, store it in eeprom, and load it in and initialise a cog with it on demand, with access to the variables already in hub?
If all the individual cog 'images' have identical opening sections (Con, Obj, Var), with the variables layed out identically, would this allow it?

In theory, the way I see it, as long as the hub variables are placed in the same place then a cog image would just write to the variable.

E.g.
Each cog image has the same opening section: (Semi-Pseudo code)

Con
  (Some constants)
Obj
  Object 1
  Object 2
Var
  Long a, b, c
  Word d, e, f
  Byte g, h, i

Object A is then created using the above header, that reads from a, adds 10, and writes it to b.
This is run on Cog 0.

Object B is created, using the same header, but this time reads from b, subtracts 10, and then writes to a. This object is stored in eeprom.

The Hub ram is then blanked after the variables onwards.
If Cog 1 is then loaded with Object B from eeprom, will the 2 cogs be able to communicate even though they are 2 seperate objects?

I think thats the best way I can explain it, its been driving me mad for the past day trying to figure out if its possible. The theory sounds fine to me in principle, but I might be missing something.

Mike Green

You're not really loading that program piece into the cog. Remember that, when you run a Spin program, you're actually running a Spin interpreter in a cog and all of the code and variables reside in the hub (main) memory. None of the code or variables reside in the cog. When you start up a new cog in Spin, you're just loading another copy of the Spin interpreter into the new cog using a stack area in hub memory that you supply for the Spin interpreter's use.

Assembly code is a different issue. This is initially placed in hub memory, then transferred to a cog by the COGINIT/COGNEW instruction which takes about 100us to execute completely. Once the code is copied to the cog, the area where the code was stored is no longer needed. The COGINIT/COGNEW instruction can pass the address of a hub variable area to the new cog and this can be different for each cog that's started.

M.Earnshaw

Ahh ok, I was thinking that perhaps if the compiler placed the variables in a constant scheme in hub ram (Address 0 onwards), then different images could just write to those locations.
Seeing as how all the cogs will have the same variables in the exact same order, and the compiler always placing vars in the order: Long, Word Byte, that it might be possible.

Cheers for the help.