avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] one-byte stack bug in tiny26


From: Marek Michalkiewicz
Subject: Re: [avr-gcc-list] one-byte stack bug in tiny26
Date: Tue, 27 Apr 2004 11:51:19 +0200
User-agent: Mutt/1.5.5.1+cvs20040105i

On Tue, Apr 27, 2004 at 09:42:23AM +0200, Svein E. Seldal wrote:
> 
> The -mtiny-stack option, does not help either. SPL and SPH is still 
> loaded/unloaded in the function's prologues and epiloges.
> 
> I found this:
> 
> http://www.avr1.org/pipermail/avr-gcc-list/2001-October/000895.html
> 
> where it is stated that the loading/unloading of the two stack bytes in 
> the function prologue is intentional, despite the usage of the 
> -mtiny-stack option.
> 
> According to the datasheet, the register of SPH is reserved. This 
> implies that we cannot predict the contents of that register, thus gcc 
> should never read SPH on this target. (Even if its done intentional.)

Well, it worked long time ago - non-existent SPH was read as zero.
If it doesn't work on some of the current devices, we may have to add
a new option (meaning "SPH doesn't exist, don't access it ever", while
-mtiny-stack only means "SPH doesn't change, no need to update it" and
avoids the cost of saving, clearing and restoring the I flag around
SPH:SPL updates).  Would -mtiny-stack-only be a good name for it?

Looks like another reason for per-device multilibs, as the avr2/3/4/5
device groups are not enough (my fault, it looked clean at the time
when Atmel's future plans were top secret - today we know about chips
with "movw", but without "mul" = more than avr2, less than avr4).
I'm not sure if we really want so many ld emulations though...

Marek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]