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

41–47 of 47 posts

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

#41

Post by WalterBright »

mschaef wrote: post #37
WalterBright wrote: post #33

Earlier quoted context omitted.

> What do you mean by respect? The disinterest programmers have in using 80 bit arithmetic. A bit of background - I wrote my one numerical analysis programs when I worked at Boeing. The biggest issue I had was accumulation of rounding errors. More bits would put off the cliff where the results turned into gibberish. I know there are techniques to minimize this problem. But they aren't simple or obvious. It's easier t…

> The disinterest programmers have in using 80 bit arithmetic. I don't know, other than to say there's often a tendency in this industry to overlook the better in the name of the standard. 80-bit probably didn't offer enough marginal value to enough people to be worth the investment and complexity. I also wonder how much of an impact there is to the fact that you can't align 80-bit quantities on 64-bit boundaries. No…

Haha the calculator app misses one critical feature - a history of the numbers you typed in, so you can double check the column of numbers you added.

> thank you for your longstanding work in the field.

I sure appreciate that, especially since I give away all my work for free these days!

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

#42

Post by WalterBright »

avadodin wrote: post #36
WalterBright wrote: post #23

Earlier quoted context omitted.

E to the u, du dx, E to the x, dx!

I must admit I do not know what you are referencing here, sir, but it is always a pleasure to run into your comments on HN. So much positive compiler-dad energy.

It's the MIT song! At least it used to be, it was a long time ago.

> always a pleasure to run into your comments on HN.

Wow what a nice compliment! Makes my day!

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

#43

Post by WalterBright »

kstrauser wrote: post #40
WalterBright wrote: post #28

Earlier quoted context omitted.

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!

That's fair. Are there any instruction sets that strike you as pretty?

The PDP-11 instruction set. It fits neatly onto a single sheet of paper. It's all very regular and orthogonal. It's simplicity is a work of genius.

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

#44

Post by NetMageSCW »

WalterBright wrote: post #43
kstrauser wrote: post #40

Earlier quoted context omitted.

That's fair. Are there any instruction sets that strike you as pretty?

The PDP-11 instruction set. It fits neatly onto a single sheet of paper. It's all very regular and orthogonal. It's simplicity is a work of genius.

How do you feel about the 6502?

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

#45

Post by WalterBright »

NetMageSCW wrote: post #44
WalterBright wrote: post #43

Earlier quoted context omitted.

The PDP-11 instruction set. It fits neatly onto a single sheet of paper. It's all very regular and orthogonal. It's simplicity is a work of genius.

How do you feel about the 6502?

I never programmed one, and haven't studied its instruction set.

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

#46

Post by dlcarrier »

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 an electronics design background, I'm even more amazed that Verilog can't gracefully handle multi-phase clocks, let alone two phases of a single clock. That's a big part of getting the most out of your power and timing budget. Also, it seems half the discussion around clocking in FPGAs are around the metainstability of communicating between logic on separate single-phase clocks. If even one clock used two phases, you'd have entirely stateful conditions.

I've found that the FPGAs themselves can handle multi-phase clocks in combinatorial logic. If you want to use the built-in clock routing and latches, I would recommend running the output of the PLL to a LUT input, then outputting that input as well as its inverse from the LUT, routing each to a global clock input. That will keep the phase right at 180°, let you drive directly off global clock fanout, and let you run the clock at the highest frequency that the fabric supports.

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

#47

Post by dlcarrier »

derefr wrote: post #25
kens wrote: post #22

Earlier quoted context omitted.

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…

The non-synthesizable features of Verilog not only work in current simulators, they were expressly developed for that purpose. Verilog has those features to describe conditions that might exist in a semiconductor as manufactured, but aren't part of any design, so that they can be more accurately simulated. For example, a pin state can be unknown, or two pins can be connected with a delay line. These allow a real-life semiconductor to be characterized well enough to insert into a simulation of the electronics circuit as a whole.

It's more akin to directives than instructions. Debug instructions can also serve a similar purpose, although they actually run on the hardware, whereas compiler directives and non-synthesizable verilog instructions are never executed.

Post reply on HN