COG and Force Run

ALIBE

is it possible to identify a COG and have it take the time slice to process. I guess my question is broader is it possible to control which COG will need to process its code from another COG.

Suppose I have 3 COGs in my app.
1) runs general sensors and sets feelers out to the env
2) processes the data sensed by #1
3) processes logging and Output

Can #1 selectively ask #2 or #3 to process its stuff...

thanks, ALIBE

Jon Williams

When you launch your new cogs you'll provide the address to the sensor data -- that way other processes can access the data and do something with it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

ALIBE

thanks Jon, a few follow ups:

what if I want to ::cognew() and then call it only on demand.

if ( x==y){
// cog 1 ::doThis();
}

is it only possible by unloading the cog and then ::cognew() again. If so, what is the performance hit on the ::cognew() call - does it depend on what's running in each cog (I guess).

thanks

ALIBE

Jon,
sorry forgot to add, in you note I did not see if it;s possbile to ID a specific cog and have it take the run.

Jon Williams

If you look at my timer object you'll see that I have methods called run and hold that affect the operation of the timer after it's been loaded into a new cog.· Remember, all Spin code resides in main RAM so there's no point moving it to another cog if you're going to call it synchronously.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Post Edited (Jon Williams (Parallax)) : 4/7/2006 6:03:37 AM GMT

ALIBE

good point on the Sync vs Async and to Cog.

Thanks.

SleepMaster

I may have missed this somewhere -- forgive me if it is redundant.

What sort of cog management is avvailable? Do we have a way to see which cogs are idle? which are running assembler versus interpreted code? I take it that the spin-running cog is usually the first to stat and is probably in cog0 (?) but can you envision a device monitoring cog that is monitoring the others in some way? I'd write something like this first off -- if I had a chip and spin/asm reference manuals, of course.

Tom Walker

I suppose that you could set your objects to "register" themselves when they first start up by putting a value in the shared variable space (assuming you've set up a design protocol and use only your own objects). You could also just pop out cognew()s and check the returns to build a table of how many are running.

Other than that, it sounds like you are trying to apply a "larger machine" paradigm to an environment in which it's not a good fit...

...or I could just as easily be missing the point...I've been doing a lot of that lately [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Truly Understand the Fundamentals and the Path will be so much easier...

Paul Baker

The ability to start and stop cogs is all that is explicitly provided. All other functionality would have to be provided for programmaticaly. And there are many different was of doing so depending on what you need. One example would be to use the 8 locks to indicate which cogs are active, then use a memory location for each cog for a status indication. There is no mechanism to interrogate a cog from another cog, this means each cog would have to update its own status in order for other cogs to know what it's current status is.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system)

SleepMaster

Tom Walker said...
Other than that, it sounds like you are trying to apply a "larger machine" paradigm to an environment in which it's not a good fit...

Yes, you are precisely correct. I am thinking of emulating a CDC6600. The architecture of that machine was surprisingly similar to this chip, in fact the memory of the cogs is quite close to that of CDC 6000 series PPUs and the "slot int he barrel" technique is identical. The 6600 software architecture included a central processor as well but you could easily do a lot of work using just the PPUs and the operating systems were entirely designed around these computers, each based on the design of the CDC-160A

Understanding what was happening in the larger system was often quite a problem simply because so many things can be going on at once. Making sense was often a amtter of having code that would run in a PPU and "tell" you want was happening elsewhere.

For starters I need a bit of code that will dump the contents of the registers and memory in a cog to a specific location in the main memory.

MMmm and then I need something to peek and poke into memory in the cog, change registers, etc. Hmmm.

Anyone likely to make an ICE for this chip?

Gadgetman

Eh....

The registers and memory of a COG can only be accessed from within that COG.
(At least I can't see any way to do that. And frankly, the possibility of directly reading/writing another COGs memory is too terrifying to behold. Too many things that can go wrong)

But if the CDC6600 is so close to the Propeller in design...
Why don't you try to emulate it with a couple of FPGAs?

I'd love to read a bit about how Chip built and tested the COGs using FPGAs.
(I'd pay to read it in fact. Not much, but still... )

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

SleepMaster

Hmm unfortunate. WQell, we can always hard code hese things. Used to have to do that when PPU memory got tight. Hate to work that way but have done it before and it might end up being part of debugger.

What's the register structure for the cog?

Anyone have the instruction that I can look at?

Again, is there an ICE in the future? Or maybe a cog simulator?

Paul Baker

No ICE, Parallax has decided against using debugging tools commonly availible because their translation to a multiprocessor environment either makes it too cumbersome or impossible. Supposedly somone has been working on a sim, but I·know no particulars about it or when to expect such a thing.

I think you may find that trying to turn the propeller into a classic multiprocessor will introduce a lot of overhead and not produce much benefit. The propeller isnt a multiprocessor in the traditional sense, its a multicontroller. Certainly there would be applications where a cog monitor would come in handy, but I wouldn't implement it as a baseline.

Cog memory is 512 longs (2Kbytes) with the last 16 being special purpose registers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system)

Kaos Kidd

What about a model for things like Protious software?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

SteveW

>The propeller isn't a multiprocessor in the traditional sense, it's a multicontroller.

Multicontroller - splendid invention!

Since this is something that's going to get asked again and again and again, I rather hope Parallax adopt that word...

Seve

ALIBE

So, I'm confused.

Multi-Microcontroller is an understatement of Multi-Microprocessor. I heard in some other threads that Parallax is calling this a "MultiProcessor".

I personally don't really worry abt it - just as long as it is doing what I needed [noparse]:)[/noparse]

However, from an architectural standpoint, I would think of propeller as a multiprocessor and not multicontroller. It is first a multiprocessor and does help drive the multicontroller behavior.

Is it not. Please correct if I'm wrong. I don;t want to be in denial

Paul Baker

Dont loose sleep over it, its just a word I coined. Multiprocessing systems have been arround for many years in the high end computing arena, but the propeller is distinctly different than the predecessory multiprocessors. The propeller is one of (if not the) first multi-core processing chips specifically designed for embedded applications. Because microcontrollers are used in nearly all embedded applications, I coined the term multicontroller, to draw a distinction between it and the other multiprocessing systems in existance, because they are vastly different. Comparing a Cray to the Propeller is illogical, though both are multiprocessors.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
6+6=10 (Long live the duodecimal system)