[Top][All Lists]

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

Re: [avr-gcc-list] Global variables and ISRs ???

From: David Brown
Subject: Re: [avr-gcc-list] Global variables and ISRs ???
Date: Thu, 8 Sep 2005 13:01:22 +0200

----- Original Message -----
From: "Vincent Trouilliez" <address@hidden>

> On Wed, 2005-09-07 at 16:41 +0200, Joerg Wunsch wrote:
> > "David Brown" <address@hidden> wrote:
> >
> > > ..., and it will also change "multiply by constant" into a series of
> > > shifts and adds.  The target chip has a hardware multiplier and
> > > divider, but they are slower than the shift-and-add sequences.
> >
> > Unfortunately, AVR-GCC also does this, even though the hardware
> > multiplier is faster than a series of shift and add. :-(
> Oh noooo, that's crap :-(

Maybe I'm missing something, but when testing with avr-gcc 3.4.1 (from a
fairly recent winavr release) with -Os or -O2, that is not the case.  I've
tested with a series of code such as:

static unsigned char a, b;
void test3(void) { a = b * 3; }

When compiling for the AT90S8535 (not hardware multiplier), a series of
shifts and adds/subs is generated whenever there are no more than two
add/subs needed.  When more than two are needed (e.g., for *13), a call is
made to a general multiply routine.  This sounds reasonable to me - if only
it would stick to 8 bits rather than promoting everything to ints (I haven't
found a way to avoid this).

When compiling the same code for the ATMega128, "mul" instructions were
generated every time, using 8-bit arithmetic.  For the case of x3 at least,
a shift-and-add would have been slightly smaller and faster (using 8-bit
arithmetic), but otherwise the code is fine.

So as far as I can see, the only real issue is that the compiler can't see
that the shift-and-add sequences can be done as 8-bit, even though it does
the "mul" code as eight bit.

I re-compiled using -mint8 for comparison.  With the AT90S8535, the choice
for shift-and-add or library call was the same, but the code was much better
(being 8-bit).  With the ATMega128, the compiler now generates shift-and-and
code like for the AT90S8535, or "mul" code, depending on the number of bits
in the multiplicand.  For some multiplicands, like x9, the shift-and-add
method is one instruction longer than the "mul" method would have been.

> Can't we just have an command line option to force the use of the H/W
> multiplier ? How should we do to submit this as a top-priority goal for
> the next release of avr-gcc ? Is anyone in the avr-gcc team on this
> list ?? This needs to be addressed ! :-/

I think most or all of the avr-gcc team follow this list.  They are always
interested in ideas leading to a better compiler, but it is up to *them*
what is "top-priority".  You are always free to actively help the
development (including things like documentation, if you don't want to get
involved in the code) and get more of a say on what's important.  Otherwise,
like me, you can content yourself with helping testing, giving ideas, trying
to help others on the lists, and thereby giving a little back.  Remember you
are getting a great deal for free here, so it's polite to ask, rather than



reply via email to

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