Can a COG stop itself?

Basil · 2007-05-30 01:07

Hi All

The subject pretty much says everything.

Provided there is no infinite loop in the COG, will it automatically stop once it has done whatever the object it was loaded with was meant to do?
(By stop, I mean become available to start again with COGNEW.)

Also, can I call COGSTOP(x) from COG x?

Thanks All!

mirror · 2007-05-30 01:11

Yes, yes & yes.

To stop a cog from within assembly use:

        cogid    cogid   'Get my cog id 
        cogstop  cogid   'Kill myself 
cogid   long   0

The rest is pretty stright forward.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007

Basil · 2007-05-30 01:24

Thought so [noparse]:)[/noparse] And in spin?

Cogid := Cogid
COGSTOP(Cogid)??

Mike Green · 2007-05-30 03:02

(You can't have a variable named "Cogid" since there's a function with that name.

cogstop(cogid) does work fine.

Basil · 2007-05-30 03:22

Oh, missed that one [noparse]:)[/noparse]

Thanks guys.

mirror · 2007-05-30 03:53

I heard it once that every application has about 1 bug for every 1000 lines of code, and that for every bug you fix, you introduce another.

Well, I can do better than that: My example was 3 lines, with a bug in every line!!! cogid was an amazingly poor choice of variable name.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007

Basil · 2007-05-30 04:04

lol, just think of all the bugs in Windows, it may make you feel better [noparse];)[/noparse]

KC8DKT · 2007-05-30 05:31

· Check out Vista,· that WILL make you feel better...

mirror · 2007-05-30 06:38

Geez, you guys are NO encouragement. Are you trying to say I should get a job at Microsoft?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007

Basil · 2007-05-30 20:47

Don't think so lowly of yourself! We would never stoop so low! :-D

ThePenguinMaster · 2007-05-31 14:10

i think windows dose better than one bug every 1000 i think its more like every 6 lines lol.. they dont call them bugs though.. they call them 'un-documented features'

oh and check out pc linux if you want to know what a good os is supposed to look like. sorry, this is an unrelated post.. shame on me..

at least with the single line cogstop(cogid) your really lowering the lines of code and keeping it simple. i did also try to set cogid to a variable at first. Im not sure why but it dose seem like the first thing that comes t mind even though its over complicating things.

Basil · 2007-05-31 20:49

ThePenguinMaster said...
i think windows dose better than one bug every 1000 i think its more like every 6 lines lol.. they dont call them bugs though.. they call them 'un-documented features'

Ands it funny the build in features in anticipation of bugs...Windows Update?

Anywho, back on subject

Ok so thats an easy answer to that question.

And the other one? If a cog run's out of things to do (i.e its not stuck ina loop or waiting for something) does it stop.
Does the stack space become available again and the cog ready to be used when COGNEW is called?

Or does it wait to be COGSTOP'd?

Mike Green · 2007-06-01 04:28

If a cog "runs out of things to do", it does stop. Really what happens is that, when the initial routine of a cog is called by a COGNEW/COGINIT in Spin, a return address is used that does a COGSTOP(COGID) effectively. When the cog stops, it is completely reset ... there's no stack (the space is no longer being used for a stack) ... the registers of the cog are all reset to zero, the cog stops executing instructions and its power consumption drops drastically.

simonl · 2007-06-01 08:55

Just to be clear; when a cog is started we have (should?) let if know which part of RAM to use as a 'stack' -- so *we* should have already set this space aside (right?)

That being the case, when the cog stops, either through a cogstop(cogid) or via the implicit stop, the 'stack' is NOT cleared -- is that right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

mirror · 2007-06-01 10:45

simonl said...
Just to be clear; when a cog is started we have (should?) let if know which part of RAM to use as a 'stack' -- so *we* should have already set this space aside (right?)

That being the case, when the cog stops, either through a cogstop(cogid) or via the implicit stop, the 'stack' is NOT cleared -- is that right?

Yes, so you'd do something like:

var
  long cog
  long SomeStackSpace[noparse][[/noparse]10]   'Set some space aside as a cog stack
 
PUB StartCog
  cog := CogStart(CogFunction, @SomeStackSpace)
  AllowAmazingStuffToHappenForSomeTime
  CogStop(cog)
  'At this point, SomeStackSpace is probably filled with random
  'values, but you are now free to use it for any purpose 
  'whatsoever. So you could do:
  CogStart(AnotherCogFunction , @SomeStackSpace)
  'Some time will pass during which SomeStackSpace must NOT be used,
  'but eventually the cog will die (after 10 iterations) and then 
  'SomeStackSpace is available for use again.
  
 
PUB CogFunction
  repeat
    DoAmazingStuff
 
PUB AnotherCogFunction | i
  repeat i from 1 to 10
    DoAmazingStuff
  'This cog dies at this point and SomeStackSpace is once again 
  'free for use in any way you see fit.

Of course the two functions AllowAmazingStuffToHappenForSomeTime and DoAmazingStuff have not been defined here, but their definition shouldn't be too hard.

So, the stack is NOT cleared, but that doesn't matter, because it hasn't been consumed or anything, and is available for further use in other functions.

Which leaves only the question you haven't asked:
How much space should you set aside for the stack?
The answer depends a bit on how complex your cog function is. There's a stack size helper object in the Object Exchange. Of course if the cog you start is an assembly cog, then you don't need a stack at all.

Any questions?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
It's not all that hard to count the number of grains of sand on the beach. The hardest part is making a start - after that it just takes time.·· Mirror - 15 May 2007

metron9 · 2007-06-01 17:55

"if the cog you start is an assembly cog, then you don't need a stack at all."

Just thinking about getting a prop so I am lurking...

Where is the program counter pushed for called subroutines and interrupts in assembly language if there is no stack?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!

Mike Green · 2007-06-01 18:23

Look at the description of the JMPRET instruction. The source field specifies a jump destination as do all jump instructions.
The destination field specifies a location where the program counter is to be stored in the source part of the location.
If the destination location is a JMP instruction, that acts as the return. The CALL / RET "macros" work that way with
the RET actually being a JMP instruction and the label for the RET being made from the CALL operand followed by "_ret".

I suggest you stop lurking and get yourself a Protoboard. You could also download GEAR and the Propeller Tool and try out
some simple programs with GEAR's simulator.

Can a COG stop itself?

Comments