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

[Joerg Wunsch]

[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.]

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.

> 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

> 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 (soon to be three, so I'm catching up with Eric ;-)
spare-time isn't an unlimited resource.

> 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.  So unlike your
old days, Marek, we're IMHO in a much better situation these days.
For the remaining 1 %, another 95 % of them will be Unix users who are
used to compile the latest and greatest stuff from source, so only a
very small minority will end up with mutually incompatible parts of
the toolchain.

> 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?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)