Re: [avr-libc-dev] RFD: more avr-libc API changes

[Björn Haase]

Joerg Wunsch wrote on Samstag, 10. September 2005 22:30 :
> > One thing, however, that I think that we might want to change some
> > day is the __tmp_reg__,__zero_reg__ issue. I assume that the
> > original decision to use r0/r1 stems from times when there were no
> > hardware multipliers.
>
> That's my guess, too, and would be one thing I'd really see changed.
>
> > IMO it would be better to use r2:r3 instead so that one could, e.g.,
> > avoid all of those "clr __zero_reg__" in the multiplication
> > operations.
>
> Btw., IAR (optionally) uses r15 as zero register, but doesn't have a
> specific alias for that (so assembly programmers will use literal
> r15).  If we could agree on that, too, it would ease porting assembly
> source code between both compilers (albeit I think featuring their
> entire ABI is completely out of scope).  But that's low priority.
I don't think that this is a good idea. I'd prefer to continue using one of 
the lower registers since this way one could continue having consecutive 
registers being allocated in, e.g. r12...r15.

> Would it make sense to have that on the schedule for GCC 5.x (plus
> avr-libc 2.x)?
I hope that one does not need to wait this long :-). 


Apart of that, I am seeing presently three important projects for the avr port 
that are somewhat linked:

1.) Implementing the cc0 -> CCmode transition
2.) Doing the subreg lowering at expand instead of at text output
3.) Using rtl prologues.

3.) is the least urgent, but also the easiest. I hope that I will be having a 
solution by the end of the next week that also adds support for the >128k 
devices.

Concerning 2.) It is my impression after having done quite a number of 
experiments that doing the lowering after reload would not help so one would 
need to do the lowering at expand in order to have a real benefit. Since then 
one would need to re-write the patterns anyway, IMO, it would be best to do 
it in one step with 1.). 
Doing the lowering, IMO, would require using a recent patch by Richard 
Henderson that removes the requirement, e.g. to allways allocate 4 registers 
for a 32 bit variable even if only part of the results needs to be 
calculated. Otherwise register moves of multi-register values with 
overlapping registers will be impossible.

Main difficulty, IMO, with 1.) will be the re-use of condition codes that 
would probably have to be implemented by a CSE pass. I would address the 
other difficulty due to reload insn that possibly clobber the condition code 
such that one makes the expander for reload insn insert insn to save and 
restore the condition code in the __tmp_reg__ if necessary.

At the same time with 1.) and 2.) one probably would change the multiply insn 
to RTL expanders.

Yours,

Bjoern.