Re: [avr-libc-dev] build per arch

[Theodore A. Roth]

On Fri, 23 Apr 2004, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > or maybe like this:
> >
> >   ./avr5/atmega128/libc.a
> >   ./avr5/atmega128/libm.a
> >   ./avr5/atmega128/libprintf_min.a
> >   ./avr5/atmega128/libprintf_flt.a
> >   ./avr5/atmega128/libscanf_min.a
> >   ./avr5/atmega128/libscanf_flt.a
> >   ./avr5/atmega128/crtm128.o
>
> Now, that gets me an idea.
>
> What about sticking to the `arch' model in general but allowing for a
> kind of per-MCU override?
>
> So the layout (dirs only) could look like
>
> ./avr2
> ./avr3
> ./avr4
> ./avr5
> ./avr5/atmega169
> ./avr5/at90can128
>
> The compiler passes both, the -mavrN plus the -mmcu= option to the
> linker, and if the linker finds a subdir that is more specific, it can
> use that one, otherwise it resorts to the per-arch subdir.
>
> That has the added benefit that the binutils (ld) change could be
> decoupled from the respective GCC change: if an old compiler works
> against a new ld, it'll just pass the -mavrN option only, and the
> linker will behave as it used to do by now.  Only the new compiler
> requires the updated ld (since the old one would not understand the
> -mmcu option).

We could try that, but I think it adds another layer of complexity we
don't need.

It also limits flexibility. I'd rather move the SP, SREG, EExx reg defs
out of io.h and back into the device header. Then when you build the
crt and libs for each devices, there's no guessing as to where the
registers are and we have full access to all registers. Since Atmel
seems to move registers on us willy-nilly, it makes all the code in the
libs a bit more flexible to just compile everything with -mmcu=<dev> and
avoid the -mavrN stuff.

I know Marek had moved over to the avrN stuff to make thing simplers
from a maintenance point of few, but I think that move hinders what we
can do in the libs provided by avr-libc.

>
> avr-ld -mfoo says:
>
> avr-ld: unrecognised emulation mode: foo
> Supported emulations: avr85xx avr1200 avr23xx avr44x4 avr4433 avrmega603 
> avrmega103 avrmega161 avr1 avr2 avr3 avr4 avr5
>
> Hmm, time to drop the ancient avr85xx ... avrmega161 options, too. ;-)

Marek did that a while ago:

$ avr-ld -mfoo
avr-ld: unrecognised emulation mode: foo
Supported emulations: avr2 avr1 avr3 avr4 avr5
$ avr-ld --version
GNU ld version 2.14.91 20040415

>
> > Of course, this will cause the build to take a considerly long time, but
> > who cares, we've all got 3 GHz systems by now, right? 8-)
>
> I've always got the impression that 2/3 of the overall compilation
> time are taken by the two runs of doxygen (plus two LaTeX runs)
> anyway.  Well, and by sending the output to the tty :) (can seriously
> increase your compile time if the output goes across a slow line).
>

That's a fixed cost. Take the 1/3 for the 4 arches and multiple by
(~35 devices)/4. Approximately.

Doing a clean build with all dox on a PIII-450:

real    4m51.404s
user    2m16.160s
sys     0m15.530s

To do a clean build without dox:

real    1m54.788s
user    0m50.230s
sys     0m12.310s

Just the dox:

real    2m59.995s
user    1m26.980s
sys     0m2.810s

I'm guessing about 15-20 minutes + dox time on this system. :-(
Luckily, my system at home is considerably faster.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden