[Top][All Lists]
[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