5 ms·

80386 microcode disassembled

278 points by nand2mario 4mo ago

mettamage 4mo ago
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
- morphle 4mo ago
  Just building your own microprocessor from gates is an easier way to learn about designing microcode and understanding how processors work(ed). But it can't hurt to study a few simple old designs like RISC or Transputer. The 80386 is on the other side of that spectrum, needlessly complicated because they wanted to be backwards compatible with an old bad design. There certainly is no need to go to university to learn chip design. Watching a few Alan Kay talks [3] or browsing Bitsavers computer designs [4] are good starting points. We made an easier way (than FPGA) to simulate and convert your gate level design into transistors on a chip (for less than $200 in 2026). We call it Morphle Logic [1]. Eventually you grow into making the largest fastest and cheapest supercomputer wafer scale integration [2]. [1] https://github.com/fiberhood/MorphleLogic/blob/main/README_MORPHLE_LOGIC.md https://github.com/fiberhood/MorphleLogic/blob/main/README_M... [2]https://www.youtube.com/watch?v=vbqKClBwFwI https://www.youtube.com/watch?v=vbqKClBwFwI [3] https://www.youtube.com/watch?v=f1605Zmwek8 https://www.youtube.com/watch?v=f1605Zmwek8 [4] http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/Alto_Hardware_Manual_Aug76.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/...
  - joleyj 4mo ago
    > needlessly complicated because they wanted to be backwards compatible with an old bad design. It's not really needless complication of there is a reason for the complication. Obvioudsly in this case the need to be backward compatible with an old design made the implemtation more complicated than if they didn't need to do that. There were very, very strong business reasons why backward compatibility was a design requirment.
    - fortran77 4mo ago
      And was it a bad design? It was very succcessful and enabled a lot of progress.
- deskamess 4mo ago
  Do you know if nand2tetris covers/uses microcode?
  - drivers99 4mo ago
    It doesn’t. I posted a reply to the same comment before I saw your question. Even the books I mentioned didn’t really get into it. I tried a search for some that did and ran across Constructing a Microprogrammed Computer by O.J. Mengali which looks interesting. It says it has you implement the microcode for 4 different architectures. I’m going to check it out.
    - mettamage 4mo ago
      Ah that's a shame. I had a computer systems course at uni where we were playing around with the microcode from the MIC-1 created by Tanenbaum. I sort of figured that Nand2Tetris just had that in it.
- drivers99 4mo ago
  I did nand2tetris a couple times, but it emphasizes simplicity in every level of abstraction. That in itself is an amazing lesson and has been an inspiration, but that also means it skips things like microcode. In college (in the 1990s) I took a EE class as part of my CS degree that went through how an 8086-like[0] CPU is made, a lot like nand2tetris but without necessarily making each part an assignment. It did cover how microcode worked where there was an internal program counter that stepped through a table of control words whose bits directly orchestrated each controllable piece of the CPU. We each got an instruction to implement on a simulator that the teacher had made previously. (I got DEC, decrement.) In a way I guess the instructions in nand2tetris are the microcode. The bits of the instructions directly control the hardware with the first bit choosing 2 instruction types, so there’s only 1 step of code per instruction, unlike with microcode where an instruction can have any number of microcode steps. In Ben Eater’s series of videos building an 8-bit CPU on breadboards he has ROMs that are indexed by the opcode (4 bits of the instruction) + a step counter to determine the control word. The ROM stands in for what could be done with sufficiently complicated logic gates. I like it as a next step on the hardware side as you get hands on experience with electronics and having to troubleshoot it. It’s disappointing how it only has 16 bytes of RAM so you can’t really build higher levels of abstraction like you can with nand2tetris. But at that point you could (I should) either redo it with a better design (and put it on PCBs) or move on to the 6502 project, and then since that puts together a timer, CPU, ROM, RAM, I/O, UART, etc. mentally group those together and move on to microcontrollers that already have them together. Anyone interested in reading about how a CPU could be made out of logic gates could also read Code by Charles Petzold (moves slower, recently updated) and/or Pattern on the Stone by Danny Hillis (moves faster). Edit: I just checked Code (2nd edition) and that uses a 4 bit cycle counter and hard logic gates to determine what to do each cycle. But then it uses an array of diodes for part of the logic. Would that be considered microcode? [0] there were classes that covered more advanced (pipelined) CPUs in another CS class but not at quite a low level where you felt like you could make one yourself
  - anthk 4mo ago
    You might like this, a CPU made by TTL's running Minix 2. https://www.homebrewcpu.com/ https://www.homebrewcpu.com/ I might upload Tristam Island (Z-Machine v3 game, like Zork and infocom games they already have the interpreter) among the feelies in ASCII format. Yes, dfrotz runs snappier than the vi clone they have. And more stable than their ed implementation.
bmenrigh 4mo ago
The black box analysis needed to decode this is incredibly hard but also incredibly fun and rewarding to pull off. Very impressive work.
liendolucas 4mo ago
> ...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...
- dboreham 4mo ago
  The microcode is in a ROM. It's a regular structure where a 1 looks different to a 0.
  - jdblair 4mo ago
    Yes, literally this. No verilog decode, just looking for signals in the image of a 1 vs. a 0. For example, a 1 may be the existence of a transistor at a particular intersection of wiring.
    - liendolucas 4mo ago
      So what you actually need is a program that navigates through the huge image of the die and detects if the structure that is looking at is a 1 or a 0? This at the fundamental level is a cross between machine learning and image processing?
      - bri3d 4mo ago
        Yes, exactly. Historically you would make some simple image processing software that will align the grid and then look for properties at each specific bit position. Usually die shots are highly imperfect (the delayering usually leaves some artifacts or damage) so frequently merging multiple scans is important as well. Travis Goodspeed has a neat tool for this workflow at https://github.com/travisgoodspeed/maskromtool https://github.com/travisgoodspeed/maskromtool and the blog mentions John McMaster’s bitract: https://github.com/SiliconAnalysis/bitract https://github.com/SiliconAnalysis/bitract although I think most people working on these projects usually just one-off it as the mentioned Discord users in the blog post eventually did. More modern devices are of course more difficult due to layers, feature size, and less visually obvious ROM bit designs. Anyway, the impressive part of this project was really understanding the undocumented microcode assembly language through inference and trace following; the 1s and 0s look like they were the easy part!
trollbridge 4mo ago
I checked reenigne's blog a few days ago. "Hmm, nothing posted since 2020. Oh well." It's especially fun seeing his blog going back 33 years.
- kgwxd 4mo ago
  Maybe the hit counter increment was the inspiration for the post.
  - whent 4mo ago
    Where's the hit counter? Mind pointing me to it. Can't find it anywhere at TFA.
    - ChrisClark 4mo ago
      He's making a joke. As in, "the site is so old, it probably still has a hit counter."
p1esk 4mo ago
Here’s a great book explaining microprogramming from ground up: https://www.amazon.com/Computation-Structures-Optical-Electro-Optical-Engineering/dp/0070681473 https://www.amazon.com/Computation-Structures-Optical-Electr... Easy to find a free pdf
yukIttEft 4mo ago
If you put this into an emulator, would it boot linux?
- GloriousCow 4mo ago
  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.
Dwedit 4mo ago
Meanwhile the original ARM didn't use any microcode at all.
- themafia 4mo ago
  Yet their purity brought them no commercial benefit.
  - Dwedit 4mo ago
    ARM got all the commercial benefit once they switched from making chips to providing full designs ready to integrate into other chips.
    - themafia 4mo ago
      > to providing full designs ready to integrate Yes, once the market came into existence, ARM was well situated to take advantage of it. > all the commercial benefit "All" is a tricky term to use here. They got some. An appreciable amount even. Their business model leaves quite a bit on the floor compared to desktop chips.
  - chadgpt3 4mo ago
    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.
- phire 4mo ago
  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. [0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruction-decoding-and.html 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.
danborn26 4mo ago
This is an incredible piece of reverse engineering. Seeing the actual microcode implementation helps demystify how these older processors handled complex operations.
Levitating 4mo ago
I wonder if an OpenFletcher[1] would be able to get such images [1]: https://openflexure.org/projects/microscope/ https://openflexure.org/projects/microscope/
- kiddico 4mo ago
  I'm absolutely going to make one of those
themafia 4mo ago
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. Still fun to look at though. Great post.
compliancedoc 4mo ago
Great!
ChrisArchitect 4mo ago
Related: z386: An Open-Source 80386 Built Around Original Microcode https://news.ycombinator.com/item?id=48248014 https://news.ycombinator.com/item?id=48248014
dang 4mo ago
Related ongoing thread: z386: An Open-Source 80386 Built Around Original Microcode - https://news.ycombinator.com/item?id=48248014 https://news.ycombinator.com/item?id=48248014 - May 2026 (22 comments)
cobbzilla 4mo ago
beautiful work! any plans for the 80387 coprocessor?
userbinator 4mo ago
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.
- rep_lodsb 4mo ago
  Well, one indication is the value loaded into EDX on reset: 9B5 BIST1 -> TMPD 0x0303 PASS2 9B6 SIGMA -> EDX 9B7 BIST2 -> TMPE TMPD XOR 9B8 SIGMA 0x3ddc0c2c XOR 9B9 SIGMA -> EAX BOOTUP_JUMP JFPUOK 0x303 = family 3, model 0, stepping id 3.
  - userbinator 4mo ago
    That's either a B0 or B1 according to https://www.pcjs.org/documents/manuals/intel/80386/ https://www.pcjs.org/documents/manuals/intel/80386/ , or an A3 according to https://www.geoffchappell.com/studies/windows/km/cpu/precpuid.htm https://www.geoffchappell.com/studies/windows/km/cpu/precpui... , all of which are very buggy.
danborn26 4mo ago
This is an incredible deep dive into the 386 architecture. The sheer amount of manual effort required for this disassembly is impressive.
danborn26 4mo ago
The amount of effort required to reverse engineer this microcode is impressive. Great deep dive into the 386 architecture.

278 points by nand2mario 4mo ago

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

morphle 4mo ago
Just building your own microprocessor from gates is an easier way to learn about designing microcode and understanding how processors work(ed). But it can't hurt to study a few simple old designs like RISC or Transputer. The 80386 is on the other side of that spectrum, needlessly complicated because they wanted to be backwards compatible with an old bad design. There certainly is no need to go to university to learn chip design. Watching a few Alan Kay talks [3] or browsing Bitsavers computer designs [4] are good starting points. We made an easier way (than FPGA) to simulate and convert your gate level design into transistors on a chip (for less than $200 in 2026). We call it Morphle Logic [1]. Eventually you grow into making the largest fastest and cheapest supercomputer wafer scale integration [2]. [1] https://github.com/fiberhood/MorphleLogic/blob/main/README_MORPHLE_LOGIC.md https://github.com/fiberhood/MorphleLogic/blob/main/README_M... [2]https://www.youtube.com/watch?v=vbqKClBwFwI https://www.youtube.com/watch?v=vbqKClBwFwI [3] https://www.youtube.com/watch?v=f1605Zmwek8 https://www.youtube.com/watch?v=f1605Zmwek8 [4] http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/Alto_Hardware_Manual_Aug76.pdf http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/...
- joleyj 4mo ago
  > needlessly complicated because they wanted to be backwards compatible with an old bad design. It's not really needless complication of there is a reason for the complication. Obvioudsly in this case the need to be backward compatible with an old design made the implemtation more complicated than if they didn't need to do that. There were very, very strong business reasons why backward compatibility was a design requirment.
  - fortran77 4mo ago
    And was it a bad design? It was very succcessful and enabled a lot of progress.
deskamess 4mo ago
Do you know if nand2tetris covers/uses microcode?
- drivers99 4mo ago
  It doesn’t. I posted a reply to the same comment before I saw your question. Even the books I mentioned didn’t really get into it. I tried a search for some that did and ran across Constructing a Microprogrammed Computer by O.J. Mengali which looks interesting. It says it has you implement the microcode for 4 different architectures. I’m going to check it out.
  - mettamage 4mo ago
    Ah that's a shame. I had a computer systems course at uni where we were playing around with the microcode from the MIC-1 created by Tanenbaum. I sort of figured that Nand2Tetris just had that in it.
drivers99 4mo ago
I did nand2tetris a couple times, but it emphasizes simplicity in every level of abstraction. That in itself is an amazing lesson and has been an inspiration, but that also means it skips things like microcode. In college (in the 1990s) I took a EE class as part of my CS degree that went through how an 8086-like[0] CPU is made, a lot like nand2tetris but without necessarily making each part an assignment. It did cover how microcode worked where there was an internal program counter that stepped through a table of control words whose bits directly orchestrated each controllable piece of the CPU. We each got an instruction to implement on a simulator that the teacher had made previously. (I got DEC, decrement.) In a way I guess the instructions in nand2tetris are the microcode. The bits of the instructions directly control the hardware with the first bit choosing 2 instruction types, so there’s only 1 step of code per instruction, unlike with microcode where an instruction can have any number of microcode steps. In Ben Eater’s series of videos building an 8-bit CPU on breadboards he has ROMs that are indexed by the opcode (4 bits of the instruction) + a step counter to determine the control word. The ROM stands in for what could be done with sufficiently complicated logic gates. I like it as a next step on the hardware side as you get hands on experience with electronics and having to troubleshoot it. It’s disappointing how it only has 16 bytes of RAM so you can’t really build higher levels of abstraction like you can with nand2tetris. But at that point you could (I should) either redo it with a better design (and put it on PCBs) or move on to the 6502 project, and then since that puts together a timer, CPU, ROM, RAM, I/O, UART, etc. mentally group those together and move on to microcontrollers that already have them together. Anyone interested in reading about how a CPU could be made out of logic gates could also read Code by Charles Petzold (moves slower, recently updated) and/or Pattern on the Stone by Danny Hillis (moves faster). Edit: I just checked Code (2nd edition) and that uses a 4 bit cycle counter and hard logic gates to determine what to do each cycle. But then it uses an array of diodes for part of the logic. Would that be considered microcode? [0] there were classes that covered more advanced (pipelined) CPUs in another CS class but not at quite a low level where you felt like you could make one yourself
- anthk 4mo ago
  You might like this, a CPU made by TTL's running Minix 2. https://www.homebrewcpu.com/ https://www.homebrewcpu.com/ I might upload Tristam Island (Z-Machine v3 game, like Zork and infocom games they already have the interpreter) among the feelies in ASCII format. Yes, dfrotz runs snappier than the vi clone they have. And more stable than their ed implementation.

bmenrigh 4mo ago

The black box analysis needed to decode this is incredibly hard but also incredibly fun and rewarding to pull off. Very impressive work.

liendolucas 4mo ago

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

dboreham 4mo ago
The microcode is in a ROM. It's a regular structure where a 1 looks different to a 0.
- jdblair 4mo ago
  Yes, literally this. No verilog decode, just looking for signals in the image of a 1 vs. a 0. For example, a 1 may be the existence of a transistor at a particular intersection of wiring.
  - liendolucas 4mo ago
    So what you actually need is a program that navigates through the huge image of the die and detects if the structure that is looking at is a 1 or a 0? This at the fundamental level is a cross between machine learning and image processing?
    - bri3d 4mo ago
      Yes, exactly. Historically you would make some simple image processing software that will align the grid and then look for properties at each specific bit position. Usually die shots are highly imperfect (the delayering usually leaves some artifacts or damage) so frequently merging multiple scans is important as well. Travis Goodspeed has a neat tool for this workflow at https://github.com/travisgoodspeed/maskromtool https://github.com/travisgoodspeed/maskromtool and the blog mentions John McMaster’s bitract: https://github.com/SiliconAnalysis/bitract https://github.com/SiliconAnalysis/bitract although I think most people working on these projects usually just one-off it as the mentioned Discord users in the blog post eventually did. More modern devices are of course more difficult due to layers, feature size, and less visually obvious ROM bit designs. Anyway, the impressive part of this project was really understanding the undocumented microcode assembly language through inference and trace following; the 1s and 0s look like they were the easy part!

trollbridge 4mo ago

I checked reenigne's blog a few days ago. "Hmm, nothing posted since 2020. Oh well." It's especially fun seeing his blog going back 33 years.

kgwxd 4mo ago
Maybe the hit counter increment was the inspiration for the post.
- whent 4mo ago
  Where's the hit counter? Mind pointing me to it. Can't find it anywhere at TFA.
  - ChrisClark 4mo ago
    He's making a joke. As in, "the site is so old, it probably still has a hit counter."

p1esk 4mo ago

Here’s a great book explaining microprogramming from ground up: https://www.amazon.com/Computation-Structures-Optical-Electro-Optical-Engineering/dp/0070681473 https://www.amazon.com/Computation-Structures-Optical-Electr... Easy to find a free pdf

yukIttEft 4mo ago

If you put this into an emulator, would it boot linux?

GloriousCow 4mo ago
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.

Dwedit 4mo ago

Meanwhile the original ARM didn't use any microcode at all.

themafia 4mo ago
Yet their purity brought them no commercial benefit.
- Dwedit 4mo ago
  ARM got all the commercial benefit once they switched from making chips to providing full designs ready to integrate into other chips.
  - themafia 4mo ago
    > to providing full designs ready to integrate Yes, once the market came into existence, ARM was well situated to take advantage of it. > all the commercial benefit "All" is a tricky term to use here. They got some. An appreciable amount even. Their business model leaves quite a bit on the floor compared to desktop chips.
- chadgpt3 4mo ago
  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.
phire 4mo ago
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. [0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruction-decoding-and.html 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.

danborn26 4mo ago

This is an incredible piece of reverse engineering. Seeing the actual microcode implementation helps demystify how these older processors handled complex operations.

Levitating 4mo ago

I wonder if an OpenFletcher[1] would be able to get such images [1]: https://openflexure.org/projects/microscope/ https://openflexure.org/projects/microscope/

kiddico 4mo ago
I'm absolutely going to make one of those

themafia 4mo ago

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. Still fun to look at though. Great post.

compliancedoc 4mo ago

Great!

ChrisArchitect 4mo ago

Related: z386: An Open-Source 80386 Built Around Original Microcode https://news.ycombinator.com/item?id=48248014 https://news.ycombinator.com/item?id=48248014

dang 4mo ago

Related ongoing thread: z386: An Open-Source 80386 Built Around Original Microcode - https://news.ycombinator.com/item?id=48248014 https://news.ycombinator.com/item?id=48248014 - May 2026 (22 comments)

cobbzilla 4mo ago

beautiful work! any plans for the 80387 coprocessor?

userbinator 4mo ago

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.

rep_lodsb 4mo ago
Well, one indication is the value loaded into EDX on reset: 9B5 BIST1 -> TMPD 0x0303 PASS2 9B6 SIGMA -> EDX 9B7 BIST2 -> TMPE TMPD XOR 9B8 SIGMA 0x3ddc0c2c XOR 9B9 SIGMA -> EAX BOOTUP_JUMP JFPUOK 0x303 = family 3, model 0, stepping id 3.
- userbinator 4mo ago
  That's either a B0 or B1 according to https://www.pcjs.org/documents/manuals/intel/80386/ https://www.pcjs.org/documents/manuals/intel/80386/ , or an A3 according to https://www.geoffchappell.com/studies/windows/km/cpu/precpuid.htm https://www.geoffchappell.com/studies/windows/km/cpu/precpui... , all of which are very buggy.

danborn26 4mo ago

This is an incredible deep dive into the 386 architecture. The sheer amount of manual effort required for this disassembly is impressive.

danborn26 4mo ago

The amount of effort required to reverse engineer this microcode is impressive. Great deep dive into the 386 architecture.