Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conditions in the Intel 8087 floating-point chip's microcode

righto.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Conditions in the Intel 8087 floating-point chip's microcode

#21

Post by dapperdrake »

kens wrote: post #6
0xsn3k wrote: post #4

super cool! i wonder how difficult it would be to recreate the entire chip at logic gate level in, say, VHDL or Verilog

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

Noob here,

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

Re: Conditions in the Intel 8087 floating-point chip's microcode

#22

Post by kens »

dapperdrake wrote: post #21
kens wrote: post #6

Earlier quoted context omitted.

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

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

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

Re: Conditions in the Intel 8087 floating-point chip's microcode

#24

Post by WalterBright »

I've always thought the 8087 was a marvelous bit of engineering. I never understood why it didn't get much respect in the software business.

For example, when Microsoft was making Win64, I caught wind that they were not going to save the x87 state during a context switch, which would have made use of the x87 impractical with Win64. I got upset about that, and contacted Microsoft and convinced them to support it.

But the deprecation of the x87 continued, as Microsoft C did not provide an 80 bit real type.

Back in the late 80's, Zortech C/C++ was the first compiler to fully implement NaN in the C math library.

Re: Conditions in the Intel 8087 floating-point chip's microcode

#25

Post by derefr »

kens wrote: post #22
dapperdrake wrote: post #21

Earlier quoted context omitted.

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

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 ass…

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

To my understanding, isn’t it more like there being a perfectly good IR instruction coding for a feature, but with no extant ISA codegen targets that recognize that instruction? I.e. you get stuck at the step where you’re lowering the code for a specific FPGA impl.

And, as with compilers, one could get around this by defining a new abstract codegen target implemented only in the form of a software simulator, and adding support for the feature to that. Though it would be mightily unsatisfying to ultimately be constrained to run your FPGA bitstream on a CPU :)

Re: Conditions in the Intel 8087 floating-point chip's microcode

#26

Post by Cold_Miserable »

WalterBright wrote: post #24

I've always thought the 8087 was a marvelous bit of engineering. I never understood why it didn't get much respect in the software business. For example, when Microsoft was making Win64, I caught wind that they were not going to save the x87 state during a context switch, which would have made use of the x87 impractical with Win64. I got upset about that, and contacted Microsoft and convinced them to support it. But…

x87 should have been killed off. It would have forced lazy game developers to use SSE around the 2005 era.

Re: Conditions in the Intel 8087 floating-point chip's microcode

#27

Post by kstrauser »

WalterBright wrote: post #24

I've always thought the 8087 was a marvelous bit of engineering. I never understood why it didn't get much respect in the software business. For example, when Microsoft was making Win64, I caught wind that they were not going to save the x87 state during a context switch, which would have made use of the x87 impractical with Win64. I got upset about that, and contacted Microsoft and convinced them to support it. But…

I’d agree that the engineering was brilliant (but 68882 gang represent!). Its ISA was so un-x86-like, though, as it was basically an RPN calculator. X86 had devs manipulating registers. X87 had them pushing operands and running ops that implicitly popped them and pushed the result back on the stack.

That’s not better or worse, just different. However, I can imagine devs of the days saying hey, uh, Intel, can we do math the same way we do everything else? (Which TBH is how you’d end up with an opcode for a hardware-accelerated bubble sort or something, because Intel sure does love them some baroque ISAs.)

Re: Conditions in the Intel 8087 floating-point chip's microcode

#28

Post by WalterBright »

kstrauser wrote: post #27
WalterBright wrote: post #24

I've always thought the 8087 was a marvelous bit of engineering. I never understood why it didn't get much respect in the software business. For example, when Microsoft was making Win64, I caught wind that they were not going to save the x87 state during a context switch, which would have made use of the x87 impractical with Win64. I got upset about that, and contacted Microsoft and convinced them to support it. But…

I’d agree that the engineering was brilliant (but 68882 gang represent!). Its ISA was so un-x86-like, though, as it was basically an RPN calculator. X86 had devs manipulating registers. X87 had them pushing operands and running ops that implicitly popped them and pushed the result back on the stack. That’s not better or worse, just different. However, I can imagine devs of the days saying hey, uh, Intel, can we do ma…

Eh, as far as compiler backends go, the RPN stack was worse.

I thought the X86_64 instruction set was a giant kludge-fest, so I was looking forward to implement the AArch64 code generator. Turns out it is just as kludgy, but at right angles. For example, all the wacky ways of simply loading a constant into a register!

Re: Conditions in the Intel 8087 floating-point chip's microcode

#29

Post by mschaef »

WalterBright wrote: post #24

I've always thought the 8087 was a marvelous bit of engineering. I never understood why it didn't get much respect in the software business. For example, when Microsoft was making Win64, I caught wind that they were not going to save the x87 state during a context switch, which would have made use of the x87 impractical with Win64. I got upset about that, and contacted Microsoft and convinced them to support it. But…

What do you mean by respect? Here's a layperson's perspective, at least.

Up through the 486 (with its built in x87), the x87 was always a niche product. You had to know about it, need it, buy it, and install it. This is over and on top of buying a PC in the first place. So definitionally, it was relegated it to the peripheries of the industry. Most people didn't even know x87 was a possibility. (I remember distinctly a PC World article having to explain why there was an empty socket next to the 8088 socket in the IBM PC.)

However, in the periphery where it mattered, it gained acceptance within a matter of a few years of being available. Lotus 1-2-3, AutoCAD, and many compilers (including yours, IIRC) had support for x87 early on. I would argue that this is one of the better examples of marginal hardware being appropriately supported.

The other argument I'd make is that (thanks to William Kahan), the 8087 was the first real attempt at IEEE-754 support in hardware. Given that IEEE-754 is still the standard, I'd suggest that x87's place in history is secure. While we may not be executing x87 opcodes, our floating point data is still in a format first used in the x87. (Not the 80-bit type, but do we really care? If the 80-bit type was truly important, I'd have thought that in the intervening 45 years, there'd be a material attempt to bring it back. Instead, what we have are a push towards narrower floating point types used in GPGPU, etc.... fp8 and f16, sure... fp80, not so much.)

Post reply on HN