This perfectly illustrates the point that it's not the language that matters ('C', assembler, whatever), but the skill and experience of the programmer.

Of course, anyone experienced in language-1 but inexperienced in language-2 will do things better in language-1 than language-2 - whether that's porting, writing efficient code, or whatever.

This is where the fallacy of "Assembler gives tighter code" lies; I've said it many times before - it's not Assembler itself that gives tighter tighter, it requires a skilled & experienced assemlber programmer to do it.

The same applies to writing "portable" code in 'C' - as Erik so often says, if you just assume that your code must be inherently portable simple by virtue of writing it in 'C' ("C is C"), then you are seriously mistaken!


This is what I meant by doing your 'C' code carefully!

The 'C' standard specifically states that the sizes of the data types are implementation-defined (it requires a minimum of 16 bits for int; but nothing else)

The first step to portable 'C' is to never use the standard types - int, long, etc - always define your own of known signednes and size; eg,

typedef unsigned char     U8;
typedef   signed char     S8;

typedef unsigned short   U16;

(or use the C99 well-defined types, if your compiler supports them)

Similarly, all other implementation-specifics need to be isolated in #defines or similar.


I think you'll find that this is all standard 'C' behaviour, or documented implementation-specific behaviour.

It seems to me that that AVR-GCC places more importance on standards-compliance than on efficient code generation...