Talk:NOP

From Wikipedia, the free encyclopedia

Note: NOOP Protocol Commands section is based off a section I wrote, original article noop. --Rgb9000

[edit] i++ statement

the i++ statement does have a net effect- therefore making it a bad candidate for an example of NOOP. This has been replaced with i + 1; which does not change any values in memory, and simply returns its value into nothingness.

Indeed it does, but here it was followed by i--, which means that there is no net effect unless there's something weird going on in the background that I don't know about. --Aurochs

No, the person above is absolutely right. Either operation, i++ or ++i will affect the value of i! These are not the same as a NOOP, this are the same as "INC i" where INC would be an increment operator in the CPU. Like you said in your edit comment, i+1 effectively does nothing. (Actually, without optimization, it LOADS the value of i into a register, increments it by one, and then forgets about the value. Optimizing compilers see this, ignore the operation, and replace it with a NOOP.) i+1 is STILL valid c++! Much in the same way i=j=k=m+1 is! Try it! You'll see that it will compile and everything. More to the point, if i have a function int dosomething(), i can just call dosomething() and ignore the return value because c/c++ allows this for all functions. i+1 is such a function.--Stux 15:33, 9 November 2005 (UTC)

I think you're missing the point. The following code:
i++;
i--;
has no net effect. It incerments i and then immediately decrements it, so i has returned to its original value and there was no intervening code to use the incermented variable. It is effectively an nop, though the amount of time it takes to execute differs from your i + 1 example. --Aurochs

Oh! My apologies! Now I understand what the example was saying! At first I thought (and I'm sure the user that originally changed the i++ to an i+1 probably thought as well), that the example was listing two individual statements. Upon more careful reading (of the text and of your comments) I realized now what it meant. Since it seemed rather easy for passers-by to misinterpret that example (much in the same way I did), I changed the example back to the original, but added brackets and wording to make it clear that it is meant to be understood as one group of instructions. I also added the i+1 example back in as an alternative. If you feel the wording needs to be improved, please do so! Again, thanks for pointing out the error. (Thank you for your politeness and understanding as well! It seems nowadays that is lacking from the users of this wiki.) --Stux 22:08, 9 November 2005 (UTC)

I'm going to remove this example. As i++; i--; changes values in memory, it's not really a no-op. (I realize the probability is unlikely, but what happens if another thread raises an exception before i--; gets called? - Chardish 16:11, 6 December 2006 (UTC)

No, i++; i--; is not a NOP. Let's assume the compiler translates it to this pseudo-assembly code:

1: INC i
2: DEC i

On most (all?) CPUs, these two instructions are not atomic. Let's assume the program containing this code is running two threads and a context switch occurs between instructions 1 and 2. The value of i is now one more than the original value. If the second thread attempts to read i at it point, it will read the wrong value. — 71.155.235.243 00:39, 31 March 2006 (UTC)

i++; i-- can cause an overflow trap depending on the type of i. An unsigned int will never trap, but a plain (signed) int or a float may do so. If adding the declaration is deemed too distracting, I suggest changing the example to i += 4711 * 0 or similar. Kjetilho 07:51, 4 October 2006 (UTC)

[edit] NOPs that aren't really

I think that this article should cover the fact that not all processors have an opcode that is truly set aside as a NOP. The most obvious example is the x86. Opcode 90 really means "xchg eax, eax". MIPS's NOP is really "sllv zero, zero, zero" if I remember right.

Of course, this can change over time. When the x86 became pipelined, "nop" stopped being "xchg eax, eax". It's special cased for performance reasons; "xchg" is a somewhat expensive instruction. Also, "xchg eax, eax" implies to the instruction scheduler that the instruction depends on the previous value of EAX.

x86-64 further differentiates it. "xchg eax, eax" actually does something - it now truncates RAX to 32 bits, as in "movzx rax, eax". Assemblers don't encode "xchg eax, eax" as 90. -- 68.228.65.220 06:48, 10 October 2006 (UTC)