Multiple Objects into a single cog

pjv

Hi All;

So, I'm quite nicely along in polishing a small Scheduler OS to run as PASM in cogs. I have been spending a LOT of time on it, and think I'm loosing focus on the bigger picture..... all my work has been written in assembler,

I have numerous low level drivers that operate "simultaneously" in a single cog, all orchestrated and interfacing to Spin through the Scheduler. For users' convenience, I now want to locate these disparate routines into separate objects, and in doing that am finding a rather rude and ugly surprise. Stupid me for being so focussed on the details, and ignoring the bigger view.

It appears that for a single cog, the DAT sections of mutiple objects will not compile into a contiguous cog memory map; they are placed in the consecutive object's DAT fields. I had not forseen this blunder.

This now means that all the PASM code must exist in the top object, and that kind of defeats the purpose of having objects. Not that that approach will not work, it's just nowhere near as elegant.

So in posting here is my current understanding of PASM objects correct, or is there some further thing I need to learn, and what I want CAN be done afterall ?

Cheers,

Peter (pjv)

Mike Green

As you've noticed, the DAT sections for various objects are scattered around memory and there's no way to override the memory allocation. Possible solutions:

1) Change to use of C and GCC compiler/linker where you can override this sort of thing. You can use Spin2GCC to make use of your existing code.

2) If you have the memory for it, allocate a 512 long buffer, copy the DAT code from each object to the buffer, then finally do the COGNEW to load the code into the cog.

3) Have separate source files or conditional compilation files that compile the DAT and pre-COGNEW initialization, then write the DAT information to an EEPROM or a micro-SD card. When recompiled, the interface methods are compiled and the DAT and initialization stuff is not and the COGNEW stuff can read in the DAT file and initialize the cog.

Alexander (Sandy) Hapgood

pjv wrote: »

This now means that all the PASM code must exist in the top object, and that kind of defeats the purpose of having objects. Not that that approach will not work, it's just nowhere near as elegant.

I've been using objects for my PASM code. Basically, all the code you want to run in a cog is contained in a single object and that object launches a cog when it starts itself. I have attached an example of a PASM object and the spin code that launches instances of the object. An advantage to this approach is that you can reuse variable names in different objects within the same application. Saves having to come up with 8 different names for 'X' haha.

The attached program also demonstrates running PASM in all 8 cogs.


Regards,
Alexander (Sandy) Hapgood

prof_braino

If your already good at PASM, you might want to consider propforth.

You can have your common definitons in the hub dictionary, or have optimixed routines that load into one particular cog.

Also, Propforth 6 is expected to have a shared pool of execution opportunities spread across a user selectable number of threads. On a prop 2, 4 threads per cog times 8 cogs gives upto 32 thread in the pool. If a thread crashes or otherwise has a problem, we only loose 1/32 of our processing. There is a slight cost for pool overhead, but so far the overhead appears minimal.

Publison

prof_braino,

Congrats on post 3,000!

pjv

Hi All;

Thanks for the comments.... although I often seem to be rejecting the ideas offered, I do appreciate the input. It is mostly that my ideas are so bizarre, that usually more conventional concepts are not a good fit.

@ Mike;
1) Thanks for confirming my suspicions. Also, I hope to learn C at some future time to satisfy my curiosity.... just not now as I'm way too busy and expect to stay with Spin when I *finish* learning that.
2) & 3) I have work-arounds that are some simpler than your suggestions.... it's that I was hoping for some epiphany.

@ Sandy; While I did not spell out my full intentions for these objects, I will now mention that they are intended to be user-invoked on a SIMPLE basis, in fact hiding the details from the user. So object calls with some parameters. The most significant thing here, is that initially multiple (co-operative) objects are to be loaded into a single cog at compile time, concurrent with the cog's OS. A little further down the development chain, these objects will be loaded (on a re-locatable basis) into a cog with an OS that is already running. I just wanted to have some clean way of a user selecting the objects to be loaded. This issue is resolved when that further development is complete.

@ Prof; The PASM code I have written is *very* tight and high performance, and though I am not sure, I suspect that a non-PASM approach will be slower. But I ought to have a look at it ... sometime. I don't want to change directions just at this point.

Thanks again all.

Cheers,

Peetr (pjv)