Re: Floating point format for Intel math coprocessors

I've run across a peculiarity concerning the format used inside the

>Intel math coprocessor. I have always >thought that the format used was in accordance with the IEEE 794

Unless IEEE 794 is something new, I think you mean IEEE 754.

standard, and every reference I've seen >on the web seems to imply that. But, as nearly as I can tell, it's not >the same. > >The IEEE standard for 32-bit floats says the format should be > > sign -- 1 bit > exponent -- 8 bits, power of 2, split on 127

With the proviso that the values of 0 and 255 for the exponent are special cases reserved for 0, Inf, denormals, and NaN.

mantissa -- 23 bits + phantom bit in bit 24. > >The Intel processor seems to use the following: > > sign -- 1 bit > exponent -- _SEVEN_ bits, power of _FOUR_ > mantissa -- sometimes 23 bits, sometimes 24. Sometimes phantom bit, >sometimes not. > When it's there, it's in bit _TWENTY_THREE_

I don't think so. Are you mistaking the lsb of the exponent for the "visible" phantom bit?

>You'll see that 1 --> 3f800000 (high bit is visible)

seee eeee emmm mmmm mmmm mmmm mmmm mmmm

0011 1111 1000 0000 0000 0000 0000 0000

s = 0, e = 127, m = 0

(-1)^s * 2^(e-127) * (1+m/(2^23)) = 1*1*1 = 1.0

but 2 --> 40000000 (high bit is not)

seee eeee emmm mmmm mmmm mmmm mmmm mmmm

0100 0000 0000 0000 0000 0000 0000 0000

s = 0, e = 128, m = 0

(-1)^s * 2^(e-127) * (1+m/(2^23)) = 1*2*1 = 2.0

>Try a few others and see what you get. Some will surprise you.

I'm not finding any surprises.

1.5 -> 3fc00000 seee eeee emmm mmmm mmmm mmmm mmmm mmmm 0011 1111 1100 0000 0000 0000 0000 0000 s = 0, e = 127, m = 0x400000 (-1)^s * 2^(e-127) * (1+m/(2^23)) = 1*1*1.5 = 1.5 2.5 -> 40200000 seee eeee emmm mmmm mmmm mmmm mmmm mmmm 0100 0000 0020 0000 0000 0000 0000 0000 s = 0, e = 128, m = 0x400000 (-1)^s * 2^(e-127) * (1+m/(2^23)) = 1*2*1.25 = 2.5

Perhaps I'm misunderstanding your point?



Change is inevitable, progress is not.
Reply to
Dave Hansen
Loading thread data ...

If you're talking about the format that IA32 FPs store values in memory, then I doubt it. If you're talking about the 80-bit internal format, I don't know. I've never tried to use that format externally.

I've been exchanging float data between IA32 systems and at least a half-dozen other architectures since the 8086/8087 days. I never saw any format problems.

It is IEEE though 794 doesn't sound right...

Grant Edwards                   grante             Yow!  .. this must be what
                                  at               it's like to be a COLLEGE
 Click to see the full signature
Reply to
Grant Edwards

... snip ...

... snip ...

What chips does this format appear in? I expect the presence or absence of normalization depends on the oddness of the exponent byte. It makes sense for byte addressed memory based systems, since zero (ignoring denormalization) can be detected in a single byte.

Chuck F ( (
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to

Actually, I think I've answered my own question, here. You really *are* that Jack.

What clues me in is your use of "phantom" here:

The same term used on page 50 in "Math toolkit..."

In my own experience, even that predating the Intel 8087 or the IEEE standardization, it was called a "hidden bit" notation. I don't know where "phantom" comes from, as my own reading managed to completely miss it.

So, a hearty "Hello" from me!


Reply to
Jonathan Kirwan

The sign bit is there, as the highest order bit -- just as you note. This is followed, working left to right, by the exponent which is in "excess 127" format. It's not a signed format, but an excess 127 format. A couple of special values, 0 and 255, are reserved for the fancy stuff. But those correspond to exponent values of -127 and +128 and no one is supposed to miss them. The mantissa is quite simply *always* associated with a hidden bit, which always leads the value.

Okay, the exception made to the above is for the exact value of zero, where the exponent is 0 and the mantissa is 0 and the hidden bit is assumed 0, as well.

I don't agree. At least, not yet in my experience. And I haven't seen an example below which makes your point.

Well, I know how to normalize. After writing a few complex-FP FFT routines for integer processors, it gets to be kind of routine and hum-drum. So I'll skip the explanation.

Interesting note about the 360. I only had a few opportunities to program in BAL and never got into the floating point formats.

High bit is *always* a 1, after normalizing (except for zero.) But, as you know, it is thrown away. Never kept.

Which doesn't make your point, because it's quite correct to use those two values to represent 1 and 2.

3F800000 is: 1 a word about it, and didn't find anything in a Google search. I'd

Well, I hope that helps some.


Reply to
Jonathan Kirwan

IIRC, the Navy's UYK-44 processor (probably UYK-20 as well, though I'm not sure it did FP) also used base 16 for the exponent, so increasing the exponent by 1 shifted the mantissa by 4. I dare anybody to claim that's a useful bit of information to have retained for 15+ years....

Grant Edwards                   grante             Yow!  .. bleakness....
                                  at               desolation.... plastic
 Click to see the full signature
Reply to
Grant Edwards

Could be worse, I could've explained what BAM variables were...

Grant Edwards                   grante             Yow!  YOW!! I am having
                                  at               FUN!!
 Click to see the full signature
Reply to
Grant Edwards

I _think_ it was UYK, since everybody prounouced it "yuck".

The 44 was a small version of the same architecture that was done by, um, Sperry (I think). Originally it was designed for use on submarines (A 44 chassis would fit (barely) through a submarine's loading hatch). A '20, OTOH, was more of a standard computer-room VAX-sized thing -- you'd have to build a sub hull around it.

A '44 consisted of a backplane full of very expensive little boards (about 3x6 inches). It took several of the boards for the CPU, and then there were memory and I/O modules. The whole thing, including power supply was the size of a small suitcase. The CPU was built out of AM2901 bit-slice processors, and executed a superset of the 20's instruction set.

The '44 was "standardized" as the Navy's official embedded computer. It was about as powerful as decent 8086 single-board-computer, only 100X larger and 1000X more expensive. It did have plug in cards for all the oddball USN-specific serial/parallel interfaces, which gave it a leg-up on commercial stuff. The '44 had FP, and the ones I played with used EEPROM/RAM instead of core (though core memory was available for it, IIRC). It was sort of cool that it could do polarrectangular coordinate transforms in a single machine instruction.

For the project I worked on, we would have embedded a couple

8086's and done C programs given our 'druthers, but NAVSEA insisted that we use '44s and write in CMS/2 or CMS-2 or whatever it was called. The also wanted us to use some OS or other from the '20. But, there was no way it could deal with the real-time requirements we had, so they let us write out own simple kernel.

The whole project was cancelled after a couple years (never even got a prototype working). A few years later it was revived and redesigned using "commercial" processors before being cancelled again.

Sure glad I'm out of defense work... ;)

Grant Edwards                   grante             Yow!  My forehead feels
                                  at               like a PACKAGE of moist
 Click to see the full signature
Reply to
Grant Edwards

Grin! Yep, I really am.

Hello. Re the term, phantom bit: I've been using that term since I can remember -- and that's a looooonnnngggg time. Then again, I still sometimes catch myself saying "cycles" or "kilocycles," or "B+". I first heard the term in 1975. Not sure when it became Politically Incorrect. Maybe someone objected to the implied occult nature of the term, "phantom"? Who knows? but as far as I'm concerned the term "hidden bit" is a Johnny-come-lately on the scene.

Back to the point. I want to thank you and everyone else who responded (except the guy who said "stop it") for helping to straighten out my warped brain.

It's nice that you have my book. Thanks for buying it. As a matter of fact, I first ran across this "peculiarity" three years ago, when I was writing it. I needed to twiddle the components of the floating-point number -- separate the exponent from mantissa -- to write the fp_hack structure for the square root algorithm. I looked at the formats for float, double, and long double, and found the second two formats easy enough to grok. But when I looked at the format for floats, I sort of went, "Gag!" and quickly decided to use doubles for the book.

It's funny how an idea, once formed, can persist. Lo those many years ago, I didn't have a lot of time to think about it -- had to get the chapter done. I just managed to convince myself that the format used this peculiar convention, what with base-4 exponents, and all. I had no more need of it at the time, so never went back and revisited the impression. It's persisted ever since.

All of the folks who responded are absolutely right. Once I got my head screwed on straight, it was quite obvious that the format has no mysteries. It is indeed the IEEE

754 format, plain and simple. The thing that had me confused was the exponents: 3f8, 400, 408, etc. With one bit for the sign and eight for the exponent, it's perfectly obvious that the exponent has to bleed down one bit into the next lower hex digit. That's what I was seeing, but somehow in my haste, I didn't recognize it as such, and formed this "theory" that it was using a base-4 exponent.

Wanna hear the funny part? After tinkering with it for awhile, I worked out the rules for my imagined format, that worked just fine. At work, I've got a Mathcad file that takes the hex number, shifts it two bits at a time, diddles the "phantom" bit, and produces the right results. I can go from integer to float and back nicely, using this cockamamie scheme.

Needless to say, the conversion is a whole lot easier if one uses the real format! My Mathcad file just got a lot shorter.

Thanks again to everyone who responded, and my apologies for bothering y'all with this imaginary problem.


Reply to
Jack Crenshaw

Hehe. Nice to know one of my antennas is still sharp.

I think my first exposure to hidden-bit as a term dates to about

1974. But I could be off, by a year, either way.

Hehe. Now those terms aren't so "hidden" to me. I learned my early electronics on tube design manuals. One sticking point I remember bugging me for a long time was exactly, "How do they size those darned grid leak resistors?" I just couldn't figure out where they got the current from which to figure their magnitude. So even B+ is old hat to me.

Well, that's about the time for "hidden bit," too. Probably, at that time the term was still in a state of flux. I just got my hands on different docs, I imagine.

Oh, it's fine to me, anyway. I knew what was meant the moment I saw the term. It's pretty clear. I just think time has settled more on one term than another.

But to take your allusion and run with it a bit... I don't know of anyone part of some conspiracy to set the term -- in any case, setting terms usually is propagandistic, designed for setting agendas in peoples' minds and here is a case where everyone would want the same agenda.

Oh, geez. I've never known a geek to care about such things. I suppose they must exist, somwhere. I've just never met one willing to let me know they thought like that. But that's an interesting thought. It would fit the weird times in the US we live in, with about 30% aligning themselves as fundamentalists.

Nah... it just can't be.

I really think it was more the IEEE settling on a term. But then, this isn't my area so I could be dead wrong about that -- I'm only guessing.

Hehe. I've no problem if that's true.

No problem. It was really pretty easy to recall the details. Like learning to ride a bicycle, I suppose.

Oh, there was no question. I've a kindred interest in physics and engineering, I imagine. I'm currently struggling through Robert Gilmore's books, one on lie groups and algebras and the other on catastrophe theory for engineers as well as polytropes, packing spheres, and other delights. There were some nice insights in your book, which helped wind me on just enough of a different path to stretch me without losing me.

By the way!! I completely agree with you about MathCad! What a piece of *&!@&$^%$^ it is, now. I went through several iterations, loved at first the slant or approach in using it, but absolutely hate it now because, frankly, I can't run it for more than an hour before I don't have any memory left and it crashes out. Reboot time every hour is not my idea of a good thing. And that's only if I don't type and change things too fast. When I work quick on it, I can go through what's left with Win98 on a 256Mb RAM machine in a half hour! No help from them and two versions later I've simply stopped using it. I don't even want to hear from them, again. Hopefully, I'll be able to find an old version somewhere. For now, I'm doing without.

Yes. But that's fine, I suspect. I've taught undergrad classes and most folks just go "barf" when confronted with learning floating point. In class evaluations, I think having to learn floating point was the bigger source of complaints about the classes. You probably addressed everything anyone "normal" could reasonably care about and more.

No problem.

In any case, it's clear that your imagination is able to work overtime, here! Maybe that's a good thing.

Hmm. Then you should be able to construct a function to map between these, proving the consistent results. I've a hard time believing there is one. But who knows? Maybe this is the beginning of a new facet of mathematics, like the investigation into fractals or something!

Hehe!! When you get things right, they *do* tend to become a little more prosaic, too. Good thing for those of us with feeble minds, too.

hehe. Best of luck. In the process, I did notice that you are entertaining thoughts on a revised "Let's build a compiler." Best of luck on that and if you feel the desire for unloading some of the work, I might could help a little. I've written a toy C compiler before, an assembler, several linkers, and a not-so-toy BASIC interpreter. I can, at least, be a little bit dangerous. Might be able to shoulder something, if it helps.


Reply to
Jonathan Kirwan

Hi Jack!

I've always used the term "implied bit". I think I saw it in the 80186 programmer's reference section on using an 80187 coprocessor.

BTW: thanks for the articles (and the Math toolkit book) on interpolating functions - I use that stuff over and over again. In fact, I'm simulating an antilog interpolation routine (4 terms by 4 indicies) right now that will eventually run on a PIC (no hardware multiply; not even an add-with-carry instruction). Those foward and backward difference operators make it all pretty easy! With no hardware support from the PIC, it will end up taking near 10mS from 24 bit ADC to final LED output but it will be better than 14 bit accurate over the 23 bit output dynamic range.

all the best, Bob

Reply to

Yeah, sometimes the ones who have the most details about a subject sometimes fail to see the overall big picture (i.e. the old forest for the trees argument). I've sometimes had revelations about things when I go to teach someone something that I thought I already knew, but now I understand it better. :-)

Yousuf Khan

Reply to
Yousuf Khan

Teaching *is* one of the better ways to learn something.


Reply to
Jonathan Kirwan

I have never heard about phantom bits before, but the PDP-11 processor handbooks talked about hidden bit normalisation when talking about the floating point processor (FPP) instructions in the mid-70's. It might even be older, since the same format was used on the FIS instruction set extensions on some early PDP-11s.


Reply to
Paul Keinanen

I think I got the term "phantom bit" from Intel's f.p. library for the

8080, ca. 1975. Then again, I've been doing my own ASCII-binary and binary-ASCII conversions since way before that, on big IBM iron. We pretty much had to, since the old Fortran I/O routines were so incredibly confining. It had to be around 1960-62. But the old 7094 format didn't use the "phantom" bit, AIR.

You just haven't lived until you've twiddled F.P. bits in Fortran .

Sounds neat. I'm glad I could help.

FWIW, there's a fellow in my office who has a Friden calculator sitting on his credenza. He's restoring it.


Reply to
Jack Crenshaw

Then you definitely ain't one of the young punks, are you? Re grid leak: I think it must be pretty much trial and error. No doubt _SOMEONE_ has a theory for it, but I would think the grid current must vary a lot from tube to tube.

FWIW, I sit here surrounded by old Heathkit tube electronics. I collect them. Once I started buying them, I realized I couldn't just drive down to the local drugstore and test the tubes. Had to buy a tube tester, VTVM, and all the other accoutrements to be able to work on them.

I agree; I was mostly kidding about the PC aspects. One never knows, tho. FYI, I have been known to be called a "fundie" on and others of those insightful and respectful sites. I'm not, but they are not noted for their discernment or subtleties of observation.

One of my favorite atheists is Stan Kelly-Bootle of "Devil's DP Dictionary" fame. Among others of his many myriad talents, he's one of the world's leading experts on matters religious. He and I have had some most stimulating and rewarding discussions, on the rare occasions when we get together. The trick is a little thing called mutual respect. Most modern denizens of the 'net don't get the notion of respecting a person's opinion, even while disagreeing with it.

Glad to help.

Don't get me started on Mathcad!

As some old-time readers might know, I used to recommend Mathcad to everyone. In my conference papers, I'd say, "If you are doing engineering and don't have Mathcad, you're limiting your career." After Version 7 came out, I had to say, "Don't buy Mathcad at any price; it's broken." Here at home I've stuck at Version 6. Even 6 has its problems -- 5 was more stable -- but it's the oldest I could get (from RecycledSoftware, a great source). The main reason I talked my company into getting Matlab was as a refuge from Mathcad.

Having said that, truth in advertising also requires me to say that I use it almost every day. The reason is simple: It's the only game in town. It's the only Windows program that lets you write both math equations and text, lets you generate graphics, and also does symbolic algebra, in a WYSIWYG interface. Pity it's so unstable.

Come to that, my relationship with Mathcad is very consistent, and much the same as my relationship with Microsoft Office and Windows. I use it every day, and curse it every day. I've learned to save early and often. Even that doesn't always help, but it's the best policy. I had one case where saving broke the file, but the Mathcad support people (who can be really nice, sometimes) managed to restore it.

I stay in pretty constant contact with the Mathcad people. As near as I can tell, they are trying hard to get the thing under control. Their goal is to get the program to such a point that it's reasonable to use as an Enterprise-level utility, and a means of sharing data across organizations. I'm also on their power users' group, and theoretically supposed to be telling them where things aren't working.

Even so, when I report problems, which is often, the two most common responses I get are:

1) It's not a bug, it's a feature, and 2) Sorry, we can't reproduce that problem.

I think Mathsoft went through a period where all the original authors were replaced by maintenance programmers -- programmers with more confidence than ability. They seemingly had no qualms about changing things around and redefining user interfaces, with little regard for what they might break. Mathsoft is trying to turn things around now, but it's not going to be easy. IMO.

See RecycledSoftware as mentioned above. BTW, have you _TOLD_ Mathsoft how you feel? Sometimes I think I'm the only one complaining.

I'm using Version 11 with all the upgrades, and it's still thoroughly broken. Much less stable than versions 7, 8, etc.

F.P. is going to be in my next book. I have a format called "short float" which uses a 24-bit form factor; 16-bit mantissa. I first used it back in '76 for an embedded 8080 problem (Kalman filter on an 8080!). Used it again, 20 years later, on a '486. Needless to say, it's not very accurate, but 16 bits is about all we can get out of an A/D converter anyway, so it's reasonable for embedded use.

Grin! I don't know about that, but there is indeed a connection. I suppose that, with enough effort, I could work out a scheme for using base 16, and still get the same bit patterns. Epicycles upon epicycles, don'cha know.

Thanks for the offer. I'm thinking that perhaps an open-source sort of approach might be useful. Several people have offered to help. My intent is to use Delphi, and there are lots of folks out there who know it better than I. Of course, I'll still have to do the prose, but help with the software is always welcome.


Reply to
Jack Crenshaw

Or any other HLL, for that matter!

He has a sliderule for backup?

Speaking of hardware math mysteries, Dr. Crenshaw, et al, does anyone know how the (very few) computers that have the capability perform BCD multiply and divide? Surely there's a better way than repeated adding/subtracting n times per multiplier/divisor digit. Converting arbitrary precision BCD to binary, performing the operation, and then converting back to BCD wouldn't seem to be the way to go (in hardware).

Reply to
Everett M. Greene

Thanks for that. I think I still have a PDP-11 book or two around here... yes! There it is. 1976, PDP 11/70 Processor Handbook, and yes... they talk about the hidden bit.

Yup, I was working on PDP-11's (and PDP-8's as well) from about

1972, on. PDP-8's first, though. So I'm pretty sure that's where I got it and it probably *was* circa 1974, my guess.

Damn, my memory is good in spots!

Thanks, Jon

Reply to
Jonathan Kirwan

What is the problem ?

IIRC the IAND and IOR are standard functions in FORTRAN and in many implementations .AND. and .OR. operators between integers actually produced bitwise and and bitwise or results.

Doing bit manipulation in COBOL is a bit messy :-).

If you have a BCD hardware, why on earth should the values be converted to binary for multiply or divide ? Do it just as if you are doing it on paper. To make a BCD computer (or a 4 function calculator) you just need a BCD adder and some circuitry to make the 9's complement of a value. Some hardware doing BCD x BCD producing a two digit BCD value (or a table search) will speed up some operations quite a lot. Paul

Reply to
Paul Keinanen

Hmphh! In Fortran II, we were lucky to get add and subtract. No such thing as .AND. and .OR. there.


Reply to
Jack Crenshaw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.