Intel's First x86 CPU Had Secret Instructions Meant to Catch IP Thievery

The 8086 code blocks
(Image credit: Ken Shirriff via righto.com)

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.

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.

The 8086 code blocks

The first 256 opcode entries out of the total 512 in Intel's 8086 weren't all populated, meaning that there was functionality that wasn't finished... or information kept secret. (Image credit: Ken Shirriff via righto.com)

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.

Francisco Pires
Freelance News Writer

Francisco Pires is a freelance news writer for Tom's Hardware with a soft side for quantum computing.

  • dehjomz
    Would NEC beat Ryzen today? The world will never know.
    Reply
  • digitalgriffin
    When you can't beat them, sue them.

    3dfx -> sues nvidia
    Creative Labs & nvidia -> sue individual developers for reenabling hardware.
    Reply
  • hotaru.hino
    x86 to this day still has instructions that aren't officially accounted for, simply because the instruction set allows for a mind boggling amount:
    GiBgJvW5hF0
    Reply
  • LabRat 891
    I can't help but wonder if some of these 'gotchya' undocumented features are intertwined with ix86's ancient and ongoingly-discovered basal security flaws...
    Reply
  • bit_user
    dehjomz said:
    Would NEC beat Ryzen today? The world will never know.
    I know it's not a direct answer, but still loosely related.
    https://www.nextplatform.com/2023/03/23/is-this-the-end-of-the-line-for-nec-vector-supercomputers/
    Reply
  • bit_user
    digitalgriffin said:
    When you can't beat them, sue them.

    3dfx -> sues nvidia
    Creative Labs & nvidia -> sue individual developers for reenabling hardware.
    You forgot ARM vs. Qualcomm/Nuvia.

    Anyway, let's see how the RISC-V market develops.
    Reply
  • ddoraemon4699
    Hello i really dont understand the hold thing please some give me a tutor on details on how intel 86\00d7 can detact what and all
    Reply
  • hotaru.hino
    ddoraemon4699 said:
    Hello i really dont understand the hold thing please some give me a tutor on details on how intel 86\00d7 can detact what and all
    If you're asking how Intel could figure out if someone was stealing their IP, they would just have to run the undocumented instruction that they specifically marked on a processor they suspected was copying their design. If the instruction behaved the same as Intel designed it for their processors, they had a good case that someone copied their processor without permission.

    It's a similar tactic for map makers. They'd sometimes contain deliberate errors (misspellings, fake locations, etc) as "copyright traps." If someone copied the entire map wholesale, they'd also include the errors, which was evidence enough the person simply copied the map.
    Reply
  • Maxor1
    digitalgriffin said:
    When you can't beat them, sue them.

    3dfx -> sues nvidia
    Creative Labs & nvidia -> sue individual developers for reenabling hardware.
    There's no way that Intel being the awesome company they are would ever do something like engage in deceptive or market manipulation practices to change illegally or unethically harm their competition. Which leads me to ask, has Intel ever gotten around to paying Advanced Micro Devices the penalties awarded them by the EU? How is Via doing in the x86 market these days?

    Part of why Intel is as concerned about corporate espionage and intellectual property as they are is because they are very aggressive in hitting the other guys.
    Reply
  • hotaru.hino
    Maxor1 said:
    Which leads me to ask, has Intel ever gotten around to paying Advanced Micro Devices the penalties awarded them by the EU?
    If they haven't, I'm pretty sure we would've heard something about this again. Keep in mind that payments like this aren't often lump sums, but over time.

    Maxor1 said:
    How is Via doing in the x86 market these days?
    Existing

    Maxor1 said:
    Part of why Intel is as concerned about corporate espionage and intellectual property as they are is because they are very aggressive in hitting the other guys.
    You kind of have to be in the market they're in.

    The thing is with IP protection, if you don't enforce it, then you're opening yourself up to some other company with the manufacturing capabilities to take your ideas and undercut you since you had to spend a lot of money for R&D and manufacturing, while the other company only had to spend money for manufacturing (more or less). I'm sure AMD is just as protective of their processor IP as Intel, but Intel's the easier target to pick on.
    Reply