Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Examining the silicon dies of the Intel 386 processor

righto.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Examining the silicon dies of the Intel 386 processor

#51

Post by fsckboy »

srejk wrote: post #18
kens wrote: post #2

Author here. I've been looking at the 386 if anyone has questions. This post was inspired by userbinator's discussion on HN a couple of weeks ago about how many transistors there are in the 386.

Great post! Any idea how the turbo button worked? It seems like, given the transistor difference between the 8086 and 386, that merely decreasing the clock frequency wouldn't be enough?

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"

Re: Examining the silicon dies of the Intel 386 processor

#52

Post by rasz »

srejk wrote: post #18
kens wrote: post #2

Author here. I've been looking at the 386 if anyone has questions. This post was inspired by userbinator's discussion on HN a couple of weeks ago about how many transistors there are in the 386.

Great post! Any idea how the turbo button worked? It seems like, given the transistor difference between the 8086 and 386, that merely decreasing the clock frequency wouldn't be enough?

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

Re: Examining the silicon dies of the Intel 386 processor

#53

Post by vikingerik »

rasz wrote: post #49
Waterluvian wrote: post #4

Earlier quoted context omitted.

Total amateur here: does a 386 have “cleverness” or optimizations or does it just quite literally chug through a stream of instructions, adjusting registers and memory? I guess by this I am thinking about how newer processors do all kinds of stuff at the microcode level that mean you cannot anticipate precisely what instructions are being executed in what order.

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.

Right, the 486 was only slightly optimized for IPC. Most of the 486's performance over the 386DX was from its L1 cache (or just called CPU cache at the time, there weren't different cache levels yet.) You can turn the cache off in a 486's BIOS and it will be barely any faster than a 386 of the same clock speed.

Re: Examining the silicon dies of the Intel 386 processor

#55

Post by nxobject »

kens wrote: post #16
Waterluvian wrote: post #4

Earlier quoted context omitted.

Total amateur here: does a 386 have “cleverness” or optimizations or does it just quite literally chug through a stream of instructions, adjusting registers and memory? I guess by this I am thinking about how newer processors do all kinds of stuff at the microcode level that mean you cannot anticipate precisely what instructions are being executed in what order.

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 w…

That's really cool: having learned most of my digital design from an era where interpreted microcode was the norm, and the PDP-11 or early 68k was the pinnacle of hardware design worth teaching, I've always wanted to learn about the transitional designs from old-style microcode, to how shrunk forms of microcoding lived in superscalar CISC designs. (I'm still trying for lack of resources.)

Re: Examining the silicon dies of the Intel 386 processor

#56

Post by happycube »

a-dub wrote: post #45

wasn't the page mode mmu the most important new feature? iirc this allowed for fully protected virtual memory, even for legacy applications.

I'd say equally important to 32bitness, both were needed to run a proper BSD4.x/SystemV Unix (or clone ;) )

(The 286 was enough for a PDP-11 style UNIX, and the 8088 could run a hobbyest-level one OK.)

Re: Examining the silicon dies of the Intel 386 processor

#57

Post by sounds »

irdc wrote: post #26
srejk wrote: post #18

Earlier quoted context omitted.

Great post! Any idea how the turbo button worked? It seems like, given the transistor difference between the 8086 and 386, that merely decreasing the clock frequency wouldn't be enough?

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

I did some sleuthing to try to figure out what part of computing history this could refer to.

- Maybe because one could lower the "wait states" BIOS setting on PCs, and this became a selling point and was marketed? https://retrocomputing.stackexchange.com/questions/9779 https://retrocomputing.stackexchange.com/questions/18333

Note: it is often perceived that the CPU with more "wait states" was slower. But the above links point out how often the opposite is true.

- The Apple II era was a very different world. The CPU was relatively slower than the RAM. https://retrocomputing.stackexchange.com/questions/23541

Re: Examining the silicon dies of the Intel 386 processor

#58

Post by hyperman1 »

twism wrote: post #11

reminds me of the days computers had a "turbo" button and a LCD read out of the clock speed on the case. "66Mhz" => "90" ... now we're cooking

My 20/40MHz had an LED display. When I opened the case, I found the display had jumpers to make every combination of leds possible, even non numeric. A bag of jumpers was taped next to it. I'd put HI/LO on it, or 01/99, or make the turbo 20Mhz and the slow mode 40.

Re: Examining the silicon dies of the Intel 386 processor

#59

Post by lizknope »

chasil wrote: post #13
colejohnson66 wrote: post #7

Earlier quoted context omitted.

Love the post! Some DOI and Bitsavers links are broken (linking to righto.com or 404s). Also, where can I find "Automatic Place and Route Used on the 80386"? DDG only contains one result: this post.

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 i…

I've been in physical design since 1997. Back then we were using Cadence Gate / Silicon Ensemble.

We tried the various Avanti tools. Aquarius, Astro, Apollo. I don't remember the exact order but all the space theme names are where the MilkyWay database comes from that is still in Synopsys IC Compiler.

I remember that when the court actually compared the source code they found that some of the comments had the same words misspelled in the same way. Two programmers may pick the same variable names but they aren't going to misspell words the same way in comments unless it was stolen code.

Re: Examining the silicon dies of the Intel 386 processor

#60

Post by a-dub »

happycube wrote: post #56
a-dub wrote: post #45

wasn't the page mode mmu the most important new feature? iirc this allowed for fully protected virtual memory, even for legacy applications.

I'd say equally important to 32bitness, both were needed to run a proper BSD4.x/SystemV Unix (or clone ;) ) (The 286 was enough for a PDP-11 style UNIX, and the 8088 could run a hobbyest-level one OK.)

> 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)

Post reply on HN