Re: [avr-gcc-list] Compiling for MEGA128 on Freaks Experimental Release

[Marek Michalkiewicz]

> I now found out what else was wrong with the watchdog: WDTOE does not
> exist on MEGA128 (Atmel renamed it ..)
> So, besides the fact that wdt.h does not work at all (divisor is not
> loaded), you can't even compile it.
> (Does no one use this bloody thing ??)

OK, I'll fix it - it worked with old chips, and was not updated...

> 2. __inw_atomic (in fact all the atomic stuff) does not exist anymore,
> at first I thought I had to include iomacros.h (used to be automatic)
> but that just causes much more problems. Is there another function for
> this ? Must the user provide for cli / sei ?
> The "inw(sfr)" in sfr_defs.h is not secure as far as I can tell.

Well, all this has been rewritten without using "asm" so __inw_atomic
disappeared.  Anything that starts with two underscores is subject to
change anyway...  If accessing 16-bit I/O registers both in interrupts
and in the main program, you need to protect inw/outw with cli/sei.
Same goes for any global variables larger than 8 bits, accessed from
both interrupts and the main program (only 8-bit accesses are atomic).

> For the rest, the project compiles with an amazing result; original
> code size: 38822 bytes, new size: 38824 bytes. (Both using -O2)

Try -Os and -fno-reorder-blocks (as I discovered, the latter made
my ~8K application about 100 bytes smaller, as GCC tried very hard
to rearrange the code to avoid taken branches, but this loses on
the AVR as branches are cheap compared to most larger processors).

> I was hoping for the -O3 option to have been fixed but that one
> generated 88K worth of code, not exactly optimised I'd say.

Might be optimized for speed, by unrolling loops with known repeat
count, inlining whole functions, etc.  But, if you have specific
test cases showing obviously bad optimization, please let me know.

Thanks,
Marek

avr-gcc-list at http://avr1.org