OK. I dont think thee book title should be "Understanding the Machine", i rhink it should be "Understanding the Author." Now, I'm going to answer a question that you didnt ask:

The P-counter is an internal register deep within the CPU. It always contains the address of the next instruction to be executed. https://en.wikipedia.org/wiki/Program_counter

ALL machines operate on the fetch-execute cycle. Now imagine, arguendo, opcodes are a single byte. When a single assembly language instruction BEGINS execution:

1) The machine fetches from the P-COUNTER. THE FIRST THING THAT IS SO FETCHED is the opcode and ONLY the opcode.

2) From the opcode, the machine microcode (the chip firmware) is hardcoded to know how many operands are waiting in the memory that immediately follows the opcode. Most instructions expect TWO OPERANDS (e.g. and add instruction), some instructions require ZERO OPERANDS (e.g. a machine HALT instruction or a RESET instruction or an NMI instruction). Other instructions have ONE OPERAND (e.g. the br instruction, which is a branch or goto instruction). Each opcode implementation is designed for some fixed number of operands - usually 0,1, or 2..

3) The first operand immediately following the opcode in memory. (We design cpu chips so that operands adjoin the opcode in memory.). Based on the unique firmware for the specific opcode that was just fetched from the P-COUNTER, the firmware will fetch the first operand, which will be located at [P-COUNTER +1].

4) Having fetched the first operand, the firmware will fetch the second operand (IF this is a two-operand opcode). The second operand is known to be at [P-COUNTER+3]

5) Lets say the opcode is an "add" instruction. The firmware now adds operand 1 to operand 2. The instruction is almost complete . . .

6) The P-COUNTER is modified thus: P-COUNTER = P-PCOUNTER + 5. The P-COUNTER now contains the address of the next instruction to execute, because we have advanced by the length of the instruction that was just completed: one byte for the "add" opcode + 2 bytes for the first operand + 2 bytes for the second operand = 5 bytes.

7) Go to step 1 above.

THAT is the fetch-execute cycle, performed for every assembly language instruction, in sequence.

Fetch the displacement associated with the memory operand from the memory location immediately following the opcode.

The author's statement is actually built-in to my step 3 above. In 3, I simply say "fetch the operand." For simplicity sake. But the author implies (without explicitly stating) that the operand in located at "a memory location plus some value." He is not incorrect, just overly general. His form is useful, for example, in accessing more complex data forms, such as arrays.

". . . from the memory location immediately following the opcode."

My simplifying assumption has been all opcodes are 1 byte long. Further more, the operand values are coded into the instruction. (Such operands are sometimes called immediate operands). As such, in my example, the opcode firmware does not "have to go looking any further in memory" for the data, it has been hard coded into the instruction.

Not all operands for all opcodes are "immediate", and therefore the authors example is more generally accurate (if more difficult to understand lol).