For me, this is peak Hacker News. I am happy I took the hard courses at uni to understand a post like this. I’m also happy that HN was there to stimulate this thinking at the time (2015). Even if I now don’t really do anything with my humble knowledge of low level programming, every time it feels consciousnesses enriching. And it’s an awesome feeling.
For people that don’t have access to a uni, I recommend nand2tetris.org
> ...they mentioned that it would be interesting to get high resolution images of the 80386 die and try to extract the microcode from it.
Can someone explain how is that from a high resolution image of the die the microcode can be reconstructed? I'm really curious, what's the process? Is the output some sort of Verilog? Does the process involve recognizing each and every transistor and model a circuit from that? I'm fascinated that something like this is possible at all...
I worked a bit on the extraction process so I can chime in here a bit. The first part is to just mark the x,y locations of where all the bits are, generally by the intersection of the rows and columns of the microcode array.
Then you have to classify them as 0's or 1's. Each is visually distinct, a 1 being encoded by the presence of a transistor and a gap in the polysilicon. We didn't have to guess which is which is by the nature of Intel microcode we could assume 0's were much more frequent, so a transistor meant a 1.
There are some automatic tools designed to perform this work via color thresholding, but they didn't work very well here because some of the mosaic was blurry, and a lot of dust had crept in which created false 1 bits.
Instead, we trained a convolutional neural network to classify the extracted bit regions into 0's and 1's. This was overlaid back onto the original mosaic as white or black squares at 50% opacity.
Then we spent several long, tedious days just checking the results for errors. Finally we had the raw 2d array of bits - the next step is to extract the microcode words from the bit array.
nand2mario has made a Verilog implementation from it. It currently runs DOOM, but some of the more fiddly protected-mode bits prevent it from running full operating systems (besides DOS). I'm sure the bugs will get ironed out eventually.
It turned out the die area saved by eliminating the complicated sequencer and microcode ROM enabled them to add another 16 datapath bits and make the first 32 bit microprocessor.
I wouldn’t say it didn’t have any microcode. It actually had a small PLA for sequencing the multi-cycle instructions. [0]
I don’t think anyone would actually label it as microcode (not when the entire point of RISC was to avoid microcode) they would call it a sequencer or finite state machine; But really it’s the same thing. It’s certainly much simpler than the full microcode of any contemporary CISC, and the bulk of instructions execute in a single cycle without using it.
If you want a design with zero microcode, you really need to look at MIPS, or the original Berkeley RISC. Those ISAs go out of their way to avoid multicycle instructions. Not entirely successfully, but they don't use PLAs [1] to implement any state machines for the few remaining instructions like multiply and divide.
[1]At least on the few MIPS designs I've looked at.And I'm not sure if they deliberately avoided PLAs for doctrine reasons, or it was just more efficient to do so.
This is an incredible piece of reverse engineering. Seeing the actual microcode implementation helps demystify how these older processors handled complex operations.
Wow. Virtual86 modes, the floating point unit, and memory paging really created an explosion of complexity within the microcode.
There's sort of a wild west nostalgia that came with the 8086 and 8088 chips and a sense of approachable individual adventure that came along with it. Staring into the 386 is like staring into the cold and dispassionate industrial machine future that Fritz Lang was trying to portray in Metropolis.
I agree with the first comment there, that it's important to know which revision of the 386 this came from, since the 386 did receive many small changes over its 22-year production run.
22 comments
[ 2.0 ms ] story [ 47.3 ms ] threadFor people that don’t have access to a uni, I recommend nand2tetris.org
Can someone explain how is that from a high resolution image of the die the microcode can be reconstructed? I'm really curious, what's the process? Is the output some sort of Verilog? Does the process involve recognizing each and every transistor and model a circuit from that? I'm fascinated that something like this is possible at all...
Then you have to classify them as 0's or 1's. Each is visually distinct, a 1 being encoded by the presence of a transistor and a gap in the polysilicon. We didn't have to guess which is which is by the nature of Intel microcode we could assume 0's were much more frequent, so a transistor meant a 1.
There are some automatic tools designed to perform this work via color thresholding, but they didn't work very well here because some of the mosaic was blurry, and a lot of dust had crept in which created false 1 bits.
Instead, we trained a convolutional neural network to classify the extracted bit regions into 0's and 1's. This was overlaid back onto the original mosaic as white or black squares at 50% opacity.
Then we spent several long, tedious days just checking the results for errors. Finally we had the raw 2d array of bits - the next step is to extract the microcode words from the bit array.
It's especially fun seeing his blog going back 33 years.
Easy to find a free pdf
I don’t think anyone would actually label it as microcode (not when the entire point of RISC was to avoid microcode) they would call it a sequencer or finite state machine; But really it’s the same thing. It’s certainly much simpler than the full microcode of any contemporary CISC, and the bulk of instructions execute in a single cycle without using it.
If you want a design with zero microcode, you really need to look at MIPS, or the original Berkeley RISC. Those ISAs go out of their way to avoid multicycle instructions. Not entirely successfully, but they don't use PLAs [1] to implement any state machines for the few remaining instructions like multiply and divide.
[0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruct...
[1] At least on the few MIPS designs I've looked at. And I'm not sure if they deliberately avoided PLAs for doctrine reasons, or it was just more efficient to do so.
[1]: https://openflexure.org/projects/microscope/
There's sort of a wild west nostalgia that came with the 8086 and 8088 chips and a sense of approachable individual adventure that came along with it. Staring into the 386 is like staring into the cold and dispassionate industrial machine future that Fritz Lang was trying to portray in Metropolis.
Still fun to look at though. Great post.
z386: An Open-Source 80386 Built Around Original Microcode
https://news.ycombinator.com/item?id=48248014
z386: An Open-Source 80386 Built Around Original Microcode - https://news.ycombinator.com/item?id=48248014 - May 2026 (22 comments)