How to increment a variable [modified]
-
I do remember IBM mainframes batch processing Fortran jobs (actually Watfor/Watfiv), punched on Hollerith cards, read one by one by a noisy machine, compiled one by one (no intermediate storage), listed one by one on an even noisier line printer, with each student allotted 5 minutes of execution time, for a total of one hour a day; the remainder of the day the uni needed its mainframe for its own IT handling. In 5 minutes the huge machine performed much less than a typical desktop would do today in 1 second. The good thing was the compile and link stages were not time-limited, and the compilers tried to maximize the number and meaningfulness of the messages it emitted. :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
You forgot to mention the keypunches never had a ribbon with ink so your deck of cards were completly blank making inserting and modifing the code next to impossible. (and we did it while walking uphill in the pouring rain). :) My favorite was taking the compiler course (Dragon Book) using an IBM 1130 [^]running I think Fortran 66 -- only arithmatic IF for conditional processing. IF( expression ) 100, 200, 300 Fun.
-
Kurdy Malloy wrote:
It made me wonders if the compiler was smart enough to ...
We can only hope the compiler generates code compatible with the language specification;
i++is a post-increment operator, it increments after the main operation (=) got executed. It isn't a compiler's duty to guess at what the programmer intended, it should do so only when reporting error and warning messages ("Are you missing a ;"). :)Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
In c++, VS 2005, the unoptimized code is actually kind of stupid i = i++; mov eax,dword ptr [i (40904Ch)] mov dword ptr [i (40904Ch)],eax mov ecx,dword ptr [i (40904Ch)] add ecx,1 mov dword ptr [i (40904Ch)],ecx It gets i, stores it in i, gets i, increments i, stores it in i. Not sure why it thinks it needs to do the first 2 steps. When I turn on "optimized for speed" (not comfort like me) it generates the exact same (smart) code as ++i;
-
In c++, VS 2005, the unoptimized code is actually kind of stupid i = i++; mov eax,dword ptr [i (40904Ch)] mov dword ptr [i (40904Ch)],eax mov ecx,dword ptr [i (40904Ch)] add ecx,1 mov dword ptr [i (40904Ch)],ecx It gets i, stores it in i, gets i, increments i, stores it in i. Not sure why it thinks it needs to do the first 2 steps. When I turn on "optimized for speed" (not comfort like me) it generates the exact same (smart) code as ++i;
the stoopit code is pretty normal since
i=i++;falls apart ini=i;andi++;and that is what the assembly code does, without any optimization. :)Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
In c++, VS 2005, the unoptimized code is actually kind of stupid i = i++; mov eax,dword ptr [i (40904Ch)] mov dword ptr [i (40904Ch)],eax mov ecx,dword ptr [i (40904Ch)] add ecx,1 mov dword ptr [i (40904Ch)],ecx It gets i, stores it in i, gets i, increments i, stores it in i. Not sure why it thinks it needs to do the first 2 steps. When I turn on "optimized for speed" (not comfort like me) it generates the exact same (smart) code as ++i;
When I turn on "optimized for speed" (not comfort like me) it generates the exact same (smart) code as ++i; Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like:
mov eax,[_i] ; Fetch value before increment
inc dword [_i] ; Do increment
mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing. BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?
-
When I turn on "optimized for speed" (not comfort like me) it generates the exact same (smart) code as ++i; Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like:
mov eax,[_i] ; Fetch value before increment
inc dword [_i] ; Do increment
mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing. BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?
supercat9 wrote:
Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like: mov eax,[_i] ; Fetch value before increment inc dword [_i] ; Do increment mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing. BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?
This code doesn't "do nothing" i = i++; It still has to inc i and store it in i. It is just a long form of ++i; The VS optimizer usually does a pretty good job. I had to heavily optimize some code a few years ago. I don't remember which VS version I was using, but I was impressed with the code it came up with. In this case it generates mov eax,1 add dword ptr [i],eax This seems a little strange to me. Maybe an "add" is much faster than an "inc". It's been a while since I was optimizing asm code. do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.
-
supercat9 wrote:
Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like: mov eax,[_i] ; Fetch value before increment inc dword [_i] ; Do increment mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing. BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?
This code doesn't "do nothing" i = i++; It still has to inc i and store it in i. It is just a long form of ++i; The VS optimizer usually does a pretty good job. I had to heavily optimize some code a few years ago. I don't remember which VS version I was using, but I was impressed with the code it came up with. In this case it generates mov eax,1 add dword ptr [i],eax This seems a little strange to me. Maybe an "add" is much faster than an "inc". It's been a while since I was optimizing asm code. do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.
-
CurtD wrote:
do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.
Really? The compiler I tested performed the increment before the function call.
From MSDN When a postfix operator is applied to a function argument, the value of the argument is not guaranteed to be incremented or decremented before it is passed to the function. See section 1.9.17 in the C++ standard for more information. So, like so much in life, you just roll the dice and take your chances.
-
supercat9 wrote:
Wouldn't a more efficient implementation be to simply do nothing, given the lack of a sequence point between the increment and the assignment? Not that I'd generally expect a compiler to find that optimization, but I would have expected code like: mov eax,[_i] ; Fetch value before increment inc dword [_i] ; Do increment mov [_i],eax ; Store fetched valuewhich would, of course, effectively do nothing. BTW, is there any guarantee about the behavior of "do_something(var++)" if do_something references var? What about "i=++i"? Even though it's hard to imagine that "i=++i;" would do anything other than increment "i", I don't think there's any guarantee that it won't?
This code doesn't "do nothing" i = i++; It still has to inc i and store it in i. It is just a long form of ++i; The VS optimizer usually does a pretty good job. I had to heavily optimize some code a few years ago. I don't remember which VS version I was using, but I was impressed with the code it came up with. In this case it generates mov eax,1 add dword ptr [i],eax This seems a little strange to me. Maybe an "add" is much faster than an "inc". It's been a while since I was optimizing asm code. do_something(var++) is going to push the current var on the stack, call do_something, then inc var. Nothing strange about that.
CurtD wrote:
This code doesn't "do nothing"
If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether? Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.
-
CurtD wrote:
This code doesn't "do nothing"
If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether? Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.
supercat9 wrote:
If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether?
Well, according to MSDN, the C++ standard does not define the proper behavior when a postfix is applied to a function arg. If anyone knows why they decided to leave it up to the compiler writers instead of deciding on a "standard", I would love to know the reason. The best thing to do is not write code like this. MSDN doesn't say specifically how a postfix is supposed to behave in the example i = i++. But, VS 2005 inc's i before storing it in i -- I assume because of operator precedence.
supercat9 wrote:
Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.
When playing with this example, the optimizer did just that in one case -- it kept (i+1) in a reg, used it a few times, and stored it later. The VS compiler will optimize away code that doesn't do anything.
void donothing()
{
int i = 5;
i++;
}No code is generated for donothing() and any call to it is ignored.
-
supercat9 wrote:
If the variable i is equal to five before the statement, "i = i++;" is executed, would it not be legitimate for the compiler's generated code to read i (five), increment i (yielding and storing six), and then store the read value back to i (setting it back to 5)? If the variable i is not volatile, would not a legitimate optimization thus be to eliminate the statement altogether?
Well, according to MSDN, the C++ standard does not define the proper behavior when a postfix is applied to a function arg. If anyone knows why they decided to leave it up to the compiler writers instead of deciding on a "standard", I would love to know the reason. The best thing to do is not write code like this. MSDN doesn't say specifically how a postfix is supposed to behave in the example i = i++. But, VS 2005 inc's i before storing it in i -- I assume because of operator precedence.
supercat9 wrote:
Out of curiosity, I wonder if there are any compilers which do not always update a variable used with a pre-increment before making use of the pre-incremented value? It's possible to contrive examples where the optimal code would in fact use (var+1) in the expression and then later store the incremented value to the variable, but I doubt compilers would find such optimizations.
When playing with this example, the optimizer did just that in one case -- it kept (i+1) in a reg, used it a few times, and stored it later. The VS compiler will optimize away code that doesn't do anything.
void donothing()
{
int i = 5;
i++;
}No code is generated for donothing() and any call to it is ignored.
For more fun from the C++ standard: [ Example: i = v[i++]; // the behavior is undefined i = 7, i++, i++; // i becomes 9 i = ++i + 1; // the behavior is undefined i = i + 1; // the value of i is incremented —end example ] I think the best programming practice is to avoid "undefined" behavior.
modified on Tuesday, March 24, 2009 2:43 PM
-
It was in release mode of course otherwise it's only normal that it wouldn't do any optimizations :) Ok didn't think of volatile - well then "any variable or field that is not volatile" can have an assignment to itself removed without any harm (unless you're doing scary reflection tricks..) But the JIT compiler is a problem.. how can you see what code it produces?
Hey, The CLR ships with a tool called NGen. NGen compiles IL into native code so if you use this you will be able to see what code is produced :) Hope that helps
At university studying Software Engineering - if i say this line to girls i find they won't talk to me Dan
-
Luc Pattyn wrote:
It isn't a compiler's duty to guess at what the programmer intended, it should do so only when reporting error and warning messages ("Are you missing a ;").
Waaay back in the good old days at University we were blessed / cursed with using a PL/C compiler. It was a student version of the full PL/I compiler and was guaranteed to always produce some sort of output regardless of how stupid your input was. This was a good thing as often you only got one chance a day (yes kids, that is one chance a day) to see if your program would compile and work. The results were often spectacular with pages of fanfold shooting out of the line printer.
"Oh, I see by your variable name that you intended this to be an unsigned imaginary number. Level of certainty: 95%" That's not actually what the output said, but that's an example of the kind of thing that I imagined the compiler saying that as it was processing the code. I do seem to recall it giving some kind of "level of certainty".
We are dyslexic of Borg. Refutance is systile. Your a$$ will be laminated!
-
"Oh, I see by your variable name that you intended this to be an unsigned imaginary number. Level of certainty: 95%" That's not actually what the output said, but that's an example of the kind of thing that I imagined the compiler saying that as it was processing the code. I do seem to recall it giving some kind of "level of certainty".
We are dyslexic of Borg. Refutance is systile. Your a$$ will be laminated!
That's right. It was somewhat conversational with a hint of arrogant superiority. You wrote "this" (you bonehead). PL/C chooses to do "this". If smileys had been invented then I'm sure it would have followed with a :P
-
It was in release mode of course otherwise it's only normal that it wouldn't do any optimizations :) Ok didn't think of volatile - well then "any variable or field that is not volatile" can have an assignment to itself removed without any harm (unless you're doing scary reflection tricks..) But the JIT compiler is a problem.. how can you see what code it produces?
I don't like to think what would happen to "i = i++" if "i" is truely volatile. Would the post increment be actioned on an interrupt modified value? Now that would be a good bug to find!
