Re: [avr-libc-dev] more ac branch updates

[Theodore A. Roth]

On Sun, 2 May 2004, Theodore A. Roth wrote:

> > > Hmmm, 'mkdir -p' might be a portability issue too.
> >
> > Probably more than <<-EOF, albeit any recent Unix I've seen implements
> > this one, too.  The oldes system I've got access to is an HP-UX 10.20,
> > it already has got mkdir -p.
> >
>
> Ok. I'll rewrite that stuff then. We'll probably never hit those fringe
> cases, but these are really trivial things to catch now.

Ok, I've committed some fixes for this stuff.

>
> > > Maximal portability is not a concern though unless we decide to stick
> > > with the avr/ tree generator script permanently. I'd rather use python
> > > for this script, but I don't want to force that requirement on too many
> > > people.
> >
> > As long as the script remains that simple, I'd stick with plain Bourne
> > shell syntax for it.  Btw., I'm perfectly happy with creating the
> > compilation dir hierarchy using a script (as opposed to maintaining it
> > completely in CVS).
>
> I think the scripted method will be easier to maintain in the long run
> since global changes to the build dir will be centralized instead of
> spread across more than 35 directories.

I've also committed some changes removing the notes about temporary
aspect of this since it sounds like we're going to go with the generator
script long term.

Another change I've made is to add the device specific CFLAGS to the
generator script. There is a little snag here. Consider the command for
compiling the vfprintf_std.o file:

  avr-gcc -DHAVE_CONFIG_H -I. -I../../../../avr/lib/atmega128 -I../../..
  -I../../../../common -I../../../../include  -g -Wall -W
  -Wstrict-prototypes -mmcu=atmega128  -O3  -O1 -mno-tablejump
  -DPRINTF_LEVEL=PRINTF_STD -c -o vfprintf_std.o
  ../../../../libc/stdio/vfprintf.c

I'm not very comfortable with the fact that the optimization turns out
to be '-O3 -O1'. It looks like gcc ends up using the -O1 in this case:

-rw-r--r--    1 roth     users        7680 May  3 11:43 vfprintf_std.o-O1
-rw-r--r--    1 roth     users        7812 May  3 11:44 vfprintf_std.o-O3
-rw-r--r--    1 roth     users        7680 May  3 11:43 vfprintf_std.o-O3-O1

But, I don't like the long term prospects of assuming this gcc
behaviour. I'd don't see an obvious way to fix this, except for not
using $(COMPILE) in the libc/stdio/Rules.am file, which less than
optimal.

Hmmm, I just noticed that this comment in libc/stdio/Rules.am:

  # vfprintf is compiled best with -O1 -mno-tablejump, this gives the
  # smallest code.

is not necessarily true. I just compiled with -Os instead of '-O1
-mno-tablejump' and got this:

  $ avr-size vfprintf_std.o-O*
   text    data     bss     dec     hex filename
   1408       0       0    1408     580 vfprintf_std.o-O1-mno-tablejump
   1468       0       0    1468     5bc vfprintf_std.o-O3
   1408       0       0    1408     580 vfprintf_std.o-O3-O1-mno-tablejump
   1284       0       0    1284     504 vfprintf_std.o-Os

Any comments are where to go with this?

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