AVR Freaks

Yes, you can even do this in Keil.
But you don't really have a single-bit variable; you just have a name for a bit-field within a larger variable
This is usually implemented with (at least) byte-wide shift and/or mask operations (even Keil) - so it gains nothing. In some cases, it is actually better to write it yourself with standard 'C' bitwise operators! :(

What Keil (and other 8051 compilers) gives you is a 'C' language extension that gives you acces to the single-bit instructions of the 8051.

> This is usually implemented with (at least) byte-wide shift and/or
> mask operations (even Keil) - so it gains nothing. In some cases, it
> is actually better to write it yourself with standard 'C' bitwise
> operators!

For AVR-GCC (to get back on-topic), there's no "bit"-organized memory
area in the processor anyway, but there are quite efficient bit access
methods to registers (and IO registers). GCC uses them whenever
possible in bit operations. So really, both the bitfield approach as
well as standard C bit manipulation operations all yield the same
efficiency in access, and compared to the rather slow (standard)
MCS51, they are probably even way faster anyway.

If Keil differs between standard bit operators and bitfields in the
efficiency of the generated code, I'd rather take that as an
indication of design problems inside that compiler. The way the C
programmer expressed itself to achieve a certain goal should not make
a difference to the compiler's code generation, at least for obvious
cases like this one.

> could you be more precise about what sort of C-code 'performs'
> better when compiled by GCC? Would be very informative.

Unfortunately not. First, this code is (currently) proprietary,
second, it's a large state machine with several actions and quite long
and windy code paths, so it's impossible to ``just extract'' the part
in question as a showcase.

> ... up to now have _always_ found that the IAR-apple was 'better'
> than all the other oranges ...

Me, too, the more I have been surprised this was not the case for that
project. We didn't do an in-depth analysis, we write the code and
compile it with GCC all the time, yet we take care to keep it IAR
compatible. At a particular point, we noticed there is a timing
problem, so we started optimizing all parts contributing to that. So
we eventually ended up improving the timing from an original ~ 800 µs
response time down to the ~ 200 µs we were supposed to get at. Only
then we also verified IAR again. As the timing of the IAR-generated
code was still within our target window (though worse than GCC), we
didn't try to make compiler-dependent optimizations. (The
optimizations were real optimizations, not just fiddling slightly with
the code. The biggest saving was done by avoiding an overcautious
memset(), only 1 line of C code resulting in 5 lines of assembly code,
but that took 185 µs. We eventually had to review any code on the
critical path, to save 20 µs here and 15 µs there.)

> According to ANSI C standard, an "int" is signed 32-bit integer.

Your knowledge of the C standard appears to be not much more advanced
than your name is...

IOW, that statement is *completely* wrong.