Nop should be #1, because it is infinitely slow for what it does. ;)
back
3 comments
It increments rip by one.
I thought I remembered reading somewhere re: the 8086 microcode disassembly that NOP, which is encoded as XCHG AX,AX actually does run the XCHG microcode and uses an internal scratchpad register to do the exchange.
There were several NOPs - XCHG BX,BX and so on. Those were taken later to be prefixes for new classes of opcodes.
None was. XCHG AX,AX is special because XCHG AX,reg has a one-byte encoding.
You're probably confusing with:
- POP CS being broken and later becoming a prefix
- some opcodes being "reserved NOPs", i.e. reserved without generating #UD. They are used for instructions that may be defined in the future while guaranteeing backwards compatibility, for example new kinds of prefetches. MPX bounds checking instructions were also encoded in reserved NOPs.
Was I thinking of 0x86?
0x86 and 0x87 (XCHG rm,r with byte- and word-sized operands) encode nops in the same way as 0x90, but were never redefined as prefixes.
It's interesting that a lot of ALU operations occupy four opcodes (memory source/memory destination x byte/word) but 0x84/0x85 and 0x86/0x87 only need two because not only are they commutative, but also 0x84/0x85 do not write to any operands and 0x86/0x87 write to both. So there is no difference between memory as the source or destination operand.
No, that's done by the decoder. It actually does nothing.
The decoder is an implementation detail that is a subcomponent of NOP; GP was right, and your correction isn't.
As specified by the spec, it arguably increments RIP by one.
The actual typical hardware implementation just fetches the next 16-32 bytes from icache, shifts it to the correct alignment, and slams it into a bunch of parallel decoders which each attempts to decode one x86 instruction per byte.
The next cycle, the first 1-6 non-overlapping valid instructions are accepted into a queue for further decoding. The NOP almost certainly takes up space in this queue.
At no point does RIP get incremented by one. There isn't even a single physical RIP register to increment, the CPU is "executing" dozens or even hundreds of RIPs in parallel.
As long as everyone is being outrageous pedantic: NOP, like all other non-faulting, non-control-transferring instructions, increments RIP by the length of the instruction, which may or may not be one. A prefixed NOP is still NOP.
It's not an implementation detail, because the decoder runs before the execution of every instruction. If we're going to say that NOP increments IP by one, then we should also say that ADD "stores in dst the addition of src and dst, as well as incrementing IP by the length of the instruction", and JMP imm "increments JMP by imm + the length of the instruction".
ADD does in fact do that.
I'm not disputing the total effect. I'm asking if you'd rather describe ADD and JMP in this manner, in order to say that NOP does not in fact do nothing.
Love the pedantry here. I'm currently at: no op code does anything, it's all fancy effects in the hardware that can be described in arbitrary detail, which somehow allows me to cause these letters to appear on your screen.
It's still part of the instruction to increment it by one, as opposed to write a value or offset to it, as jump instructions do.
See my sibling response.
I mean....there are several architectures out there which has a nop that is a jump forward. Kind of a tree forest issue imho
I don't know about other architectures in as much detail. I know x86 NOP does nothing.
Strategy: nop does nothing. It opens the leaderboard accordingly.
Score: 1 cycles Time: 0 nanoseconds
It opens the leaderboard as #27, so in the last place.
It's a little faster than yep.