Reverse Engineering the Constants in the Pentium FPU | Hacker News Reader

Reverse Engineering the Constants in the Pentium FPU

righto.com

151 pointsmef23 comments

I guess the unused entries spell "bad FC" (for floating constant). Also I think constants 6 through 10 are relevant for the decimal-to-binary conversion or vice versa, as evident from the following observation:

    0x5c3bd5191b525a249 ~= 2^123 / 10^17
    0x470de4df820000000  = 2^13 * 10^16

Thanks! I think you've figured out those mystery constants. How did you recognize them?

That somehow looked very similar to the typical powers of ten table found in floating point conversion routines. I got the first confirmation by searching for 0x5c3bd5191b525a249 / 2^67, which happened to match how many exabytes are equal to 5 exbibits.

I've updated my article along with a credit to you. Unfortunately, I couldn't figure out the other constants despite a whole lot of brute-force checking.

There used to be a site called the Inverse Symbolic Calculator (also a sibling site, Plouffe's Inverter) where you could give in a decimal expansion and it would search for known constants. Unfortunately, it seems to be down (the frontend exists, the backend just gives 404). Maybe someone else made something similar?

Edit: I found https://mrob.com/pub/ries/, which may or may not help.

The ries program is very cool for turning a number into an equation. However, I tried it on some of the Pentium constants and it didn't do very well. In particular, it seems to be allergic to numeric constants, preferring complicated symbolic expressions. For instance, if I put in 0.5625, I expect to get 9/16 out. However, ries doesn't come up with that, instead suggesting the best answer is sin(pi*sqrt(x)) = 1/sqrt(2). It's impressive that it came up with that formula, but it's not helpful.

Yes, I feared as much. Perhaps trying to get a copy of Piouffe’s inverter would be possible, but I don't know.

Yeah, RIES won't work well with that because there are too many constants to test out for RIES. AFAIK RIES doesn't natively handle constants larger than 9 partly to reduce the already enormous search space.

Constant 9 does match the expression ( at least when I truncate the output in KCalc 2^13*10^16/2^28 shows base16 0x470de4df82 )...

However, I don't know enough about floating point conversion to understand why that value's useful, or why it's stored where a fractional part normally would be in that same format.

Constants 6 and 7 visually appear to be in a similar fractional range and possibly as if extending precision of a fraction to 8 bit, 16 bit, and 32 bit words. I wonder if something along that line of thought might have an answer similar to the constant 10.

The FPU supports decimal numbers in BCD (binary-coded decimal). Presumably these large powers of 10 are useful for BCD conversion, especially since they are near other BCD-related masks. But they aren't normal floating-point numbers, so they don't have exponent parts. Yes, constants 6 and 7 look like they should be part of the same sequence, but nothing that I try will work.

Fun trivia: for many years Intel documentation was wrong on error bounds in trigonometric functions: https://randomascii.wordpress.com/2014/10/09/intel-underesti...

Author here for your Pentium questions...

Feels like an honor to be able to ask. I've appreciated your work for a few years now especially on the Apollo gear restoration.

Anyway, question on the ones you thought were wrong (I think "just" the trig functions). Is there a running system you can use that can be used to confirm your findings? Especially considering your previous post on the pentium division bug, maybe they got this wrong too?

A running system won't really help me since I'm sure it will give the right answer. I need to know what's happening internally, which remains hidden in a running processor.

Hello! In your view, did the move to IEEE 754 floating-point make things easier or harder for CPU designers?

My guess is that it made things both easier and harder. Harder in the sense that you couldn't just throw together floating point circuits; you had to deal with lots of special cases. But easier in the sense that the tricky design decisions were already made for you. And easier to test against a known standard.

For what its worth, Intel was one of the major contributors to IEEE 754. In a lot of ways the original 8087 behavior became an early IEEE 754 draft.

Are you working your way up through the eras of CPU's? How far do you predict you'll be able to get? (Ps. Thanks for all the awesome insight you've shared)

It's sort of random. My intent is to focus on the 8086, but someone asked about the 386 so I looked at that a bit. Then I saw the Navajo Pentium rug in a museum so I figured I should look at a real Pentium to compare. And then I wondered if I could find the FDIV bug. So one thing leads to another. I don't think I'll be able to go much beyond the Pentium with an optical microscope, though.

Do I understand it right that excluding the two metal layers, there's only a single "layer" of "logic" inside? I reckon newer CPUs have multiple, making imaging based reversing more difficult?

Even modern chips have a single layer of transistors, although there is research into 3D transistor stacking. (Flash memory stacks dies for more density.) Modern CPUs have much, much smaller transistors as well as constructing them more vertically (FinFET) but it is still a single layer. Modern processors can have over a dozen layers of metal, while the Pentium I examined has just 3 metal layers. I'm not going to be reverse-engineering a modern chip since you need an electron microscope to see the features; the features are orders of magnitude smaller than the wavelength of light.

Really interested in the debug and test systems accessible though JTAG. So many undocumented endpoints, especially starting with the ppro.

Ken, how has the technology for interconnects changed over the years? Seeing all of these disparate regions in 2D it really interests me on how they are routed.

Reply on news.ycombinator.com