Fianawarrior 
Guys, I found this wee gem on the internet. Instead of say using a for loop to go from 10 to 0 ect you can use the -->
for example.
int x = 10;
while( x --> 0 ) // x goes to 0
{
printf("%d ", x);
}
Slán
Does anyone have there own little gems? Like the ternary operator?
That example is fairly obvious for most of us. There's plenty that will have you scratching your head. Best to avoid those methinks. Simple code = simple defects. If you have to stop and think too much about precedence and operation order, then you might want to rewrite the code.
As to whether your example generates more/less or the same code as the equivalent for loop - that's something for investigation.
jgmdesign 
This is a good thread for joeymorin.
JIm
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...)
ok, other question then.......
if you create this, or a for loop, will the assembly output be the same or is there a code difference?
most important, the use of RAM space and the number of instruction cycles needed to do either one of them.
and what will happen if you at one point decide to make things more readable and do while( (x --) > 0 ) // x goes to 0
clawson 
will the assembly output be the same or is there a code difference?
#include <avr/io.h>
int main(void)
{
int x = 10;
#if 1
while(x --> 0) {
PORTB = x;
}
#else
for (x = 10; x; x--) {
PORTB = x;
}
#endif
while(1);
}then built with #if 1 it yields:
00000080 <main>:
#include <avr/io.h>
int main(void)
{
80: 89 e0 ldi r24, 0x09 ; 9
int x = 10;
#if 1
while(x --> 0) {
PORTB = x;
82: 85 b9 out 0x05, r24 ; 5
84: 81 50 subi r24, 0x01 ; 1
86: e8 f7 brcc .-6 ; 0x82 <main+0x2>
88: ff cf rjmp .-2 ; 0x88 <main+0x8>
and built with #if 0 it is:
00000080 <main>:
#include <avr/io.h>
int main(void)
{
80: 8a e0 ldi r24, 0x0A ; 10
while(x --> 0) {
PORTB = x;
}
#else
for (x = 10; x; x--) {
PORTB = x;
82: 85 b9 out 0x05, r24 ; 5
84: 81 50 subi r24, 0x01 ; 1
#if 0
while(x --> 0) {
PORTB = x;
}
#else
for (x = 10; x; x--) {
86: e9 f7 brne .-6 ; 0x82 <main+0x2>
88: ff cf rjmp .-2 ; 0x88 <main+0x8>
So, no, it doesn't seem to make a lot of difference to the generated code.
But to be honest I would always write C with a space on either side or an operator apart from per/post increment. So if you write the code as:
while(x-- > 0) {
There's little mystery to it. Using --> in this is a bit like those folks who rearrange the spacing of the letters in their car's number plate to spell out some name or phrase! Like "SEX80MB" simply split as "SEX 80MB" or whatever ;-)
you can use the -->
Eh?
That's just two perfectly standard, everyday 'C' operators:
The code is just
int x = 10;
while( x-- > 0 ) // check x > 0 with post-decrement
{
printf("%d ", x);
}
Any for loop can always be implemented as an equivalent while loop - and vice versa:
https://www.coursera.org/lecture/programming-fundamentals/equivalent-for-and-while-loops-8LVp2
while( x --> 0 ) // x goes to 0
{
printf("%d ", x);
}
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).
and if it's terse code you like, why not just have
int x = 10;
while( x-- )
{
printf("%d ", x);
}which could equally be written as
for( int x = 10; x--; )
{
printf("%d ", x);
}
which saves you a source line!
I wouldn't call this a hidden gem, I would call it a hidden piece of nonsense.
Indeed!
cute tricks
It's not even a "cute trick" - it's just perfectly standard code.
The worst thing about it is probably the "x goes to 0" comment - suggesting that it is something special ... ?
I found this wee gem on the internet
Go on - where, exactly, did you find it?
EDIT
Too much Stack Overflow, perhaps?
https://stackoverflow.com/questions/1642028/what-is-the-operator-in-c
EDIT 2
Did you also see the "slides to 0" operator?
while (x --\
\
\
\
> 0)
printf("%d ", x);
clawson
It's not even a "cute trick"
(and yes, folks, I know that is not a valid UK registration - I'm just trying to illustrate a point!)
PS my own registration - I know, I know...
clawson 
You think the OP's trick was bad? Try the latest from Microsoft... https://devblogs.microsoft.com/c...
Ligatures in monospaced fonts, yet, in source code. Sometimes I despair.
Neil
I would call it a hidden piece of nonsense.
It probably started as a joke/prank (April fool?) - but someone missed the smiley ... ?
clawson Isn't there some thing in C where something like a++++++a is valid or something? (and no I didn't count the '+' but I know it involves quite a few)
m.majid 
The idiom
while (x--) {}
is quite common for situations where you can loop 0 or more times (ie x can be 0).
and if it's terse code you like, why not just have
int x = 10; while( x-- ) { printf("%d ", x); }
my favorite loop for simple countdowns. +1
Any for loop can always be implemented as an equivalent while loop - and vice versa:
Any for loop can be generated using a while loop, but not the reverse
a++++++a
Take a couple of + out and it's fine:
a++ + ++a
Not sure what happens if you try and increment an incremented(ing) value, mind.
Neil
Take a couple of + out and it's fine:
a++ + ++a
Thta's still undefined behaviour (modifying a twice without a sequence point in between)
curtvm The obvious code produces the same code as the non-obvious-
so may as well make it obvious
Compilers are not impressed by anything clever. They may have been in the past, but not anymore. It becomes a hard habit to break if in the past you had to be 'clever' to get a compiler to do things in a certain way. Now, you just feed it straight-forward code and its already optimized to a degree more than you expected in many cases. I'm sure I still code in 'clever' mode at times mostly out of habit, but it is rarely a good thing.
Compilers are not impressed by anything clever.
I'd like one that could at least understand my programming jokes. Even synthesized laughter would be appreciated.
't is cute, but unless it compiles to something faster, it's not real helpful. Of course, you could do like me, and write assembler to start with - Then there's no issues about how fast it compiles to, you already know... ;-) S.
So now we can check that your tax & MoT are up-to-date ...
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.
clawson Then there's no issues about how fast it compiles to, you already know...
My last boss used to insist on assembler being used 'because it's harder to make mistakes in assembler...'
Neil
p.s. PIC14 assembler at that :( mostly, though the high precision floating point for z80 was fun.
Given trivia, no. But I was curious how a C compiler would have handled something else I just wrote in assembler - It's a three-way switch statement that really only does one of three memory moves - but the source for the three memory moves is always the same, so I moved the 'source' pointer out of the switch statement results. Saved myself several cycles and bytes there.
Pseudo-code:
If X == 1 Then copy SRAM A to SRAM P
If X == 2 Then copy SRAM A to SRAM Q
If X == 3 Then copy SRAM A to SRAM R
I would also like to see a C compiler pull off my zero-cycle divide by 256. ;-P
S.
(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!
gchapman Just accumulating 256x of 16-bit values only needs 24 bits, but is there a 24-bit integer type?
http://gcc.gnu.org/wiki/avr-gcc#Types
Microchip AVR GCC is dependent on GMP.
The GNU Multiple Precision Arithmetic Library
AVR and SAM Downloads Archive | Microchip Technology
[3/4 page]
AVR GCC
...
AVR GCC 3.6.2
Excellent! Now, is there a type for 22 bits or 26 bits, as implemented in a 'soft processor core' in an FPGA? 
theusch 
I would also like to see a C compiler pull off my zero-cycle divide by 256. ;-P
P indeed. The same way you'd just "tell" your assembler code to use the most-significant-byte of a two-byte value, you'd do the same in C. (I'll bet on your AVR8 it is in the low address as well...)
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>
With gcc 8.3 the construction of the 16-bit number is optimized.
Source:
#include <avr/io.h>
#include <stdint.h>
int main()
{
uint16_t x = ( PORTC << 8 ) | PORTD;
PORTB = x / 256;
for ( ;; ) {}
}Compiled with the following flags:
-std=c++17 -Werror -Wall -Wextra -Wpointer-arith -Wold-style-cast -mmcu=atmega328p -Os -g
Disassembly (main only):
int main()
{
uint16_t x = ( PORTC << 8 ) | PORTD;
80: 98 b1 in r25, 0x08 ; 8
82: 8b b1 in r24, 0x0b ; 11
PORTB = x / 256;
84: 95 b9 out 0x05, r25 ; 5
for ( ;; ) {}
86: ff cf rjmp .-2 ; 0x86 <main+0x6>
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!
but not a 24-bit number.
Hmm? It still works...
void main() {
__uint24 x;
x = (PORTC << 8) | PORTD;
38: 25 b3 in r18, 0x15 ; 21
3a: 82 b3 in r24, 0x12 ; 18
3c: 90 e0 ldi r25, 0x00 ; 0
3e: 92 2b or r25, r18
40: 09 2e mov r0, r25
42: 00 0c add r0, r0
44: aa 0b sbc r26, r26
46: 89 2f mov r24, r25
48: 9a 2f mov r25, r26
4a: aa 27 eor r26, r26
PORTB = x/256;
4c: 88 bb out 0x18, r24 ; 24
4e: ff cf rjmp .-2 ; 0x4e
but not a 24-bit number.
Hmm? It still works...
void main() { __uint24 x; x = (PORTC << 8) | PORTD; 38: 25 b3 in r18, 0x15 ; 21 3a: 82 b3 in r24, 0x12 ; 18 3c: 90 e0 ldi r25, 0x00 ; 0 3e: 92 2b or r25, r18 40: 09 2e mov r0, r25 42: 00 0c add r0, r0 44: aa 0b sbc r26, r26 46: 89 2f mov r24, r25 48: 9a 2f mov r25, r26 4a: aa 27 eor r26, r26 PORTB = x/256; 4c: 88 bb out 0x18, r24 ; 24 4e: ff cf rjmp .-2 ; 0x4e
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?
I don't know if it is still the case, but a few years ago, the PIC C compiler, free version, was carefully optimised to ensure maximum time was taken for shifts. Shifting a 24-bit value by eight required that all three bytes were shifted one bit at a time, eight times...
Neil
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.
I lurv "ldi r25, 0x00". And then OR with r18? What? Can't 'mov' do it all?
Yeah. Some of that is that I didn't cast the RHS math to __UINT24, so it's probably doing 16bit math and then carefully converting to 24bits. It looks slightly better fixed, but not a lot (even with avr-gcc9.2, which does well on the 16bit case (and only so-so on 32bits.)
But you asked about the /256, which it seems to be doing fine in all cases.
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.
Well, you want to see gcc screw-up because it thinks it's smart? Easy 
#include <avr/io.h>
int main() {
DDRB = 0x01;
uint8_t parallel_data = PIND, mask = 0x01;
while (mask) {
parallel_data & mask ? PORTB |= 0x01 : PORTB &= ~0x01;
mask <<= 1;
}
while (1);
}
Well, you want to see gcc screw-up because it thinks it's smart? Easy
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).
Maybe it is different if compiled as C++ (I haven't tried).
Yeah I did write it in C++, my bad. Like this, then:
#include <avr/io.h>
int main() {
DDRB = 0x01;
uint8_t parallel_data = PIND, mask = 0x01;
while (mask) {
(parallel_data & mask) ? (PORTB |= 0x01) : (PORTB &= ~0x01);
mask <<= 1;
}
while (1);
}
Needs extra brackets, or be normal and just use if/else.
I though ternary operator was normal... But ok, for those who have issues:
#include <avr/io.h>
int main() {
DDRB = 0x01;
uint8_t parallel_data = PIND, mask = 0x01;
while (mask) {
if (parallel_data & mask) {
PORTB |= 0x01;
}
else {
PORTB &= ~0x01;
}
mask <<= 1;
}
while (1);
}
I though ternary operator was normal... But ok, for those who have issues:
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
Not the ternary operator itself, I'm quite happy when you're making use of value returned
Yeah I understand that. I have this tendency to maybe overuse it because I once saw an old version of gcc generating better code for the ternary operator than for if;else.
Modern versions usually generate the exact same code.
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?
Is that one of the cases where gcc decides that you want to do something 8 times, and therefore creates an entirely unnecessary counter?
Looks like it, yes (and 16 bit counter as well).
(this is with avr-gcc (GCC) 4.9.2 -Os, maybe newer version is better?)
int main(void)
{
DDRB = 0x01;
80: 81 e0 ldi r24, 0x01 ; 1
82: 84 b9 out 0x04, r24 ; 4
uint8_t parallel_data = PIND, mask = 0x01;
84: 39 b1 in r19, 0x09 ; 9
86: 88 e0 ldi r24, 0x08 ; 8
88: 90 e0 ldi r25, 0x00 ; 0
8a: 21 e0 ldi r18, 0x01 ; 1
while (mask) {
if (parallel_data & mask)
8c: 42 2f mov r20, r18
8e: 43 23 and r20, r19
90: 11 f0 breq .+4 ; 0x96 <main+0x16>
PORTB |= 0x01;
92: 28 9a sbi 0x05, 0 ; 5
94: 01 c0 rjmp .+2 ; 0x98 <main+0x18>
else
PORTB &= ~0x01;
96: 28 98 cbi 0x05, 0 ; 5
mask <<= 1;
98: 22 0f add r18, r18
9a: 01 97 sbiw r24, 0x01 ; 1
int main(void)
{
DDRB = 0x01;
uint8_t parallel_data = PIND, mask = 0x01;
while (mask) {
9c: b9 f7 brne .-18 ; 0x8c <main+0xc>
PORTB |= 0x01;
else
PORTB &= ~0x01;
mask <<= 1;
}
while (1);
9e: ff cf rjmp .-2 ; 0x9e <main+0x1e>
Is there a way to tell GCC that, say RPM, is an important 16 bit value (in a motor controller app) & should be kept in a register pair, rather than delegated to sram with "lower-importance" values. This is a matter of efficiency, since, of course, register values can be read, compared, & manipulated much more efficiently. I don't think GCC would be able to determine which variables are most critical, in terms of impacting efficiency---or does it?. I've meant to look into this, but just declare my variables & move on!!
(note: reply to #48 & #49)
Yes, this is, let's say, my pet peeve with the gcc optimizer. So it's not the first time I mention it: https://www.avrfreaks.net/forum/...
There is a workaround, explained in that thread.
And even the most recent avr-gcc version I have, v9.1.0, still auto-generates a 16 bit counter to count to 8.
So, when people say "Just trust the compiler, it will generate better code than the average programmer would hand code in assembly"... err, no. Maybe it will most of the time, but then mess up a time critical loop. I always double check important parts of the generated code.
clawson I think the phrase "will generate code as good as an Asm programmer" is usually with something like "about 90% of the time". Sure there are occasions where it's suboptimal but the positives outweigh the negatives.
As a simple exercise write a JPEG encoder. Your choice: C or Asm.
Report back in 2 weeks ;-)
I think the phrase "will generate code as good as an Asm programmer" is usually with something like "about 90% of the time". Sure there are occasions where it's suboptimal but the positives outweigh the negatives.
Actually the positives _far_ outweigh the negatives, I'm not arguing about that. Just saying, that if the compiler screws up 10% of the time, and 10% of the code is time critical, there is a 1% chance that the compiler will screw up time critical code. It happens. So I like to check the quality of generated code in these parts just to be sure.
I don't think GCC would be able to determine which variables are most critical, in terms of impacting efficiency---or does it?
In 9 cases out of 10 GCC will much better than the user at determining it.
Is there a way to tell GCC that, say RPM, is an important 16 bit value (in a motor controller app) & should be kept in a register pair, rather than delegated to sram with "lower-importance" values.
I believe there is a keyword modifier 'register' that you can apply to variables, but it would probably depend on the compiler. S.
I think the phrase "will generate code as good as an Asm programmer" is usually with something like "about 90% of the time". Sure there are occasions where it's suboptimal but the positives outweigh the negatives.
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.
As a simple exercise write a JPEG encoder. Your choice: C or Asm.
Report back in 2 weeks ;-)
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 believe there is a keyword modifier 'register' that you can apply to variables, but it would probably depend on the compiler
The keyword is part of the language standard.
What - if any - effect it has will depend upon the particular compiler.
I think it is largely ignored by modern compilers ... ?
code as good as an Asm programmer
Does, of course, depend upon how good the particular "Asm programmer" is.
I think it 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.
When you write assembler, you know. S.
When you write assembler, you know.
And if you need to know, you should be writing in assembler anyhow.
Which I do. Cheers to all of you! a great gang, you is. 
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.
clawson but it's not clear whether it works on variables larger than the cpu register size.
register uint16_t foo asm("r16");then it's assigned to r17:r16:
register uint16_t foo asm("r16");
int main(void)
{
foo = 0x1234;
7a: 04 e3 ldi r16, 0x34 ; 52
7c: 12 e1 ldi r17, 0x12 ; 18
And even the most recent avr-gcc version I have, v9.1.0, still auto-generates a 16 bit counter to count to 8.
So, when people say "Just trust the compiler, it will generate better code than the average programmer would hand code in assembly"... err, no. Maybe it will most of the time, but then mess up a time critical loop. I always double check important parts of the generated code.
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.
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)
I fail to see how a 16bit counter is more efficient than 8bit on an 8bit micro.
The assembler produced by the compiler for this partiular code snippet is clearly not optimal for this architecture.
Personally, I think so what, it's not going to stop me using C.
But the fact remains it is in this case non optimal.
Sticking with 8bit micros, I'm not sure I agree with using 'int sized' variables, just because things are (conceptually at least) promoted to int before an operation (if that's what you are saying, I may have misunderstood).
Given
uint8_t a, b, c;
a = b + c
Although b + c is conceptually performed as int (16 bit), the compiler knows that since the result is assigned to a uint8_t it only needs to do an 8bit add.
(I'm assuming that you know the result will always fit in 8 bits).
If you had
int a;
uint8_t b, c;
then for a = b + c it would have to do 16bit add.
clawson one immediately realizes that the code is written by an amateur.
MISRA (fairly professional) forbid the use of "signed int"/"unsigned int" and the other base types (apart from "char") anyway.
I shall grant at first that this particular field is 'general programming', but the site itself is called AVRFreaks, so we're probably mostly hanging around on 8-bitters? Maybe? There's a few 32 among us, and yes, some AVR registers can be paired to be addressed sixteen-bit-ly, as it were, but mostly speaking:
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).
The 'bitness' of the AVR processor is eight bits, not sixteen. The 'bitness' of the larger processors is 32, not 16. If you're really whacking away on the big iron, the 'bitness' is 64. Not sixteen.
's true there are other Microchip products that are sixteen bits wide, and you're right, it is best to adjust your code to the hardware it gets to run on. I've built systems from four bits to eighteen (yes, that one was a bit weird), forty, and beyond, and the best code is that which pays attention to the hardware. Know thy targets. S.
On AVRs, and I expect other microcontrollers, gcc allows one to use inline assembly on local variables.
One need not write the entire function in assembly and
can still get the timing right by counting the times of instructions.
'Tis my understanding that this is not true of other compilers or other processors:
Other compilers do not have gcc's syntax for referring to local variables and
larger processors have more complicated timings.
Counterexamples?
Simonetta I would avoid this construction (x-->0) because the symbols are too close to the syntax used for accessing a structure member when using a pointer to the structure: x->0: which may refer to the beginning of the structure (member number 0 of the structure pointed to by x).
An interesting gem is C's ability to "reverse" the syntax of an array. So myArray[5] is the same as 5[myArray]. The compiler starts at 5 times the size of the array element and then adds the beginning address of myArray[0] to get the final address 5[myArray].
x->0: which may refer to the beginning of the structure (member number 0 of the structure pointed to by x).
Nonsense - structure members are not referred to by number!
An interesting gem is C's ability to "reverse" the syntax of an array. So myArray[5] is the same as 5[myArray]. The compiler starts at 5 times the size of the array element and then adds the beginning address of myArray[0] to get the final address 5[myArray].
I see what you're saying, but I think it's more easily understood by recognising that, under the hood, array subscripting is implemented as pointer arithmetic.
So myArray[5] becomes *(myArray + 5)
and 5[myArray] becomes *(5 + myArray)
The end result is the same either way, it's just adding an integer to a pointer (pointer arithmetic) and then dereferencing the resulting address.