AVR Freaks

I cannot reproduce your results, using my vanilla test project, Studio 7, "right out of the box".

#include<avr/io.h>

int main () {
  7a:	98 e0       	ldi	r25, 0x08	; 8
	/* Sample bits */
	uint8_t c = 0;
  7c:	80 e0       	ldi	r24, 0x00	; 0
	for (uint8_t i = 0; i < 8; i++) {
		/* Take sample */
		//c >>= 1;
		c /= 2;
  7e:	86 95       	lsr	r24
		if ( PIND & (1 << PIND6) ) {
  80:	4e 99       	sbic	0x09, 6	; 9
			c |=  0x80;
  82:	80 68       	ori	r24, 0x80	; 128
  84:	91 50       	subi	r25, 0x01	; 1
#include<avr/io.h>

int main () {
	/* Sample bits */
	uint8_t c = 0;
	for (uint8_t i = 0; i < 8; i++) {
  86:	d9 f7       	brne	.-10     	; 0x7e <main+0x4>
		if ( PIND & (1 << PIND6) ) {
			c |=  0x80;
		}
	}
	return c;
  88:	90 e0       	ldi	r25, 0x00	; 0
  8a:	08 95       	ret

0000008c <_exit>:
  8c:	f8 94       	cli

0000008e <__stop_program>:

No promotion; no register-whomping.  Is the -mint8 a default?

 

I don't see it in the compile options:

        Building file: .././main.c
        Invoking: AVR/GNU C Compiler : 5.4.0
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\include"  -Os -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atmega328p -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATmega_DFP\1.2.132\gcc\dev\atmega328p" -c -std=c99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c"
        Finished building: .././main.c

 

Time for the OP to post his toolchain version!

 

Jim

 

Just to point out that I have a sneaking suspicion that El Tangas (being a great fan of such things) may actually be using the C++ compiler not the C compiler (so main.cpp rather than main.c). C++ is a whole new ball game as it is much more stringent about types/promotions etc.

 

EDIT: yup just run the experiment with main.cpp and /2 is the LSR but >>1 is the messy stuff

 

EDIT2: I don't know enough about C++ to know if the generic << operator (not one associated with a specific class of object) can be overloaded but you could maybe envisage a situation where you redefine a specifically uint8_t variant of it that sticks to byte wide operation perhaps?

 

EDIT3: you say >>, I say <<, let's call the whole thing off! :-)

In this case, the bloat is a compiler thing,

not a language thing.

It might depend on optimization flags.

avr-g++ might have different defaults from avr-gcc.

Again, this is where the commercial specifically-focussed AVR compilers can win.

 

Whether any gain is worth the price tag is another question ...

 

To be clear: the avr-gcc version is standard-compliant: c gets the correct values and all the other side-effects are the same.

not willing to accept changes specifically for some no-name 8bit micro that no one has ever heard of

They need to get educated!  However, I suppose we get what we pay for in compilers...can't complain too much when free.

We'll see how long free is supported by microchip.

Indeed - see #2, #4, #13

That's what I said. The C++ folks are only interested in ensuring the x86/64/ARM versions are standards perfect. The AVR8 is an irrelevance so they wouldn't contemplate taking on board any change to make AVR8 more efficient at the risk of it perturbing the important versions of the tool. For example they wont accept __flash.