[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils

From: Marek Michalkiewicz
Subject: Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc.
Date: Sun, 13 Mar 2005 17:35:12 +0100
User-agent: Mutt/1.5.6+20040907i

On Thu, Mar 10, 2005 at 11:05:39PM +0100, Joerg Wunsch wrote:

> My idea was to build .o files that are known to still fit into the old
> avr2 through avr5 (6...7 -- tiny*13, mega256*) model only once, and
> just copy them over.  That should drastically speed up build for
> per-device libs.  (900 MHz Athlon here, a bit faster than your system,
> but not by an order of magnitude.)

Looks like a good solution for the build time issue, but the disk
space problem still remains.  It's not a very big problem anymore
(disk space is much cheaper than it was a few years ago), but I think
I have an idea which I think would be a good compromise (fast build,
and not much disk space needed for installation).

With a small change in LIB_SPEC ("%{mmcu=*:-lavr-%*}" added), GCC
should be able to look for a small per-device library (such as
libavr-atmega128.a) in addition to the generic (per-core) libc.a.
With the correct link order, a per-device library can override
libc.a to provide better optimized device-specific functions.

By "core", I mean a combination of instruction set, memory sizes
(program <=8K/<=128K/<=8M, data <=256/<=64K) and core I/O registers
(stack pointer, SREG) without any peripheral devices (like EEPROM) -
only these things GCC itself is concerned about.  There would be few
(about 10) such cores, handled by the standard multilib infrastructure.
The many per-device libraries would only contain really device-specific
code (if it needs #include <avr/io.h>, it is device-specific), so they
would be much smaller.

BTW, if we forget backwards compatibility with DOS 8.3, and full device
names (instead of shortened ones) become part of filenames (crtm128.o ->
crt-atmega128.o etc.), GCC spec strings could be simplified a lot, and
there would be one less place to maintain a list of supported devices.

Does this sound reasonable?  That's how I would do this if I had the
time these days... unfortunately, while I often see spam advertising
"extra time" in my mailbox, on a closer look it turns out it's not
exactly what I'm looking for ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]