Searching \ for '[PIC]:CCS C and stacks' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=c
Search entire site for: 'CCS C and stacks'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:CCS C and stacks'
2001\01\16@163922 by Barry Gershenfeld

picon face
You guys seem to be saying that it's possible to write
a C program that won't run on the PIC after it's compiled,
because you may exceed the stack size.  Is this true?  I
would expect the compiler to either be careful not to
do this or to avoid using the hardware stack for conventional
call/return at all.   Especially on a chip with a 2-level
stack!  If all this is a real problem, then which
operations use the stack?  Just function calling?

If I can figure out how to get a call tree out of my PCW
compiler I'll probably be able to answer this myself.

Barry

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\01\16@164927 by Mike Mansheim

flavicon
face
>If I can figure out how to get a call tree out of my PCW
>compiler I'll probably be able to answer this myself.

If you're using the CCS IDE, Alt-T will show you the call tree.
If you're using MPLAB as the IDE, the compiler will create a
.tre file in the project subdirectory that you can look at
"manually".  You need to have the "generate call tree"
option checked in the project properties for this file to
be created.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\01\16@170002 by Dipperstein, Michael

face picon face
A PIC C compiler cannot reasonably guarantee that it will not generate code that
can overflow the stack.

Return addresses get pushed onto the stack both in the context of base level
code and interrupt level code.  A stack overflow will occur if the total stack
usage by both calling trees exceeds the stack space of the processor.

It is not all that difficult to determine the maximal stack usage by either
calling tree, however, under most circumstances it is not possible for the
compiler to determine the maximal combined stack usage of both calling trees.

-Mike
{Original Message removed}

2001\01\16@223418 by Bill Westfield

face picon face
   You guys seem to be saying that it's possible to write
   a C program that won't run on the PIC after it's compiled,
   because you may exceed the stack size.  Is this true?

Yes, of course it's true.  As far as I know, ANY C compiler for ANY
processor can produce code that overflows the stack.  I don't THINK there
are any that actually try to guess what the stack size SHOULD be, and of
course it's not possible to predict the amount of run-time recursion.

BillW

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\01\16@232355 by Kevin Maciunas

flavicon
picon face
William Chops Westfield wrote:
>
>     You guys seem to be saying that it's possible to write
>     a C program that won't run on the PIC after it's compiled,
>     because you may exceed the stack size.  Is this true?
>
> Yes, of course it's true.  As far as I know, ANY C compiler for ANY
> processor can produce code that overflows the stack.  I don't THINK there
> are any that actually try to guess what the stack size SHOULD be, and of
> course it's not possible to predict the amount of run-time recursion.
>

It *IS* possible in this case - there is NONE.  CCS compilers re-use
memory as long as it can be re-used.  The only exception to this is a
routine which is marked as an interrupt service routine. Recursion is
not allowed.

As has been pointed out by others, the only recourse to make it fit is
inlining at the appropriate point and the compiler will give you a call
tree, so it's a simple task.

I've used the 16F84 and the CCS compiler as an example for my compiler
construction course, the students still find it amazing that the MCU
only has a few bytes of RAM and you can compile code for it :-)

/Kevin
--
Kevin J. Maciunas           Net: .....kevinKILLspamspam.....cs.adelaide.edu.au
Dept. of Computer Science   Ph : +61 8 8303 5845
University of Adelaide      Fax: +61 8 8303 4366
Adelaide 5005
SOUTH AUSTRALIA

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\01\17@134806 by briang

flavicon
face
In-Reply-To: <3136A952E020D211882000805FE687B102D11D68spamspam_OUTnssmx2.cpd.harris.com>

"Dipperstein, Michael" <@spam@mdippersKILLspamspamHARRIS.COM> wrote:

> A PIC C compiler cannot reasonably guarantee that it will not generate code that
> can overflow the stack.

Yes it can.

> Return addresses get pushed onto the stack both in the context of base level
> code and interrupt level code.  A stack overflow will occur if the total stack
> usage by both calling trees exceeds the stack space of the processor.
>
> It is not all that difficult to determine the maximal stack usage by either
> calling tree, however, under most circumstances it is not possible for the
> compiler to determine the maximal combined stack usage of both calling trees.

The compiler just assumes that an interrupt can occur at any time.

Brian Gregory.
KILLspambriangKILLspamspamcix.compulink.co.uk

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...