>> >>> The overflow in DSEG is all >>> sloc variables and I don't know how to move those (thats what >>> stack-auto >>> is supposed to do I think?) out of the internal ram. >> >> Yes, stack-auto puts the sloc's on stack too. And you >> cannot move slocs to any other memory, because then SDCC >> would need sloc's to access those sloc's. >> > Does that then imply a severe limit on arguments to functions? > Using > both --model-large and --stack-auto makes the failing code compile > (but as > noted not run ...).
In my experience the easiest way to get slocs in your code is to have complex functions with many variables in play at a given time. You won't have any slocs if your vars all fit in r0-r7. By tightly scoping variables, and limiting the use of multibyte variables you can get rid of most slocs. If that does not remove enough for you, you can also refactor your subroutines into multple smaller parts that deal with only a subset of the data. The only place I have not been able to banish all slocs from my code is where I do lots of math with 32 bit values. The first 4 bytes passed to a function are free. So, if you are careful to keep your API simple you will need to burn very little memory for this issue. I hope this information is useful. Good night, Mark Swayne ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
