Cog startup time

Alex Mackinnon

I just wondered what the cog startup time is?

The datasheet gives the instruction time for the calling cog but I'm not sure I've seen a note anywhere of how long after that·(in clocks)·the initialized cog begins executing instructions - I assume it has to read the 512 longs of data from the hub-memory and then starts processing?

Mike Green

Yes. Most of the cog startup time is that required to copy 512 words from hub to cog. It's on the order of 100+us with an 80MHz system clock.

Alex Mackinnon

Thanks - I'm still getting to grips with the powerful but strange (or maybe just unfamiliar) architecture and I was wanting to factor in cog startup times [noparse]:)[/noparse]

Mike Green

Usually you don't start up a cog to do a single operation. Typically, one or more cogs are started during initialization, then they either act as interpreters or function mostly autonomously. The floating point package is an example of the former and pretty much any I/O driver is an example of the latter.

The architecture is really just that of separate, independent processors with some shared resources (I/O, hub memory). The Propeller is somewhat like the I/O processors of the Cray or CDC multiprocessing computers of years gone by.

Alex Mackinnon

I get the bit about setting cogs up once and then using them as function or IO processors [noparse]:)[/noparse]. Why I asked was that I am loading the cogs via a single buffer from post-32k-EEPROM rather than embedding the various cog programmes in the main programme in order to maximize main memory and I was working out whether I needed a semaphore setup to detect when the cog was finished loading from the buffer or whether it was deterministic enough to just rely on the main programme timing - I'v decided to go with a semaphore [noparse]:)[/noparse].

Mike Green

You don't need a semaphore (LOCKxxx) for this type of signalling, just a byte in hub memory that gets initialized to zero by your loader and set to non-zero by the (once only) initialization of the cog program. Your loader waits for the byte to become non-zero before starting to load the next cog's program. The same byte could be used for all the cogs if you wanted.

Baggers

Just out of curiosity, how are you accessing functions from the cogs you are initializing with post-32k-EEPROM, I was wondering about doing something like this in some of my games, where memory was tight, ie, sound drivers and tv display drivers don't need to be in main memory, as they get sent to a cog, then that memory is free to overwrite, but I have no idea where it's stored in ram, or if you can order it's position in ram so it's at the end of memory so you can overwrite it without worrying about it corrupting something important.
Mike, ( as you've done something like this with your OS ) or anyone at Parallax, is there a particular way you can do this at the moment?

Cheers,
Baggers.

Mike Green

There's no nice clean way to do this. You can't control where the drivers are placed in memory. You can pass the address (and size) around at runtime.

In the OS, the actual assembly routine along with its Spin initialization routine is in one object while the Spin routines that interact with the cog are in a second object. My intention was to provide the OS itself (which includes the cog initialization stuff) as one program while "applications", which are separate programs, would only include the Spin interface objects (not the cog initialization stuff). The OS would be loaded first. It would set up the cogs, then load and run the "application".

Each cog "driver" has its own work area allocated at the end of the hub memory. The pointers to the work areas are in fixed locations so the cog "drivers" and the Spin interface routines can find them. The program loader in the OS knows about the work areas and won't load programs into that area.

You could certainly modify the existing I/O drivers to return the address and size of the area where the assembly driver is assembled. Your program could link these areas together and use them for some kind of buffer or other data storage once the cog has been loaded.

Alex Mackinnon

When I said semaphore I actually meant a status byte in the shared parameter block I send to the cogs as they are started.

I need a buffer for text processing in my main programme so after the main programme starts I load the image for each of the cogs into this buffer from the EEPROM, start the cog and then move onto the next one - when all the cogs are loaded my main programme can use the buffer for it's own purposes. I have a bootstrap EEPROM image that I can load to send the cog images into the post-32k EEPROM. I've also got a couple of the cog images in the buffer to preserve space in the EEPROM.

In essence all I'm doing away with is the spin wrapper and embedded cog asm in the main programme and shifting a number of cog programmes into the spare EEPROM above 32k.

Baggers

Cheers Mike [noparse]:)[/noparse]