Hardware sleuth Ken Shirriff took to his blog to explore the feature set and possible operations one could bring out of the world's oldest x86 CPU - the Intel 8086. By following the 8086's microcode operations, Shirriff found some unexpected design "choices": from proprietary microcode meant to trap IP thieves through questionable (but necessary) design decisions that allowed 8086 processors to run unknown instructions (with equally little-known results), the detective work shines some light on what is likely the most important CPU release in the last fifty or so years.
The world's first implementation of the x86 instruction set on Intel's 8086 was about as you'd expect from a CPU released back in the late seventies. While today's leading-edge chips can carry hundreds of billions of transistors (the basic building blocks for more complex circuits), Intel's first commercial x86 CPU, the 5-10 MHz Intel 8086, had to make do with a mere 29 thousand of them.
Modern processors block you from executing nonexistent instructions. But early microprocessors like the Intel 8086 (1978) didn't check for illegal instructions. Running one could provide hidden functionality or even give access to hidden registers you couldn't otherwise access.🧵 pic.twitter.com/BCdp7ZBY6VJuly 16, 2023
More transistors generally equal more performance and especially more functionality (increased support for more varied and complex instructions and hardware-based acceleration are the poster child here). Then, like now, a balance between performance, power efficiency, and transistor counts/die area enforced hard limitations on how transistor allocations were handled - and ultimately, what features were deemed "necessary" and "disposable."
According to Shirriff's finding, one particular quirk of Intel's 8086 is that the CPU didn't possess any checks and balances for running microcode - the closest-to-the-metal layer between software and hardware that's responsible for dividing complex instructions into a series of simpler, step-by-step ones that the CPU can execute. But with transistors being limited to 29,000, Intel opted not to include a hardware-level lock on what instructions could and couldn't be run. Usually, instructions work on a whitelist basis - the CPU allows for the execution of microcodes that it already knows can be processed within its hardware design.
But since Intel's 8086 was so tight for transistor space, the company actually didn't bake in the microcode operation whitelist that the CPU could process, meaning that in the presence of "illegal" (read: non-supported) microcode ops, Intel's 8086 tried its best to resolve the microcode operation anyway - without specifying the result of the "illegally requested" operation.
All in all, the Intel 8086 supported 521 instructions, held in its Microcode ROM chip (Read-Only Memory). Some of those 512 instructions were duplicates (as fall-back mechanisms and other reasons), but others were never made public: certain microcode operations were left undocumented - whether for planned functionality that was never implemented or for other reasons.
Yet one interesting microcode, as verified by Shirriff, aided Intel in defending its IP from would-be IP thieves. Populating an instruction list from the available 512 in the 8086's ROM, Shirring was able to discern the opcodes with known functions (in white); the ones in orange, yellow, and green were left blank for the 8086, but were populated on Intel's next processors, the 80186, 80286, and 80386 respectively; and finally, the purple outlier: an opcode that was implemented in Intel's 8086 and subsequent processors, but that was never openly documented.
Shirriff's take on the undocumented purple flag - which was only brought to light in Intel's documents as late as 2017, despite living within the company's x86 design since the 8086 - is that it served as a honeypot of sorts for anyone looking to copy Intel's technology. If a company had cut corners in developing their own CPU solutions and had instead pilfered Intel's microcode IP, then their CPUs would carry the same SALC (Set AL to Carry) operation when fed the relevant bits of machine code - it's equivalent to a barcode identification that'd allow Intel to more effectively prosecute any IP stealers.
Unfortunately, the "copyright trap" microcode didn't serve Intel very much, not even in the early days of the 8086 when the competition was more varied: Intel hoped that its SALC instruction had been implemented in NEC's own (and better) take on Intel's x86 processors in the form of the NEC V20 and NEC V30 processors. But it wasn't: a federal ruling from 1989 asserted that NEC hadn't infringed Intel's copyright (and the SALC instruction, therefore, wasn't there). But other things happen when a copyright infringement suit is launched, things that have little to do with the merits of the copyright itself. Intel's decision to sue and block NEC and the sale of its V20 and V30 processors is part of the reason why there aren't more players in the cut-throat-competitive scene of x86 chip design.
