Floating point provides a convenient, approximate representation of real numbers that can greatly simplify scientific and engineering algorithms. This article gives an overview of two floating point formats used in the z990 architecture and discusses key FPU issues that system architects should consider in new designs.
Big iron lessons: FPU architecture, now and then
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Looking for a comparison of FPU technology? don’t look here this is just a sales add for IBM processors and a were the best rah rah article.
It’s easy to see everything talking about a product written by the company that sells the product as a commercial. However, if you read and actually understand what the article says, it isn’t purely fluff. This stuff actually matters for real applications, and having different floating point implementations between compilers or hardware (because it might be done in software instead of hardware, and you might port something that had the number crunching done in software emulation instead of hardware) completely changes how many things behave in many cases. While a human working in base 10 with exact numbers will come up with one answer, a computer working in base 2 floating point will often come up with a close, but not exact answer, and another system will come up with another version of a close, but not exact answer. Even being .00000000000001 off can make all the difference between something working and something not working: I’ve seen it happen.
So, while there is inevitably sales material you can glean from this article, it is more than mere hype: it details a practical reason beyond a shadow of a doubt as to why it’s a “good thing” for the customer, and it isn’t merely a fancy buzzword.
The article only begins to touch on the differences between the S/360 base(16) floating point format and the IEEE base(2) floating point format. Comparing “digit” lengths is just so much noise, like comparing the lengths of Arabic and Japanese words transliterated into English.
The sample code doesn’t work. A first-term programmer will find the bugs, and a reasonably good professional programmer will quickly clean up the unnecessary iterations and parameterize the maximum number of iterations.
Call this article “FPU’s for Basket Weavers”…
The author fails to point out that the base-16 exponent in the original IBM floating format means that the mantissa could lose three bits, being reduced from 24 to 21 bits in single precision floating. This was a reduction from 7 to 6 decimal digits.
This is why so many programmers used double length foating as a matter of course. This is why a famous writer complained of, “the proliferation of lousy floating point hardware”.
Discrete transforms (i.e. FFT derivatives) have grown to be one of the foremost uses of the FPU. In this respect vector units, or explicitly parallel ISAs (i.e. EPIC) have grown increasingly more important as there is great potential for parallelization when executing these transforms, which are typically just nested loops.
In an article talking about “scientific and engineering algorithms”, you’d think there would be some sort of discussion about how vector units have changed the landscape in these fields. With the exception of Itanium (in which the ALU and FPU are both intrinsically vector units) you won’t find vector units in big iron, as HPC clusters have all but grasped the scientific market and big iron has been relegated mostly to running enterprise databases and applications.
I think the FPU test code is off by a “bit”. To get it to work I changed the following to get it to work:
float single_test=0.0, single_addend=0.0;
double double_test=0.0, double_addend=0.0;
to:
float single_test=0.0, single_addend=1.0;
double double_test=0.0, double_addend=1.0;