Erratic behavior when ram getting full

T Chap

RAM usage:

Prog 7138
Var 1004
Stack/Free 46

Strange things start happening, a lockup for no reason. When I comment out pretty much any lines in the program, things get back to normal. There are no errors. I am trying to understand the issue since there is a ton more programming to go.

Baggers

I'm guessing you're running out of stack space then, do you have routines calling routines? or multiple parameters for a function? etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

BradC

I'm with Baggers. 46 longs of stack is really not very much. You'd eat that in less than 10 average subroutine calls. Remember each call eats 3 longs at an absolute minimum, then you have local variables on top of that! Each local variable is another long, then you have your intermediate stack usage during the subroutine. Most math seems to use between 2 and 5 longs of stack. Repeat/Case all use stack and more if you nest them. Stack usage adds up _very_ quickly.

You've got 8k of global variables there! Maybe look at trading some globals for locals if you can and see if that helps the space usage.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

whicker

I still wish the spin interpreter or the actual hardware had some sort of stack overflow monitoring.
I know I've (briefly) griped about this before.

BradC

whicker said...
I still wish the spin interpreter or the actual hardware had some sort of stack overflow monitoring.
I know I've (briefly) griped about this before.

When you overflow the stack on a PC program it usually crashes. When you overflow the stack on a PIC program it usually crashes. When you overflow the stack on a 68HC11 program it usually crashes. When you overflow the stack on a Propeller program it usually crashes.

I can't really see that much of a problem. Stack monitoring of some sort is probable doable, but just like garbage collection in Java and string bounds checking in managed languages, it costs a great deal of overhead to protect the programmer from themselves.

The trick is to be aware of the problem and try to avoid it. In the case of the propeller we have the interpreter source and therefore we *know* what things cost. We can dump the listing of a spin program and we can physically sit there with a pencil and _count_ the stack usage of any routine as a result. Personally I don't want the interpreter slowed down to check each call and warn me in some way that I've just hit the end of the stack. How would it do that in any case? Crashing is a pretty good indicator [noparse];)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

T Chap

Baggers said...
I'm guessing you're running out of stack space then, do you have routines calling routines? or multiple parameters for a function? etc.

Yeah there are quite a few callers and callees.

Brad said...
Maybe look at trading some globals for locals if you can and see if that helps the space usage.

I never even considered that locals use a different ram location. I can probably convert a lot to locals, is a local array possible? I'll try it later to find out.

Thanks guys, this will help. But still a lot of stuff to write yet, optimization will be half the effort now.

BradC

TChapman said...
I never even considered that locals use a different ram location. I can probably convert a lot to locals, is a local array possible? I'll try it later to find out.

Sure it is. Same as an array in globals except the ram and contents are only valid while that routine is running. Also remember that the contents of all locals except "Result" are indeterminate when the method is entered.

As long as you remember that locals disappear as soon as the routine in which they are declared returns then you can do pretty much anything with them you can do with globals.

Remember that a caller will use a minimum of 4 longs for the call, so a couple of calls with some locals will give the stack a good workout.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.

agodwin

BradC said...

The trick is to be aware of the problem and try to avoid it. In the case of the propeller we have the interpreter source and therefore we *know* what things cost. We can dump the listing of a spin program and we can physically sit there with a pencil and _count_ the stack usage of any routine as a result. Personally I don't want the interpreter slowed down to check each call and warn me in some way that I've just hit the end of the stack. How would it do that in any case? Crashing is a pretty good indicator [noparse];)[/noparse]

I wouldn't want the interpreter to check (except maybe in a debug mode, and that can be done by utilities like the stack check object). In any case, that requires that your testing regime gives 100% code coverage, which is quite hard to achieve (though a good thing if you can).

But rather than going through the listing with a pencil, it would be possible to have the compiler construct a call tree and calculate the worst-case stack usage. It would be difficult in C due to function pointers and the like, but as I understand it a spin program's call tree is fully defined.

All it needs is one of those fine compiler-writing gentlemen to add this wonderfully useful feature .