RE: [avr-gcc-list] when is it safe to use -mtiny-stack
-Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu. org] On Behalf Of sjuid-...@yahoo.com Sent: Sunday, April 05, 2009 2:30 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] when is it safe to use -mtiny-stack I have an ATmega3290P app that I am trying to optimize for size. I find that using the -mtiny-stack option gives me the last It's not safe at all. The 3290P has 2K of RAM which gets used for static variables, stack space and heap (if you use dynamic memory allocation). -mtiny-stack will cause the compiler to only change the lowest 8-bits of the stack, which means that you effectively only have a 255 byte stack. Can you guarantee that your application does not use any more stack space than this? Do you have complete code coverage in your testing to prove this? And please subscribe to the list so your messages don't have to be approved. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] when is it safe to use -mtiny-stack
It's not safe at all. The 3290P has 2K of RAM which gets used for static variables, stack space and heap (if you use dynamic memory allocation). -mtiny-stack will cause the compiler to only change the lowest 8-bits of the stack, which means that you effectively only have a 255 byte stack. Can you guarantee that your application does not use any more stack space than this? Do you have complete code coverage in your testing to prove this? Can I have source code for the program we are talking about? I'm working on a stack analyzer. Currently it does not support the tiny-stack case but certainly that would be nice. John Regehr ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] when is it safe to use -mtiny-stack
Hi. Are there any caveats to the use of this option? How would one know if it is safe to use for a given code base? The -mtiny-stack may (and should) be used only for devices with 0xFF max RAM adderss, i.e. if SP register is 8-bit. All devices with 1KB and 2KB FLASH memory satisfy this condition, now. Anatoly. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] when is it safe to use -mtiny-stack
On Tue, 7 Apr 2009, Anatoly Sokolov wrote: The -mtiny-stack may (and should) be used only for devices with 0xFF max RAM adderss, i.e. if SP register is 8-bit. All devices with 1KB and 2KB FLASH memory satisfy this condition, now. Is it not sufficient for the maximum extent of the stack to be 256 bytes? John ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] when is it safe to use -mtiny-stack
The -mtiny-stack may (and should) be used only for devices with 0xFF max RAM adderss, i.e. if SP register is 8-bit. All devices with 1KB and 2KB FLASH memory satisfy this condition, now. Hello all, If the memory size itself is 256 Bytes, naturally SP will be 8 bits and where is the need to explicitly tell the compiler of mini-stack? Is it to generate any stack over flow errors? Thank you. Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] when is it safe to use -mtiny-stack
John Regehr reg...@cs.utah.edu wrote: Is it not sufficient for the maximum extent of the stack to be 256 bytes? Only if the stack starts at a 0xXXFF address. As RAMEND on the ATmega3290 is equal 0x8FF, this is by default the case on that MCU type. Other MCU types (in particular older AVRs) have a RAMEND of e.g. 0x25F. In that case, the stack could only extend to 0x60 bytes before changing SPH were due. (Alternatively, the stack could be relocated to a lower address, e.g. 0x1FF.) -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list