Re: [avr-libc-dev] RFC: avr/bits.h

[Joerg Wunsch]

As Nicolas Schodet wrote:

> > There's a paragraph in the FAQ that explains why interrupt flags
> > are written as 1 [...]

> I mean, if there is a new bit manipulation header, it could be a
> good idea to warn user about this or to add a link to the FAQ.

Well, yes, why not.

> > > Another question about bit manipulation: what is the best way to
> > > read 4 bytes into a double word?

> > IIRC, a union works best.

> Yes, it work best because the code generated by gcc is not very
> good, but the source is then non portable.

I highly doubt the union would make it less portable across the AVR
compilers, compared to other things like interrupt syntax.  I don't
think any of the existing AVR compilers would implement the union
mapping differently than GCC does right now.

> Gcc (3.4.3) miss even very simple optimisations, I am missing
> something?

If you read the recent threads in the avr-gcc-list, it seems much has
been done to improve the situation for GCC 4.  Actually, from my own
observations, GCC 3.4 was about the worst in terms of optimization for
the AVR target, versions prior to it usually optimized better
(sometimes a lot better).  OTOH, I seem to remember Dmitry recently
discussed that on avr-gcc-list, and found also some things where 3.4
performs better than 3.3 did.

> I had better confidence in compilers before, is it general to gcc or
> just specific to avr-gcc?

My guess is that GCC 3.4's development has mainly been motivated by
the need to fix all the bugs in the AMD64 code generation, and to get
at least a moderate degree of optimization for that target which is
still a relatively young yet increasingly important target for GCC.
Remember, the AVR target for GCC is maintained by only very few
people, and is really anything else but a major target for GCC.

Eric has plans to improve this situation for future releases. ;-)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)