How do I know when prop is "full"?
Hugh
Posts: 362
This is probably a silly question, but how do I know when I have reached a limit of the Prop?
I've been adding more and more bits of code and the 'F8' compile summary shows there is still free space, but how do I know:
- how many free cogs are in use / available at any one time?
- When there is sufficient 'load' that all cogs are saturated?
Will it just stop working, or will there be some strange manifestations first?
Just curious!
Hugh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
I've been adding more and more bits of code and the 'F8' compile summary shows there is still free space, but how do I know:
- how many free cogs are in use / available at any one time?
- When there is sufficient 'load' that all cogs are saturated?
Will it just stop working, or will there be some strange manifestations first?
Just curious!
Hugh
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
Comments
Counting used COGs is a bit more difficult. In general the compiler cannot know this. COGs can be started and stopped during run time so the number in in use at any time entirely depends on the nature of the application and the work it is given at any moment.
Generally most objects, from OBEX for example, will tell you how many COGs they use. In the documentation or in the comments in the code.
It is up to the programmer to keep track of what COGs he is using as the program progresses. Fortunately in 90% of application COGs are only started once at start up, for device drivers etc, so it's not so hard.
If you are dynamically starting and stopping COGs in an application it would be wise to check the error returns from the COG starts so as to avoid any "mysterious" failures at run time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hugh - the thinking woman's Geoffrey Pyke.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/
PhilPi wrote a pre-processor that analyses and strips out unused code from the intermediate files for compilation and one of the third party SPIN compilers has an option that leaves out all unused parts of SPIN code. It's all the same in the end I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Your results may vary especially if you have big arrays declared in a method's variables or have undeclared buffers.
I thought is was because C was using a lot of space for the Stack.
I have found the same thing but only with code compiled under C. I have been using Forth almost exclusively for a few months now, it makes more sense to me but there is little interest in the Forum for some reason. The lastest version of Propforth leaves only 17 unallocated longs. The rest of hub is divid up and have not had it hang on me at all.
_stack = 100
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's very difficult to account for stack usage, particularly in complex programs. I guess its easier with the propeller as you don't have interrupt stacks to worry about, but none the less it's not an easy task to estimate the longest call branch and work back from that to gauge stack usage.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
But now I think I understand why I'm surprised at the behavior of Spin compilers failing when free space is low.
When I start up a COG with some Spin code I specify a stack for it to use. It's down to me to figure out how much stack that Spin code may need and reserve that much space for it. I have total visibility and control as I reserve that space myself.
This is true except for that first Spin code that starts up after reset. In this case I have no say in how big or where the stack is and no visibility of it.
Edit: Except now I've been reminded of the existence of _STACK so at least I have a say in how big it is even if I don't know where.
Would it be so hard for a compiler to assume no recursive calls, create a call graph and report the possible worst case stack usage? After all it knows how much stack is required for all the calls, parameters and locals. It could just give up if recursive calls are detected.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 10/6/2009 10:33:45 AM GMT
True except you do know where it is. It travels down from the top of RAM. And your default say in how big it is, is how little code and data you write.
I just kind of wish in hindsight the TV and VGA drivers would have declared their buffers formally, instead of just giving an address. Oooh, look at all that free space left-- oh wait, something isn't adding up... I'm sure I'm not the only one.
No it doesn't. The stack starts immediately after the allocated variables (end of the VAR section) and expands toward the end of ram ($7FFF).
_STACK does nothing to set the size of the stack, it simply makes the compiler complain if less than _STACK is available. It's a bit like FIT but for SPIN code. It is just a compiler directive.
If you start another SPIN cog and give it a stack variable, the interpreter will happily bulldoze its way off the end of that if its too small, trashing any other allocated VAR areas in its path.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I see the issue now.
Reason being is the tile address also encodes the color as one of 64 palettes, defined in the colors array.
If that is done, then just use @buffer where the address is given in the driver code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!