Re: AW: AW: AW: [avr-gcc-list] avr-gcc bug: global register variable isbroken

[Klaus Rudolph]

Hi Bjoern,

fisrt I find out that local register allocation seems to work as expected.
And of course I could not find specific code for that so that this is done
by generic gcc code I hope. If it is so I really only have to rearange
the function_arg routine to get correct registers, yes.

But I´m not really shure about that all, because there is some
code which really make no sense for my eyes today. There is a sorting
routine with 3 differnt tables of local register allocation.... but I found
no input value which change this. And I have no idea why there should be
the normal avr.h defnition overwritten? 
> 
> In fact the things that you should consider to change to your desired
> values are
> 
> 1.) First register to use for variable passing:
> 
> Source line
> #define FIRST_CUM_REG 26

OK

> 
> 2.) Number of registers available for variable passing 
> source line in function    "init_cumulative_args"
> 
> com->nregs = 18
> 

This looks not like expected. Because there are 2 tables which describe
which
regs should saved by caller and one which says which registers should be
saved by function. And this function gives something which is not derived
from
the information at all. And also ignoring the fixed_regs table. 
I think that is more then a few hours...
OK, I simply will do a test and maybe it works or not. Maybe I brake the
code
on other places but this is avr internal code so that not the complete
family
is broken :-). 

And that only every second register is used for chars seems not ok. 
There is a movw instruction which needs that kind of allocation if
16 Bit ints are used. But this makes only sense on controllers which support
this.
And it make only sense for vars which are 16 bits or more I think.
In my personal code every second register is gone whithout any usage.
That is a lot for an embedded system :-)

And also I am wondering that fixed regs is r0 and r1 bit interrupt and
signal is allways pushing them on the stack. Also a lot of action for
nothing if it could be guaranteed that this registers leave untouched.
OK, against this, we have an lpm instruction so these registers must move to
a controller save place. The next thing I found is that registers 
are used in large sequences.


push r18
push r19
push r20
...
ldi r18, 0
ldi r19, 1
ldi r20, 2
mov r5, r18
mov r6, r19
mov r7, r20

and so on. Here a single register is enough to move the intermediate 
content around.... As I saw in my personal target code I found that this
wastes nearly 10% of code. A lot for a controller I think....

But first I will continue looking for the actual bug. After fixing that
we can do the improvements :-))))

I hope there will come some more activists in the discussion here.


Regards,

Klaus

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!