[avr-gcc-list] Re: [Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[Joel Sherrill]

Eric Weddington wrote:
>  
>
>   
> > -----Original Message-----
> > From: Joel Sherrill [mailto:address@hidden 
> > Sent: Thursday, May 03, 2007 10:48 AM
> > To: Eric Weddington
> > Cc: 'Ralf Corsepius'; address@hidden
> > Subject: Re: [Bug target/31786] error: unable to find a 
> > register to spill in class 'BASE_POINTER_REGS'
> >
> > Eric Weddington wrote:
> >     
>
>   
> > > I would strongly suggest that you and Joel take a look at 
> > >       
> > avr-libc again: it
> >     
> > > has printf, many string functions, etc.
> > >   
> > >       
> > Does it support file IO?
> >     
>
> Avr-libc user manual online:
> <http://www.nongnu.org/avr-libc/user-manual/>
>
> Stdio specific docs:
> <http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html>
>
>  
>   
> > At the bottom of the implementation of the stdio library what gets 
> > called?  write() or
> > an output character function? 
> >     
>
> Output character function. This allows the end user to write to just about
> anything, uarts, lcds, etc.
>  
>   
> > I'm not saying it is impossible.  Only that RTEMS has a lot of POSIX 
> > functionality and that
> > we try to leverage newlib as much as possible for that support.  The 
> > behavior of RTEMS is
> > the same on every port and switching C libraries for a single target 
> > decreases the cross
> > platform value RTEMS offers.
> >     
>
> Sure. Putting an OS (any of them) on a small 8-bit micro such as the AVR can
> almost be overkill, depending upon the situation. You have to give it some
> thought about what kinds of functionality do you really need on an AVR.
>
>   
I don't think we really see RTEMS as that appropriate for the tinyAVRs
but at least some of the megaAVRs are reasonable RTEMS targets.  Shrinking
executable footprints for RTEMS is a never ending and ongoing battle but 
many
of the megaAVRs look reasonable. 

> The upside is that avr-libc supports every single AVR device under the sun,
> plus it contains AVR-specific functions (e.g. bootloader API).
>
>   
That is a plus and even using newlib, it might be appropriate to build a 
subset of
avr-libc for other functionality.
> I would also think that it depends on what your business case is; how many
> customers do you have really wanting RTEMS on AVR?
>   
Agreed.  The business case for ANY target that requires a LOT of 
deviation in
the standard RTEMS source base is very hard to justify.  Ignoring cost, just
the maintenance of such a unique target would be harder long term.

But none of this justifies ignoring the original bug just because the 
code was
in newlib not avr-libc.  It is still a compiler bug and could eventually 
show
up somewhere else in code you really do care about.

--joel

> Eric
>
>