This was an interview question. I said they were the same, but this was adjudged an incorrect response. From the assembler point of view, is there any imaginable difference? I have compiled two short C programs using default gcc optimization and -S to see the assembler output, and they are the same.
views:
746answers:
7
+6
A:
Looks like you were right and they were wrong. I had a similar issue in a job interview, where I gave the correct answer that was deemed incorrect.
I confidently argued the point with my interviewer, who obviously took offence to my impudence. I didn't get the job, but then again, working under someone who "knows everything" wouldn't be that desirable either.
spender
2009-05-15 09:15:13
It's worth arguing - I had the same experience, pointed out where and why the interviewer was wrong, and got the job.
anon
2009-05-15 09:18:28
Agreed. It's always better to give correct answers than the one you think the interviewer wants. Good interviewers will want to hire people who are smarter than they are.
Kristopher Johnson
2009-05-15 09:20:25
+6
A:
You are probably right. A naive compiler might do:
++i to inc [ax]
and
i = i + 1 to add [ax], 1
but any half sensible compiler will just optimize adding 1 to the first version.
This all assumes the relevant architecture has inc and add instructions (like x86 does).
cletus
2009-05-15 09:16:32
I'd have made a comment like this in the interview. That ++i would definitely use an increment instruction if available, whereas i = i + 1 may not do so in a naive compiler but should be optimised to do the same by a decent compiler.
workmad3
2009-05-15 09:18:33
using the ++i shows you know the difference. It's always a good habit to try say what you actually mean.
Chris Huang-Leaver
2009-05-15 09:22:42
it's worth noting that ++i (or i++, or i=i+1) doesn't always map to the `inc` instruction. If i is a pointer to an int then ++i will be the same as add i, 4, because i needs to point to the next int, which is 4 bytes wide. If i points to a long, the ++i will be the same as add i,8, for the same reason.
Nathan Fellman
2009-05-15 14:21:52
@Nathan: excellent point. If i is a pointer, the statements will probably compile to the same code cos, for example, double *p = 0; p++; p now equals 8.
cletus
2009-05-15 14:47:48
+10
A:
The interviewer may have wanted an answer something like this:
i=i+1will have to load the value ofi, add one to it, and then store the result back toi. In contrast,++imay simply increment the value using a single assembly instruction, so in theory it could be more efficient. However, most compilers will optimize away the difference, and the generated code will be exactly the same.
FWIW, the fact that you know how to look at assembly makes you a better programmer than 90% of the people I've had to interview over the years. Take solace in the fact that you won't have to work with the clueless loser who interviewed you.
Kristopher Johnson
2009-05-15 09:17:56
That's true from the assembly point of view, but all x86 processors would do the same for both instruction sequences - inc [memadr] requires loading the value to a hidden register anyway. However different amount of code would be emitted.
sharptooth
2009-05-15 09:21:06
I'd expect a decent compiler to see that it's the same i in the LHS and RHS and produce the same code.
Nathan Fellman
2009-05-15 14:13:50
Won't a modern SSA compiler rewrite the entire statement anyway? The first statement becomes i_2=i_1+1 and the second becomes i_2=i_1+1, too. Chances are that the i_1 and i_2 variables aren't assigned the same register.
MSalters
2009-05-15 14:56:47
A:
Both assembler ops are invalid, square brackets implies access a memory slot via AX. Theres is also no inc ax instruction - one must use add 1 to AX.
mP
2009-05-15 09:20:02
Actually, if you're referring to cletus' answer, both are correct. inc [ax] means increment the memory addressed by ax, while inc ax means increment ax itself.
Nathan Fellman
2009-05-15 14:16:17
+3
A:
In C++, it depends if i is an int or an object. If it's an object, it would probably generate a temporary instance.
kotlinski
2009-05-15 09:36:12
+5
A:
To defend the interviewer, context is everything. What is the type of i? Are we talking C or C++ (or some other C like language)? Were you given:
++i;
i = i + 1;
or was there more context?
If I had been asked this, my first response would've been "is i volatile?" If the answer is yes, then the difference is huge. If not, the difference is small and semantic, but pragmatically none. The proof of that is the difference in parse tree, and the ultimate meaning of the subtrees generated.
So it sounds like you got the pragmatic side right, but the semantic/critical thought side wrong.
To attack the interviewer (without context), I'd have to wonder what the purpose of the question was. If I asked the question, I'd want to use it to find out if the candidate knew subtle semantic differences, how to generate a parse tree, how to think critically and so on and so forth. I typically ask a C question of my interviewees that nearly every candidate gets wrong - and that's by design. I actually don't care about the answer to the question, I care about the journey that I will be taking with the candidate to reach understanding, which tells me far more about than right/wrong on a trivia question.
plinth
2009-05-15 14:27:14
A:
the context is the main thing here because on a optimized release build the compiler will optimize away the i++ if its available to a simple [inc eax]. whereas something like int some_int = i++ would need to store the i value in some_int FIRST and only then increment i.
NK47
2009-05-27 13:24:28