[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 ;-)
Marek
- [avr-libc-dev] Patches to add mega325-3250-645-6450 to binutils and gcc., E. Weddington, 2005/03/04
- [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Marek Michalkiewicz, 2005/03/04
- [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., E. Weddington, 2005/03/04
- [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., E. Weddington, 2005/03/04
- [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Marek Michalkiewicz, 2005/03/04
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Joerg Wunsch, 2005/03/10
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc.,
Marek Michalkiewicz <=
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., E. Weddington, 2005/03/15
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Joerg Wunsch, 2005/03/15
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Marek Michalkiewicz, 2005/03/15
- Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc., Dmitry K., 2005/03/23