AVR Freaks

As you said earlier this is certainly possible in C++ as the '[]' indexing operation can be implemented by the programmer.

[x] and [y] would just be broken down into actual_bitarray[x/8] and actual_bitarray[y/8] with the mask for the bit access created using (1 << (x|y % 8)) just as I showed above. However this will involve a run-time calculation of (1 << n) which could be costly though the obvious { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 } lookup table solution could mitigate some of the over-head of doing run-time shifts.

I guess it depends what is important to the implementor: speed, size or ease of maintenance. I would tend to favour the latter myself unless these bit-vars were being used in a particularly speed-sensitive area.

Of course one solution to all this is just a "char array[240];" in which you simply store 0's and 1's or perhaps even '0's and '1's (for easier debugging) but that traded RAM usage for ease of implementation and speed of access. I know some people's heads might explode at the prospect of wasting every 7 of 8 bits though!

I guess it depends what one means by "big"? ...

$ cat avr.c
#include <avr/io.h>

uint8_t masks[] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 };


int main(void) {
    while(1)
        PORTD = masks[PINB];
}

00000082 <main>:
uint8_t masks[] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 };


int main(void) {
    while(1)
        PORTD = masks[PINB];
  82:	e6 b3       	in	r30, 0x16	; 22
  84:	f0 e0       	ldi	r31, 0x00	; 0
  86:	e0 5a       	subi	r30, 0xA0	; 160
  88:	ff 4f       	sbci	r31, 0xFF	; 255
  8a:	80 81       	ld	r24, Z
  8c:	82 bb       	out	0x12, r24	; 18
  8e:	f9 cf       	rjmp	.-14     	; 0x82 <main>

$ cat avr.c
#include <avr/io.h>
#include <avr/pgmspace.h>

uint8_t masks[] PROGMEM = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80 };


int main(void) {
    while(1)
        PORTD = pgm_read_byte(&masks[PINB]);
}

00000074 <main>:
  74:	e6 b3       	in	r30, 0x16	; 22
  76:	f0 e0       	ldi	r31, 0x00	; 0
  78:	ec 5a       	subi	r30, 0xAC	; 172
  7a:	ff 4f       	sbci	r31, 0xFF	; 255
  7c:	e4 91       	lpm	r30, Z+
  7e:	e2 bb       	out	0x12, r30	; 18
  80:	f9 cf       	rjmp	.-14     	; 0x74 <main>

Virtually identical apart from LPM versus LD.

(wonder why one is Z and the other Z+ ??)

Yup, odd isn't it - but the compiler really did generate this - however I have to admit it was an old 4.5.3. It's possible that if this is an error it has been fixed.

EDIT: yup, this from 4.9.2:

00000074 <main>:
  74:	e6 b3       	in	r30, 0x16	; 22
  76:	f0 e0       	ldi	r31, 0x00	; 0
  78:	ec 5a       	subi	r30, 0xAC	; 172
  7a:	ff 4f       	sbci	r31, 0xFF	; 255
  7c:	e4 91       	lpm	r30, Z
  7e:	e2 bb       	out	0x12, r30	; 18
  80:	f9 cf       	rjmp	.-14     	; 0x74 <main>

No "+"

While I enjoy your posts, don't get too evangelical.  If you change one line of your ASM, your worst case timing could go 10 times up.  You never know whether your ASM is smart code or not.

[Indeed, I've worked with a handful of gurus that think in machine op codes.  You may well be one of them.  Us mere mortals can never hope to match your efforts, no matter what language and toolchain.  But the majority of programmers, ASM or not, are not such gurus.  And so the old argument goes...the ASM program has many more lines thus many more chances for error.  But putting that aside for now...]

OP has expressed the desire for ~240 bit variables.  sparrow2, you've taken shots at proposed C implementations, and hinted at "better" ways.  Show a code fragment of your "better" approach for 60 to 64 bytes of bit variables on an AVR8.

[LOL -- back in a prior life in CNC/PLC world, my company did it with SRAM "dual port" for lack of a better term.  It could be looked at via the traditional byte view.  And extra decoding hardware gave it a bit view.  IIRC it was patented.  It made for the [at the time] fastest ladder logic scan time in the industry.]

Ooops -- can't divide by 8 in my head.  Must have used C.  In ASM, it would be

Show a code fragment of your "better" approach for 30 to 32 bytes of bit variables on an AVR8.

Agreed.  But OP implied not constant...

Interesting.  I'll have to digest that a bit. [pun intended]  Using the high 3 bits for the bit instead of the low is akin to doing any array row/col or col/row -- doesn't really matter as long as you are consistent.  A quick peek indicates constant 7 cycles (plus register save/restore if needed and the "array index" creation/load into the working register).

Apparently gcc has no AVR-specific optimization code for shifting.

Not until someone has enough desire to develop it and then donate it back to the GCC project ;-) 

GCC does suffer a little from the fact that it is a multi-language, multi-architecture compiler system so it doesn't just compile direct from C to AVR (or any specific target) Asm but breaks whatever language  (C, C++, Ada, Fortran, Objective C, whatever) into an intermediate, generic language breakdown called GIMPLE then it uses a target specific code generator to generate AVR asm code from that. So it's possible this process is sub-optimal for the specific combination of C and AVR. What's more the system tends to be biased towards the important targets (ARM, X86) which may actually be detrimental to a trivial target like AVR. 

A compiler specifically for AVR like Codevision could well have advantages because of this. 

While it's not a great idea to start a compiler war I think pretty much everyone who uses AVR knows that when size (speed?) really matters it is worth paying the $3000+ for a copy of IAR. But how desperately do you need to save a few bytes/cycles to justify that kind of cost? 

I think all the compilers have Eval versions so the real test is to download all of them and try them with the specific style of code YOU write (on the whole forget published "benchmarks", it's rare for them to reflect YOUR code style).