Examining the silicon dies of the Intel 386 processor

Out of order execution was introduced in the Pentium Pro, the Pentium was already able to execute two instructions per cycle but was still in-order.

Note that this "magic" is mostly implemented not in microcode, but rather in hardwired logic.

Well, yes and no. The 386 is chugging through the stream of instructions sequentially, unlike modern processors. There are various clever optimizations, though. First, there is some pipelining, so the microcode for the next instruction can execute while the previous one is finishing. Second, the CPU has 16 bytes of prefetching, so instructions are fetched from memory asynchronously from their execution. So you know what instructions are executed and in what order, but the timing is fairly unpredictable.

I should mention that microcode in the 386 is pretty different from micro-ops that modern processors run. They both break machine instructions down into smaller steps. But microcode runs sequentially, while micro-ops are sort of tossed into the CPU and run independently through a dataflow engine, with everything sorted out at the end to look sequential. Confusingly, modern processors use "microcode" to hold the micro-ops for complicated instructions that can't be handled by the regular instruction decoder; this is sort of like old-style microcode, but not exactly.

One of the assertions of RISC is that microcode is a performance penalty, to be avoided.

And many have.

"To provide this rich set of instructions, CPUs used microcode to decode the user-visible instruction into a series of internal operations. This microcode represented perhaps 1⁄4 to 1⁄3 of the transistors of the overall design. If... the majority of these opcodes would never be used in practice, then this significant resource was being wasted."

https://en.m.wikipedia.org/wiki/Berkeley_RISC

386 is actually somewhat slower clock for clock than 286 for same 16bit code. So no, no optimizations. For example https://web.itu.edu.tr/kesgin/mul06/intel/instr/movs.html, 486 was only slightly optimized, it was Pentium where they finally started working on IPC.

Level of integration wasnt the thing that made 386SL special, there were 8088/8086 SoCs before it like NEC V40 used in 1987 Zenith Eazy PC or V50 in 1988 Akai S1000 https://en.wikipedia.org/wiki/NEC_V20#Variants_and_successor...

What made 386SL special was introduction of System Management Mode (SMM). Intel sued AMD over Am386 SMM implementation, AMD tried claiming its not really SMM but jut some left over debugging ICE implementation :D https://ir.amd.com/sec-filings/content/0000898430-94-000804/...

There was some discussion of the automatic placement in this panel interview.

If I remember correctly, the software that performed the placement was written by a graduate student who debugged it from a terminal at his dormitory. It was one of many project decisions on the i386 that management would have absolutely stopped had they been made aware.

https://www.computerhistory.org/collections/catalog/10270201...

"386 is a complicated processor (by 1980s standards), with 285,000 transistors..."

Interesting that ARM1 was only 25,000 transistors. Did the i386 really have additional features that justify an order of magnitude?

One thing is certain in retrospect: Intel should have bought Acorn, not Olivetti.

Edit: Wow, there is even more detail on the placement software in the Righto article; the software was "Timberwolf" written by Dr. Carl Sechen.

Edit2: It appears that later versions of Timberwolf were sucked into Yale's licensing.

...Sechen served as an expert witness in the Cadence/Avanti trial in 2000 and 2001... "I had a chance to examine a great deal of the code in question when I was an expert witness on the trial. It was amazing – I even saw my own TimberWolf code in their tool, where only a single line of code had been changed. And I don’t mean the earlier, far-inferior version of TimberWolf available from Berkeley. The version I found in Avanti’s suite was a far more state-of-the-art version that had somehow been ‘acquired’ from Yale."

http://www.aycinena.com/index2/index3/archive/uw%20-%20seche...

Edit3: Graywolf is a fork of the last free version of Yale's Timberwolf.

https://github.com/rubund/graywolf

Thanks! I've fixed the links, so let me know if you see any other broken ones.

The "Automatic Place and Route Used on the 80386" article is from Intel Technology Journal, Spring 1986, p29-34. I don't think you can find it anywhere; Pat Gelsinger sent me a copy. Email me (ken.shirriff@gmail.com) and I'll send it to you.

Looking at the die, I'd say roughly 1/3 of the die is standard cell. I think some of it was standard cell but with hand layout, rather than automatic place and route. About 1/4 is the datapath, which is highly optimized. Maybe 10% is the microcode ROM.

+1

What I like most about these articles, is that it shows how messy even high-tech can be:

All the details in fabrication techniques (and its effect on what logic designers can/can't do), some opcodes removed to make room on the die for a bugfix (?, see note 26), etc etc. "Ultimately all digital electronics is analog".

The business mistakes, and lucky recoveries.

Keep up the good work, Ken! (btw you typo'd an "8" and "6" in note 25 :-)

Yes, I think the turbo button just changes the clock speed. The 386 was designed to be binary compatible with the 8086, but normally ran faster.

This was often done by introducing wait states, so the processor would slow down while accessing main memory.

the lack-of-turbo button was included to enhance compatibility with older software that using timing tricks that relied on the clockspeeds of the older generations of processors. Those older processors would not have used the enhanced features of the new processors, just the backward compatible features. Turbo was a motherboard OEM feature, not a 386 feature. Otherwise, there was no reason not to run "turbo"

Chipset/motherboard specific. Clock, wait states, cache, later even SMM sleep.

I remember they had cubicles. Relatively glamorous compared to entirely open and echoey offices.

I updated the article with Brad's info :)

My dad says he does. I've connected him with Ken.

Excellent points!

System/360 is indeed interesting because (if my memory serves me) it was one of the first computational architectures to implement microcode (also, if I recall correctly, the necessity of updating of this microcode was one of the reasons that floppy drives were invented...)

I'm also a fan of the Motorola 68000 -- I used to have an Amiga 1000 "back in the day". I'd choose it over any 8 or 16 bit CPU of the time period, but (correct me if I am wrong) it didn't have an MMU -- which would have made it a less-than-ideal candidate for writing a modern-day Unix compatible operating system, although the authors of AmigaOS managed to pull off quite an impressive multitasking OS on it, despite this fact, nonetheless...

Also, as a 32-bit architecture (as opposed to discrete single-package IC CPU) we'd probably additionally want to remember the VAX 11/780 (1977) -- whose CPU was implemented as circuits of multiple simpler TTL IC's...

(Oh sure, IBM might have done something like that earlier -- but the VAX 11/780 brought down the cost of IBM's comparable computing offerings by at least one order of magnitude! -- Although, even so, the 11/780 still would have been ridiculously expensive to the average person of that time period... (and yes, I know it was intended for mid-sized to large businesses, not people! :-))

But anyway, great article, and yes, the IBM System/360 and 68000 were indeed groundbreaking!

There were rumours that the DX and SX chips were exactly the same:

Intel zapped the FPU on the SX to disable it. Apparently it cost more to make, but sold for less.

> The 286 was enough for a PDP-11 style UNIX,

i remember MWC coherent well! it was where i was first learned unix. :)

(except for maybe some vague memories of some unix like os for the atari st that i didn't really understand at the time, but those memories are extremely vague)