How does the processor know how many bytes a machine code instruction takes?

Question

assembler

Some commands may take 1 byte more than others, as the machine determines how many bytes to read and decode.
The assembler has line numbers, and the command is on the line, but what is it in the machine code, they are not there, while the processor knows how many to calculate. Maybe part of the first bits determines how many bytes to count.

90                                                NOP           ;;//  почему  процессор к примеру 90 D9 05 B0
D9 05 B0 08 1E 01                      dword ptr ds:[11E08B0h]  
011E0879 DD 5D BC                   qword ptr [ebp-44h]  
 011E087C 8B 05 44 23 D0 03    mov         eax,dword ptr ds:[3D02344h] //  Console.WriteLine("SSS "+r)

Answer 1

x86 instructions are scattered quite randomly over the numerical range, not to mention their length, but it is much easier for the processor itself to decode instructions than for programs. It simply has a tree inside, if the high bit of the first byte of the instruction is 0, one branch, otherwise another. So he goes down the branches and, for example, reaches the instruction 01010b (push reg) and now he already knows that the length of this instruction is 5 bits + 3 bits of arguments. And it can even immediately launch the found instruction, if it is some kind of i286. And all in 1 cycle.

Answer 2

the first machine word of the command goes to the command decoder, and the command decoder already recognizes what to do with the rest of the words.
in a modern multi-stage decoder, this happens long before it is executed. so there are no delays.

Answer 3

There is no easy way to determine if pure hardcode is the length of the commands.
Here he sees 8B 05, so the address goes further.