Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>

[E. Weddington]

Joerg Wunsch wrote:

> [Btw., thanks for taking the time to participate a bit more in this
> kind of discussions again, now that Ted had to move off the list.
> Much appreciated, Marek.]
>
>  
[ And I second that, too!]

> As Marek Michalkiewicz wrote:
>
>  
>
> > > As a side OT note: This is another desired feature, to go to
> > > per-device multi-libs. And perhaps this can be done in conjunction
> > > with a possible move to newlib.
> > >      
>
>  
>
> > With the large size of newlib compared to avr-libc, and Atmel making
> > lots of new devices easily (where often a few variants differ only
> > in memory sizes), I'm a bit worried about the total size and build
> > time...
> >    
>
> Yeah, Ted's last estimates already turned out into something like 15
> minutes compile time for avr-libc on a medium-sized computer.  You're
> probably right.
>  

And, so?
It already takes long enough to build GCC. 15 minutes to build avr-libc 
is comparable. Besides as you say below, pre-made distributions have to 
deal with the time issue, not the general users.

I really think that the size, and the time issue is no problem.


>  
>
> > As I proposed
> > some time ago - instead of a flat list, multilibs should ideally be
> > based on a few independent properties of a device:
> >    
>
>  
>
> > - MOVW supported: yes/no
> > - MUL (etc.) supported: yes/no
> > - stack pointer: 16-bit/8-bit  (possibly make all pointers 8-bit
> >   on such small devices - but, this might break some code which
> >   assumes that pointers are the same size as "int"...)
> > - max program memory size: 8M/128K/8K
> >    
>
> The only problem I'm seeing as that you never know which new
> differences you might encounter on the next Atmel.  There was already
> a remark about one device (was it the secure AVR?) that's got a couple
> of other instructions unknown to current AVRs.  Ah yep, SBRA and CBRA,
> see here:
>
> http://www.avrfreaks.net/phpBB2/viewtopic.php?t=24957
>  

I agree with Joerg. Because we cannot predict what Atmel will do, I 
hestiate to make a change to some other arbitrary organization, just to 
get burned by Atmel again.




>  
>
> > The "really per-device" stuff (interrupt vectors, EEPROM access,
> > timers, etc.) could go into separate, small per-device libraries.
> > This would be instead of the current crt*.o files (just more
> > flexible - libraries instead of single object files), and since
> > this is mainly assembler code, it is small and fast to build.
> >    
>
> OK.
>
>  
>
> > This could be made a separate package (not part of newlib), along
> > with the AVR-specific header files.  Only that package (and not
> > newlib itself) needs to be modified to add support for new chips.
> >    
>
> Hmm, but I'd definately want this to be maintained along with newlib,
> otherwise we end up in maintaining even more software packages than we
> maintain right now.  If newlib isn't flexible enough to handle
> per-device subtrees, well maybe either we can manage them to agree, or
> I'm rather inclined to keep the current avr-libc project as it is.
> I've already got too many spare-time jobs at hand.  With a couple of
> small kids <removed for privacy> ;-)
> spare-time isn't an unlimited resource.
>
>  
I agree with Joerg on this.

I would strongly suggest going to per device libs. Don't organize it 
along other arbitrary lines that Atmel doesn't support. One big 
advantage is that subsystems can be enhanced or new ones made that can 
be made flexible according to the device used. For example, the EEPROM 
routines. Right now those routines depend on fixed locations of the 
EEPROM system registers, which are in different locations in some 
devices. Having a per-device lib means that EEPROM routines could be 
made to work with any AVR device that Atmel makes, and as soon as they 
release the spec. Other subsystems can be built the same way.

So it would have to be:
1. Newlib accepts everything, per-device subtrees, etc.
2. Keep avr-libc as is and modify it to do what we need.

I only want *one* project to update. Not *two* or more.

> > The main problem with all this is backwards compatibility.
> >    
>
> I'm not too much concerned about that.  After all, keep in mind that
> the vast majority of people is likely to use pre-defined or
> pre-compiled toolchain kits.  If we can manage it to settle WinAVR
> (Eric), cdk4avr (Stephan), the FreeBSD ports (myself), and maybe
> whatever is used on MacOS X (any maintainer over here?) to ship a new
> version of all required tools by the same time, we've got pretty much
> a coverage of probably 99 % of our user base by this.
>  
I'm only slightly concerned with backwards compatibility. I would want, 
for example, the headers to be installed in the same location, so a 
program that builds with the current toolset could be built with a 
toolset built with newlib. And also the libraries to be found in the 
same locations as well.


> > This time, I'd suggest only _one_ ld emulation (with the maximum
> > possible memory sizes in the linker script).  Doing it per-device
> > (as was the case in the past) has already turned out to not scale
> > well.
> >    
>
> Can you elaborate?  What would be the maximum possible size, 8 MB?
>
>  

And, more importantly, can this be done now? (Without moving to newlib.)

Thanks
Eric