2011/11/29 Georg-Johann Lay <a...@gjlay.de>:
> For devices with 8-bit SP reading the high byte SP_H of SP will get garbage.
>
> The patch uses CLR instead of IN SP_H to "read" the high part of SP.
>
> There are two issues with this patch:
>
> == 1 ==
>
> I cannot really test it because for devices that small running test suite
> does not give usable results. So I just looked at the patch and the
> small test case like the following compiled
>
> $ avr-gcc-4.6.2 -Os -mmcu=attiny26 -m[no]call-prologues
>
> long long a, b;
>
> long long __attribute__((noinline,noclione))
> bar (char volatile *c)
> {
> *c = 1;
> return a+b;
> }
>
> long long foo()
> {
> char buf[16];
> return bar (buf);
> }
>
>
> int main (void)
> {
> return foo();
> }
>
>
> The C parts look fine but...
>
>
> == 2 ==
>
> The libgcc parts will still read garbage to R29 as explained in the
> FIXMEs there.
>
> Solving the FIXMEs can only be achieved by splitting multilibs avr2 and avr25,
> i.e. the mutlilibs that mix devices with/without SP.H, into avr2, avr21,
> avr24,
> avr25, say.
>
> I don't think it's a good idea to have real 8-bit SP/FP and that it would
> cause
> all sorts of trouble.
I'm agree.
>
> Ok to commit to 4.6?
Approved.
>
> What about splitting multilibs?
Seems that splitting multilibs is a right way.
> Is this appropriate for 4.7?
As I understand, any changes appropriate for our port in any stage.
> Johann
>
> PR target/51002
> * config/avr/libgcc.S (__prologue_saves__, __epilogue_restores__):
> Enclose parts using __SP_H__ in defined (__AVR_HAVE_8BIT_SP__).
> Add FIXME comments.
> * config/avr/avr.md (movhi_sp_r_irq_off, movhi_sp_r_irq_on): Set
> insn condition to !AVR_HAVE_8BIT_SP.
> * config/avr/avr.c (output_movhi): "clr%B0" instead of "in
> %B0,__SP_H__" if AVR_HAVE_8BIT_SP.
> (avr_file_start): Only print "__SP_H__ = 0x3e" if !AVR_HAVE_8BIT_SP.
>
Denis.
