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.
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.
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".
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.
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.
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.
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.
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.