Conditions in the Intel 8087 floating-point chip's microcode
80 points
4 days ago
| 3 comments
| righto.com
| HN
kens
5 hours ago
[-]
Author here if anyone has questions...
reply
hnthrowaway0315
1 hour ago
[-]
Hi kens, thanks for the knowledge sharing all these years. Can you please confirm this one? From Wikipedia, it says that 8087 uses CORDIC algorithm. Does that mean that it's the same (but different speed) as what I'd implement the functions in software, except in microcode (which has more granularity than usual assembly code)?

I found it a bit surprising that as a 45-year old chip, there is no public information of its microcode. I guess hardware is indeed much more secret than software.

reply
kens
1 hour ago
[-]
Yes, the 8087 uses CORDIC. I extracted the constants from the 8087's internal constant ROM and they are arctangent and log values for the CORDIC algorithm. You can implement the same functions in software, which is what floating-point emulation libraries did back then.

There's almost no public information on the 8087 microcode, but I'm working on that :-)

reply
hnthrowaway0315
1 hour ago
[-]
Thanks Ken, appreciate the work!
reply
dapperdrake
48 minutes ago
[-]
Thank you for the deep dive.
reply
farseer
5 hours ago
[-]
Is there 8087 IP available in verilog etc?
reply
kens
4 hours ago
[-]
As far as I know, you can't get the 8087 itself as an IP block. You can get generic IEEE-754 floating-point as an IP block, e.g. from AMD: https://www.amd.com/en/products/adaptive-socs-and-fpgas/inte...
reply
pwdisswordfishy
4 hours ago
[-]
IPv6 has seriously gone too far.
reply
dboreham
5 hours ago
[-]
Until I read this I did not know that 1970s microprocessors had register renaming. Feel a little cheated, thinking for all those years that they were actually moving the bits.
reply
dapperdrake
45 minutes ago
[-]
If you work through a math problem with pen and paper or nand2tetris or nandgame.com then it becomes obvious that changing indexes into a register file (a.k.a. pointers) are way faster and easier than wires to move stuff around.
reply
peterfirefly
3 hours ago
[-]
How do you think the EXX and EX AF,AF' instructions work on the Z80?
reply
avadodin
2 hours ago
[-]
And EX DE, HL
reply
WalterBright
16 minutes ago
[-]
E to the u, du dx, E to the x, dx!
reply
kens
1 hour ago
[-]
If you feel cheated now, wait until you find out that the ALU in the 8-bit Z80 was just 4 bits. :-)
reply
0xsn3k
5 hours ago
[-]
super cool! i wonder how difficult it would be to recreate the entire chip at logic gate level in, say, VHDL or Verilog
reply
kens
5 hours ago
[-]
It would be difficult, but not impossible. The main problem is tracing out all the circuitry, which is very time-consuming and error-prone. Trust me on this :-)

The second problem is that converting the circuitry to Verilog is straightforward, but converting it to usable Verilog is considerably more difficult. If you model the circuit at the transistor level in Verilog, you won't be able to do much with the model. You want a higher-level model, which requires converting the transistors into gates, registers, and so forth. Most of this is easy, but some conversions require a lot of thought.

The next issue is that you would probably want to use the Verilog in an FPGA. A lot of the 8087's circuitry isn't a good match for an FPGA. The 8087 uses a lot of dynamic logic and pass transistors. Things happen on both clock edges, so it will take some work to map it onto edge-trigger flip-flops. Moreover, a key part of the 8087 is the 64-bit shifter, built from bidirectional pass transistors, which would need to be redesigned, probably with a bunch of logic gates.

The result is that you'd end up more-or-less reimplementing the 8087 rather than simply translating it to Verilog.

reply
dapperdrake
43 minutes ago
[-]
Noob here,

does VH have options for encoding working with both clock edges?

reply
kens
23 minutes ago
[-]
There's a difference between what Verilog will allow and what is "synthesizable". In other words, there is a lot of stuff that you can express in Verilog, but when you try to turn it into an FPGA bitstream, the software will say, "Sorry, I don't know how to do that." Coming from a software background, this seems bizarre, as if C++ compilers rejected valid programs unless they stuck to easy constructs with obvious assembly implementations.

Using both edges of a clock is something that you can express in Verilog, but can't be directly mapped onto an FPGA, so the synthesis software will reject it. You'd probably want to double the clock rate and use alternating clock pulses instead of alternating edges. See: https://electronics.stackexchange.com/questions/39709/using-...

reply
0xsn3k
4 hours ago
[-]
ah, i see, thanks for the insight! do you have any advice on how one might get started with IC reverse-engineering? i think it would be interesting to reimplement these chips in a way that's at least inspired by the original design
reply
kens
4 hours ago
[-]
How to get started reverse engineering? That's a big topic for a HN comment, but in brief... Either get a metallurgical microscope and start opening up chips, or look at chip photos from a site like Zeptobars. Then start tracing out simple chips and see how transistors are constructed, and then learn how larger circuits are built up. This works well for chips from the 1970s, but due to Moore's Law, it gets exponentially more difficult for newer chips.

I also have a video from Hackaday Supercon on reverse engineering chips: https://www.youtube.com/watch?v=TKi1xX7KKOI

reply
monocasa
4 hours ago
[-]
Do you have any good tips on what to look out for when buying a used metallurgical microscope for looking at decapped chips? Even if not a complete set constraints, I'd appreciate some off the cuff thoughts if you have the time.
reply
kens
3 hours ago
[-]
I use a basic metallurgical microscope (AmScope ME300TZB). An X-Y stage is very useful for taking photos of chips and stitching them together. A camera is also important; my scope has a 10MP camera. I'm not into optics, so I don't know what lens characteristics to look for.
reply