4 ms·

I don't understand the reasoning behind this. Why do you need 5 bytes of unexecuted patch space before the program _and_ 2 bytes of patch space at the beginning

I don't understand the reasoning behind this. Why do you need 5 bytes of unexecuted patch space before the program _and_ 2 bytes of patch space at the beginning of the program? Wouldn't it be the same to have a single 5-byte effectless operation to patch a single long jump instead of needing space for two jumps?

saagarjha 4y ago
5 bytes of nops takes longer than 2 bytes?
- jahewson 4y ago
  Longer time to execute.
layer8 4y ago
The article explains why a MOV is used instead of two NOPs. Five NOPs would obviously be even worse.
- mFixman 4y ago
  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?
  - layer8 4y ago
    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).
  - MBCook 4y ago
    They may not have been coalesced at the time the decision was made.
- colejohnson66 4y ago
  But NOPs aren’t even executed. They’re swallowed by either the decoder or dispatcher.
  - wvenable 4y ago
    The article states that it's one cycle and slot per NOP.
    - colejohnson66 4y ago
      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 4y ago
        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 4y ago
        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.
  - avianlyric 4y ago
    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.

saagarjha 4y ago

5 bytes of nops takes longer than 2 bytes?

jahewson 4y ago
Longer time to execute.

layer8 4y ago

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

mFixman 4y ago
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?
- layer8 4y ago
  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).
- MBCook 4y ago
  They may not have been coalesced at the time the decision was made.
colejohnson66 4y ago
But NOPs aren’t even executed. They’re swallowed by either the decoder or dispatcher.
- wvenable 4y ago
  The article states that it's one cycle and slot per NOP.
  - colejohnson66 4y ago
    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 4y ago
      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 4y ago
      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.
- avianlyric 4y ago
  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.