[layer8]

The article explains why a MOV is used instead of two NOPs. Five NOPs would obviously be even worse.

[colejohnson66]

But NOPs aren’t even executed. They’re swallowed by either the decoder or dispatcher.

[avianlyric]

Because you can’t atomically replace the NOPs. So there’s nothing to prevent you from inserting your patch while a thread partway through consuming the NOPs, resulting in a portion of your patch being decoded out of order.

[wvenable]

The article states that it's one cycle and slot per NOP.

[colejohnson66]

Modern x86 processors decode multiple instructions per clock. By “slots”, I’m assuming he means entries in the dispatcher or reservation stations. But NOPs don’t even make it to there. As I said, the decoder that encounters it will probably swallow it and emit nothing.

Besides, it sounds like premature optimization. This isn’t the 1980s; An extra clock cycle per function call is not going to make or break your program.

[MBCook]

Modern.

There is a very good chance this dates back to 16-bit Windows. Even Windows 98 supported the 486 which was not capable of independent execution (that’s P5) or separate decode from execution (P5Pro there).

Those processors weren’t dead until Windows XP.

[wvenable]

At the time this was relevant, it wouldn't have been premature optimization. Reducing that many cycles per function call would be a reasonable win.

[mFixman]

But isn't there a 5-byte single instruction that has no effect, like `NOP DWORD ptr [EAX + EAX*1 + 00H]`?

I thought that multibyte NOPs were executed in a single instruction?

[MBCook]

They may not have been coalesced at the time the decision was made.

[layer8]

I’m pretty sure it would be slower, if only by taking up more space in the instruction cache (in the common case where no hotpatch is applied).