https://www.righto.com/2023/11/reverse-engineering-intel-386.html
The groundbreaking Intel 386 processor (1985) was the first 32-bit processor in the x86 line. It has numerous internal registers: general-purpose registers, index registers, segment selectors, and more specialized registers. In this blog post, I look at the silicon die of the 386 and explain how some of these registers are implemented at the transistor level. The registers that I examined are implemented as static RAM, with each bit stored in a common 8-transistor circuit, known as "8T". Studying this circuit shows the interesting layout techniques that Intel used to squeeze two storage cells together to minimize the space they require.
This discussion was created by hubie (1068) for logged-in users only, but now has been archived.
No new comments can be posted.
Reverse Engineering the Intel 386 Processor's Register Cell
|
Log In/Create an Account
| Top
| 4 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 1) by shrewdsheep on Monday November 13 2023, @01:35PM (1 child)
Not much to say, except that I appreciate these reverse engineering stories as they give me a glimpse into the bare metal that I'm pretty much oblivious to. Interesting that bits are stored by a loop of inverters. I guess a continuous current is always flowing through one of the legs. What wattage would that be?
(Score: 5, Interesting) by ChrisMaple on Monday November 13 2023, @04:07PM
Not counting leakage current, no power is dissipated while not switching. The "on" transistor has zero volts across it, so no power. The "off" transistor has no current flowing through it, so no power. With field effect transistors, no current is needed at the gate to keep the transistor turned on; just keep the gate at the proper voltage. This is unlike bipolar transistors, which require current at the base to keep the transistor turned on.
(Score: 3, Interesting) by bzipitidoo on Monday November 13 2023, @04:22PM (1 child)
Really, the 32bit addressing was an overdue change that was still not fully utilized thanks to DOS sticking with 16bits for another decade, until Windows 95. OS/2 could've moved the world to 32bit sooner, but it foundered thanks to IBM's not making networking integral. They didn't get it in time that networking was going to be big. Or, maybe they did understand but were too greedy and thought they could charge a high premium for networking. Microsoft was also slow to grasp that, but they figured it out before it was too late. Figured out that networking and a browser should be included, not sold separately as an expensive add-on. In 1994, patience with MS was running out. It was only that there really was no other acceptable option, certainly not OS/2. Linux did exist then, but still had a lot of rough edges. One that may seem trivial was the lack of any means to skip the login dialog, except runlevel 1, and that was too big a hammer to use just to avoid a login dialog. The main issue with Linux at that time was the lack of software such as an office suite, and most everyone was still developing for DOS. No AutoCAD for Linux, no sir!
The whole idea of segmented memory was crap, and the flat memory model, even if less than 32bit, was the way it should've been done from the outset. When I first understood how those machines worked, how they overlapped the addressing so that 32 bits could only address a 20 bit space, I thought there must be a good reason for the waste of having so very many different ways to address the same byte of RAM, but I couldn't think of any. It was hard to believe the designers didn't have a good reason.
Where Intel blew it was the bad virtualization and lack of good ways to implement the semaphores needed to support a multiuser, multitasking OS. Yes, the 386 was better at that than the 286. Yet it still wasn't great. Years and years of mainframe design to handle that stuff, and does Intel tap any of that? The 486 finally addressed the semaphore issue. Virtualization however has been improved so incrementally that even now, it's still in need of more. The current glaring hole is the lack of virtualization in the graphics. Maybe a bit unfair to blame the x86 family for that one, and yet, in the days of the 386, the first VGA capable systems were integrated into the motherboard.
(Score: 4, Informative) by maxwell demon on Monday November 13 2023, @08:17PM
The reason for the 8086 segmented architecture was backwards compatibility. While the 8086 was not machine code compatible to the 8085, it was still possible to automatically translate most machine code. This was in part thanks to the segmented architecture. Basically a program could ignore that there were more than 16 bits of address space.
Also note that back in that time, 1 MB was a huge amount of memory.
The Tao of math: The numbers you can count are not the real numbers.