Gregory's ServerThe Intel 8086 processor (1978) has a complex instruction set with instructions from 1 to 6 bytes long. How does the processor determine the instruction length? It turns out that there is no explicit length. A ROM says if 1 or 2 bytes, then the microcode fetches bytes until done. 🧵
 15 comments
An instruction implemented in logic (e.g. Clear Carry) or a prefix is executed directly. Otherwise the microcode engine starts executing the micro-instructions that make up the machine instruction. Microcode to add an immediate word to a register. It fetches two bytes from the prefetch queue Q to the temporary B register of the Arithmetic/Logic Unit, then stores the sum Σ. Note that the microcode fetches two bytes. Plus the opcode, that makes this a 3-byte instruction. If the instruction uses a ModR/M byte to specify a memory address, the loader fetches both bytes. Then the microcode might fetch more. This microcode for an address displacement fetches two bytes from the Q, so a 4-byte instruction overall. Variable-length instructions make life difficult for modern superscalar x86 processors. They must split the bytestream into instructions in advance to run instructions in parallel. This takes a lot of logic to analyze the instructions and find the length. But it could be worse. The Intel iAPX 432 (1981) was supposed to be Intel's main processor. It had instructions from 6 to 321 *bits* in length so instructions weren't even byte aligned. The iAPX 432 was too complicated, went way over schedule, and was a commercial failure. For more details, see my blog post: https://www.righto.com/2023/02/how-8086-processor-determines-length-of.html Credit: die photo of the iAPX 432 is from Intel and the Computer History Museum. https://www.computerhistory.org/collections/catalog/102652367 Simplicity was what I liked about the PDP-8. But then, there are limits what you can do with a 12-bit instruction size, 12-bit bus width, ...  @kenshirriff Holy shit that was ambitious https://en.wikipedia.org/wiki/Intel_iAPX_432#Architecture  @kenshirriff I worked on computers with many different architectures in this time period, but never saw one based upon the iAPX 432. It seemed like most of even the ideas of this processor were judged to be architectural dead ends, and there were essentially no spiritual successors of any note. Am I wrong?
[DATA EXPUNGED]
 @kenshirriff This is the paper that sank the iAPX 432. It was demonstrably slower than the 8086 it was supposed to replace. I'm *really* curious to know if there's a working copy of the '432 in existence today. Have you come across one? https://archive.org/details/PerformanceEvaluationOfTheIntelAPX432  @kenshirriff US Patent 6883087 (now expired so I can talk about it) describes a method to compress x86 instructions by splitting the bytes depending on their meaning in the instruction, i.e. a stream of opcodes, a stream of ModR/M, a stream of immediates, etc..., and decompressing by following a very similar decoding logic. Compression was around 5x in practice, compared to 2x with zlib.  @kenshirriff i find it amazing that we've doomed ourselves to be stuck with an instruction set that was basically designed around the constraints and capabilities of a 512-word run of microcode The point is that the 8086 doesn't "know" how many bytes the instruction is. The Group Decode ROM says at least one or two, but then the microcode uses as many bytes as it needs. |
Instruction processing starts with the Group Decode ROM, which classifies instructions: 1 byte implemented in logic, a prefix, 1+ byte using microcode, or 2 bytes+ (including ModR/M byte) using microcode. A circuit called the loader gets 1 or 2 bytes from the prefetch queue.