AVR Freaks

Best to avoid those methinks. Simple code = simple defects.

Amen.  Remember that someday, someone who doesn't know, or doesn't remember, these sorts of cute tricks (perhaps they're barely competent in C, since Javascript and Visual Basic are their main thing) will need to read/modify/fix that code.   It might be you.

Quick: is the first number printer 10, or 9?  Is the last number 0, or 1?  (not that it's so much worse than the standardish C "for" loop...)

I wouldn't call this a hidden gem, I would call it a hidden piece of nonsense.

You could at least write it as

while (x-- > 0)

The idiom

while (x--) {}

is quite common for situations where you can loop 0 or more times (ie x can be 0).

For situations where the num of loops are known at compile time, personally I always prefer for loop, and let the compiler optimise it.

(For example, if the compiler knows you are looping 10 times it might implement the for loop in the form of do {} while(); since it knows that 10 times is definitely 1 or more times).

Thta's still undefined behaviour (modifying a twice without a sequence point in between)

We could do that a long time already as Cliff posted about his custom plate when he got it, and to me that already seems a long time ago.

thanks for the test Cliff, indeed does not seem to reduce instruction cycles nor time so it is up to the person who wrote the code as to what he found better looking.

(As another aside, and this is really something I hope is in Xilinx's new 'C for FPGAs' kit, C can't do arbitrary bit-size integers.  Just accumulating 256x of 16-bit values only needs 24 bits, but is there a 24-bit integer type?  I don't think so, so using 32 bits for a 24-bit number is inherently wasteful!  Tell that to your C compilers.  Plbbht.)  S.

Edited to add: Not that you care, but I've done work in 12 bits, 18 bits, 24 bits, 40 bits (that one was in an AVR, too)...  Yeah, given an AVR using 8-bit multiples is easier, but with arbitrary programmable logic, you can have just as many bits as you need... no more, no fewer.  That 40-bit processor would not have fit in a tiny2313 if someone insisted on using 64-bit values!

Excellent!  Now, is there a type for 22 bits or 26 bits, as implemented in a 'soft processor core' in an FPGA? 

I would also like to see a C compiler pull off my zero-cycle divide by 256.  ;-P

Here you go.   It's a shame that the compiler didn't do a better job constructing the 16bit number in the first place...

void main() {
    uint16_t x;
    x = (PORTC << 8) | PORTD;
  74:    28 b1           in    r18, 0x08    ; 8
  76:    8b b1           in    r24, 0x0b    ; 11
  78:    90 e0           ldi    r25, 0x00    ; 0
  7a:    92 2b           or    r25, r18
    PORTB = x/256;
  7c:    95 b9           out    0x05, r25    ; 5
    while (1);
  7e:    ff cf           rjmp    .-2          ; 0x7e <main+0xa>

All of which are lovely for dividing a 16-bit number by 256, but not a 24-bit number.  S.

Edited to add, once more, that the point is not necessarily sheer speed.  The point is knowing EXACTLY how many cycles you are going to get, every time.  Since I work with time-sensitive external hardware, I often throw in piles of NOP instructions to keep the speed to EXACTLY what I want it to be.  Is your compiler going to optimize out my NOPs?  If so, then I don't want it! 

I lurv "ldi r25, 0x00".  And then OR with r18?  What?  Can't 'mov' do it all?  And 'add r0, r0'?  What's r0 got to do with this?  I know the AVR has lots of registers, but this is getting silly!  Finally, a 24-bit number only needs three registers, not four.  How many registers did you use in that?  Lemme count...  r0, r18, r24, r25, r26... five?  And what's with the mov instructions?  In assembler, you don't have to move them around, because they're already where you can use them! 

And now, in pseudo-code, the same thing in assembler:

in r16, PINA

in r17, PINB

in r18, PINC

out PORTD, r17

out PORTE, r18

Any further questions?

In the very early days, the Imagecraft compiler for AVR did the same. I pointed this out to Richard and he quickly added the optimisation by byte shuffling.

Indeed it does.  As well it should.  Congrats to the compiler writers.  Of course, nobody took me up on the 'moving the loading of the source pointer out of the switch statement' remark.  You busy?  (I'm getting wildfires around and should be 350 miles away, so I'll get back to you later on that one...)  S.

If compiled as C code, it  won't compile, syntax error due to operator precedence.

Seems smart enough to me :)

Needs extra brackets, or be normal and just use if/else.

Maybe it is different if compiled as C++ (I haven't tried).

Just one of my pet hates :)

Not the ternary operator itself, I'm quite happy when you're making use of value returned eg.

x = condn ? this_value : that_value;

just never liked it for

condn ? do_this : do_that

	uint8_t parallel_data = PIND, mask = 0x01;
	while (mask) {
		(parallel_data & mask) ? (PORTB |= 0x01) : (PORTB &= ~0x01);
		mask <<= 1;

Is that one of the cases where gcc decides that you want to do something 8 times, and therefore creates an entirely unnecessary counter?

In 9 cases out of 10 GCC will much better than the user at determining it.

The problem I have there is that you don't know when it's being weird, without inspecting the asm code, which isn't that far off writing it in the first place.  Freely granted, most of the time it doesn't matter, but when it does, you might want to know.

My AVRs don't do that.  They interact with external hardware, not pushing pixels around!  If you want to push pixels, get a Rasp Pi or something, and yes, use C to your heart's content therein.

It's very rarely raw speed (is if you're calculating Mersenne primes, but that's an oddball case), it's much more frequently needing precise timing to interact with the other hardware.  Yes, it would be nice to have optimized code in the user interface.  That is absolutely not worth it if the compiler optimizes out the 'nop's that provide the precision timing!  (Oh, I'm sure there's ways to force the compiler to behave itself, but why bother fighting it?)

I like to write down not what I want the chip to do, but exactly what the chip is going to do.  So I cut out the middleman.  Call me a Luddite if you want to.  I write my AVR code in assembler.  So there.  ;-P   S.

>> I think ["register"] is largely ignored by modern compilers ... ?

Beautiful.  You think it might be, or it might not.  The compiler might care, or it might not.  It might do what you want it to do... or it might not.

"register" is quite old, but is largely obsolete because compilers have gotten much better at automatically putting variables in registers.  I don't know whether the declaration "bumps" the priority of a variable for register-ification in modern gcc, or whether it relies entirely on its own calculations.  (originally it was a "hint" that the variable would be frequently accessed.  Nowadays, the compiler figures out in detail which variables are used most...

gcc also has a global "register" variable definition, but it's not clear whether it works on variables larger than the cpu register size.  https://gcc.gnu.org/onlinedocs/g...

When you write assembler, you know.

Yes, of course.  you MUST know, and your MUST keep track, and you need to pay attention to which registers are usable for which purposes, and if you end up being wrong about overall performance then you have no one to blame but yourself.

Um... Are you sure you are not mixing "time-critical" with "space-critical"? GCC will often prefer to use registers whose bit-width matches the natural "bitness" of the platform (i.e. 16-bit registers on a 16-bit platform) because such registers are simply faster. GCC treats your loop as time-critical and that is exactly why it opts for a more efficient 16-bit register (instead of an 8-bit register).

P.S. This is the same reason why every time one sees "small" integer types (like uint8_t being used) as local arithmetic variables in a C program (just because 8 bits was "enough"), one immediately realizes that the code is written by an amateur. In properly written C programs local integer arithmetic is always done in "natural" types signed/unsigned int as much as possible, even if their range is excessive. This will produce the most time-efficient code.