AVR Freaks

My guess is, that the compiler splits the statement into two parts. First, the program needs to isolate bit n, and keep it in a location where it can find it again. Apparently, this must always be in bit 0. Only after this is done, the compiler starts looking at the destination variable. This action is almost completely split from the first part, so the compiler must rely on the bit being bit 0.

 

That sounds about right:

1. Load the bitfield.  That means load the storage containing the bitfield, shift its LSB down to bit 0, and remove other bits.  That's exactly what you'd need to do for "int i = testsource.bitf;"
2. store the value (no longer a bitfield, really) into another bitfield.

Don't forget that bitfields are not always single bits.

It'd be nice if it optimized better, but it's not really surprising that it doesn't.

Strange. I'm using this test code:

struct tTestBitfield
{
	unsigned char Bit0:1;
	unsigned char Bit1:1;
	unsigned char Bit2:1;
	unsigned char Bit3:1;
	unsigned char Bit4:1;
	unsigned char Bit5:1;
	unsigned char Bit6:1;
	unsigned char Bit7:1;
};

volatile struct tTestBitfield TestSource;
volatile struct tTestBitfield TestDestination;

int main() {
	TestDestination.Bit3=TestSource.Bit0;
}

and I'm getting the optimized version. I'm also using -Os and the native avr-gcc that comes with AS7 (5.4.0). I have newer versions of avr-gcc that also give the optimized version.

edit: oops, disregard. So the code changes with the bits that are moved. Yeah, it's weird.

edit #2: I've confirmed that this is a problem of v 5.4.0 and is fixed in newer versions, for example using 7.3.0, this

	TestDestination.Bit3=TestSource.Bit0;
	TestDestination.Bit3=TestSource.Bit1;
	TestDestination.Bit3=TestSource.Bit2;
	TestDestination.Bit3=TestSource.Bit4;

compiles to:

 10a:	90 91 01 02 	lds	r25, 0x0201	; 0x800201 <TestSource>
 10e:	80 91 00 02 	lds	r24, 0x0200	; 0x800200 <_edata>
 112:	90 fb       	bst	r25, 0
 114:	83 f9       	bld	r24, 3
 116:	80 93 00 02 	sts	0x0200, r24	; 0x800200 <_edata>
 11a:	90 91 01 02 	lds	r25, 0x0201	; 0x800201 <TestSource>
 11e:	80 91 00 02 	lds	r24, 0x0200	; 0x800200 <_edata>
 122:	91 fb       	bst	r25, 1
 124:	83 f9       	bld	r24, 3
 126:	80 93 00 02 	sts	0x0200, r24	; 0x800200 <_edata>
 12a:	90 91 01 02 	lds	r25, 0x0201	; 0x800201 <TestSource>
 12e:	80 91 00 02 	lds	r24, 0x0200	; 0x800200 <_edata>
 132:	92 fb       	bst	r25, 2
 134:	83 f9       	bld	r24, 3
 136:	80 93 00 02 	sts	0x0200, r24	; 0x800200 <_edata>
 13a:	90 91 01 02 	lds	r25, 0x0201	; 0x800201 <TestSource>
 13e:	80 91 00 02 	lds	r24, 0x0200	; 0x800200 <_edata>
 142:	94 fb       	bst	r25, 4
 144:	83 f9       	bld	r24, 3
 146:	80 93 00 02 	sts	0x0200, r24	; 0x800200 <_edata>

Here's another take on this problem:

There is an avr builtin for this https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html#AVR-Built-in-Functions

uint8_t __builtin_avr_insert_bits (uint32_t map, uint8_t bits, uint8_t val)

Insert bits from bits into val and return the resulting value. The nibbles of map determine how the insertion is performed: Let X be the n-th nibble of map

1. If X is 0xf, then the n-th bit of val is returned unaltered.
2. If X is in the range 0…7, then the n-th result bit is set to the X-th bit of bits
3. If X is in the range 8…0xe, then the n-th result bit is undefined.

One typical use case for this built-in is adjusting input and output values to non-contiguous port layouts. Some examples:

// same as val, bits is unused
__builtin_avr_insert_bits (0xffffffff, bits, val)

// same as bits, val is unused
__builtin_avr_insert_bits (0x76543210, bits, val)

// same as rotating bits by 4
__builtin_avr_insert_bits (0x32107654, bits, 0)

// high nibble of result is the high nibble of val
// low nibble of result is the low nibble of bits
__builtin_avr_insert_bits (0xffff3210, bits, val)

// reverse the bit order of bits
__builtin_avr_insert_bits (0x01234567, bits, 0)

It's a bit of an IQ Test to understand how to use it but here goes; using godbolt.org and avr-gcc-5.4.0 with -Os

#include <stdint.h>

extern uint8_t TestSrc;
extern uint8_t TestDst;

void foo () {
    TestDst = __builtin_avr_insert_bits (0xffff1fff, TestSrc, TestDst);
}

compiles to:

foo():
        lds r25,TestSrc
        lds r24,TestDst
        bst r25,1
        bld r24,3
        sts TestDst,r24
        ret

If you use it in production code (I never did) be sure to comment well your intentions because it's really hard to read.

They were never intended for that. Bit-fields is an abstract data packaging feature (for space saving purposes), not a bit-mapping feature.

BTW, in C you have '[signed/unsigned] int' bit fields and '_Bool' bit fields. For any other type you are at the mercy of your compiler. 'unsigned char' bit fields in C is non-standard - it is a GCC extension.