31–40 of 47 posts
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.
If you feel cheated now, wait until you find out that the ALU in the 8-bit Z80 was just 4 bits. :-)
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…
Yeah I remember when I first came across floating point stuff when trying to reverse engineer some assembly - I wasn't expecting something stack-based.
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…
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 to go to higher precision. After all, you have the chip in your computer.
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.
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…
Earlier quoted context omitted.
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…
> 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…
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. Not to mention the fact that memory bandwidth costs are 25% higher when dealing with 64-bit quantities, and floating point work is very often bandwidth constrained. There's more precision in 80-bit, but it's not free, and as you point out, there are techniques for managing the lack of precision.
> 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.
This sort of thing shows up in even the most prosaic places, of course:
https://blog.codinghorror.com/if-you-dont-change-the-ui-nobo...
In any event, while we're chatting, thank you for your longstanding work in the field.
Earlier quoted context omitted.
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…
> 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…
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…
The IEEE standard had included almost all of what Intel 8087 had implemented, the main exception being the projective extension of the real number line. Because of this deviation in the standard, Intel 80387 has also dropped this feature.
Where you are right is that most other implementers of the standard have chosen to not provide this extended precision format, due to the higher cost in die area, power consumption and memory usage, the latter being exacerbated by the alignment issue. The same was true for Intel when defining SSE, SSE2 and later ISA extensions. The main cost issue is the superlinear growth of the multiplier size with precision, a 64-bit multiplier is not a little bigger than a 53-bit multiplier, but much bigger.
Nowadays, the FP arithmetic standard also includes 128-bit floating-point numbers, which are preferable to 80-bit numbers and do not have alignment problems. However, few processors implement this format in hardware, and on the processors where it would need to be implemented in a software library one can obtain a higher performance by using double-double precision numbers, instead of quadruple precision numbers (unless there is a risk of overflow/underflow in intermediate results, when using the range of double-precision exponents).
In general, on the most popular CPUs, e.g. x86-64 based or Aarch64 based, one should use a double-double precision library for all the arithmetic computations where the traditional 80-bit Intel 8087 format would have been appropriate.
Earlier quoted context omitted.
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!