There is a line where I could use either a right shift by 1 or divide by 2, and I expected avr-gcc to generate the same code due to optimizations. But to my surprise, the code using the division is better than the shift one!

I tried several versions of avr-gcc. The shift code is worse because the uint8_t variable is promoted to 16 bits, shifted, then cropped back to 8 bits:

This makes quite a difference on a tight loop where timing is quite critical. I don't understand why the variable is promoted to 16 bits in the shift case, maybe the C standard mandates this? Opinions welcome.

OK, so the standard mandates promotion to int, but then some optimization pass notices this is not needed, but only for the division, the shift is left as 16 bits. I found the avr-gcc option "-mint8" but it's just too blunt to be used, it makes the size of every int 8 bits.

The problem seems to be that the promotion of unsigned char to int changes the signal behaviour and this confuses the optimizer.

Moreover, the promotion is costly because new registers are allocated. If we start with an int variable, that is:

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?

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?

And here for a decade or more Johan has been trying to pound "no bloat" into us. "Fake news."

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

I think it's widely understood that avr-g++ is not as "honed" as avr-gcc. In part this is because the C++ team are sticklers for adherence to standards and are not willing to accept changes specifically for some no-name 8bit micro that no one has ever heard of that might upset their standard compliance (even if it might make for more efficient code for that specific target).

Bottom line, you aren't going to turn the oil tanker!

(there's quite a lot of scope for making efficiency changes to avr-gcc if you are happy to stick with C)

the [GCC] C++ team are sticklers for adherence to standards and are not willing to accept changes specifically for some no-name 8bit micro that no one has ever heard of that might upset their standard compliance (even if it might make for more efficient code for that specific target)

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

I don't think the C++ standard requires generating inefficient code. Both C and C++ are all about speed. More likely there just hasn't been as much work on making the same optimizations that are already present in the C compiler.

I don't think the C++ standard requires generating inefficient code. Both C and C++ are all about speed. More likely there just hasn't been as much work on making the same optimizations that are already present in the C compiler.

--Mike

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.

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

I'll bet they are probably really just upset they never got a t-shirt...payback

When in the dark remember-the future looks brighter than ever. I look forward to being able to predict the future!