Re: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-bit eepromaddresses in devices with 8-Bit address registers

[Wouter van Gulik]

Eric Weddington wrote:
>  
>
>   
> > -----Original Message-----
> > From: 
> > address@hidden 
> > [mailto:address@hidden
> > org] On Behalf Of Joerg Wunsch
> > Sent: Wednesday, October 24, 2007 6:28 AM
> > To: address@hidden
> > Subject: [avr-libc-dev] Re: [bug #21410] Incorrect use of 
> > 16-bit eepromaddresses in devices with 8-Bit address registers
> >
> > As Wouter van Gulik wrote:
> >
> >     
> > > What is the main reason not to build a per-device lib, apart from
> > > the time to do such a thing? I quickly scanned the mailing archives
> > > but I could only find the build time as a reason. Is this still
> > > valid?
> > >       
> > Basically yes.  With the current number of AVRs we are supporting (and
> > Eric adding  another dozen or  so right now),  the build time  for the
> > entire  avr-libc project  could easily  reach something  like  half an
> > hour, which is way too long.  
> >     
>
> I think that argument is bogus. It is only the toolchain distro maintainers
> and the avr-libc developers that have to eat up that time. I think that is
> reasonable considering the value of the feature. Besides, we need to get you
> a faster machine, Joerg. ;-)
>
> IMHO, the biggest issue is the amount of developer time needed to make the
> change, the resulting testing, and the other reason you mention below:
>  
>   
> > If we were to change the model to a per-device library one, we'd also
> > have to think of a good transition scheme, because this library model
> > scheme is hand-wired into the GCC (compiler driver) code.  So it's not
> > only we need a new avr-libc but also a new GCC.  One possible option
> > for that is to start with avr-libc building per-device *and*
> > per-architecture libraries for quite some time, and only then start
> > modifying GCC.
> >     
>
> And *that* is the biggest reason why it hasn't been done yet. Coordinating
> the two projects.
>   
Maybe we must make a separation between peripheral drivers and the 
library functions.
There are basically two area's why per device is desirable: different 
instruction set's  (movw&mul)

And different peripherals requiring different approaches. (I regard 
eeprom as a peripheral here)
The trouble off the different instruction sets is tackled by the 
architectures.
However trying to bundle the peripherals is now breaking avr-libc. At 
the moment I can only see eeprom as a supported peripheral over all 
devices. Maybe fuse read support would be peripheral support. I am not 
pleading to implement all peripherals, just a valid reason not to 
implement a true per device lib. But merely a 
per-device-lib-for-the-peripherals.
Since the peripheral differ most it seems legal to split it this way.

Just my 2 cents.

Wouter