The 8086 has a 6-byte prefetch queue (photo), which is tiny compared to the megabytes of cache on modern processors, but it increased performance by about 50%. Intel ran a bunch of simulations to decide on the 6-byte queue (4-byte on the 8088 with its narrower 8-bit bus).
This diagram zooms in on the prefetch pointers and associated logic on the die. This circuitry takes up a significant chunk of the die.
A processor's program counter or instruction pointer (IP) keeps track of what instruction it will execute. But prefetching moves the IP ahead of its "real" value. Subtracting the queue length gets the "real" IP. A Constant ROM holds constants -1 to -6 for this correction.
The interface between prefetching and the microcode engine was the "loader". This state machine fetched the first two bytes of the instruction from the queue. It also let microcode start the next instruction a cycle before the current one ended by pipelining decoding.
Prefetching added a lot of complications to the memory control circuitry since prefetches and "regular" memory accesses both needed to use the bus and needed to avoid conflict. My blog post has more information on how 8086 prefetching works: https://www.righto.com/2023/01/inside-8086-processors-instruction.html
Inside the 8086 processor's instruction prefetch circuitry

The groundbreaking 8086 microprocessor was introduced by Intel in 1978 and led to the x86 architecture that still dominates desktop and se...

@kenshirriff I dont really grok this paragraph: "The 8086 does nothing to ensure consistency between the prefetch queue and memory if a prefetched instruction is modified in memory. In this case, the "stale" instruction in the queue is executed. This situation may seem contrived, but self-modifying code used to be fairly popular, where a program would change its own instructions."

So on the 8086 self modifying code must have modified instructions far enough so that they were not prefetched yet?

@kenshirriff
20 bits of address makes for 1 megabyte of address space, not 4 😅
@kenshirriff Great post Ken. Thanks for the in-depth analysis.