JC> CB> (I should point out that the 64 bit integers in the FPU are really
JC> CB> only partially implemented.  All you can do is load and store them.
JC> CB> All the integer FPU operations work on 16 or 32 bit integers.)
JC>I'm a left confused by this comment.  My understanding has always been
JC>that the FPU does _all_ internal work with 80 bit extended reals.  I.e.
JC>anytime it works with any other format, it converts the other format to
JC>an 80 bit real upon loading, does all work on the 80 bit extended real,
JC>then stores results in whatever format you prefer.
It's a little hard to explain exactly what the FPU does internally,
since I don't have access to the design specs.
But we can talk about what it _apears_ to do.  Which is all that counts
from a programmers point of view.
Now, the x87 FPU may load the integers and put them on the 80 bit stack,
but it also has to bypass a few floating point things.  Things like not
automatically normalizing them, no checking for invalid floating point
results, no checking for over/under flows, etc.  (Obviously, you can't
guarantee loading, say a 10 byte long double, and then store it and
expect to get the exact same bit sequence.  Not bit combinations are
valid floating point numbers and might cause errors, plus the FPU might
decide to normalize the answer or something.  I'm sure you already know
that, but I'm saying it in case anybody else is reading.)
That's why there are specific instructions to load & store integers,
plus additional instructions to do things like division, comparisons.,
addition, etc.
All those places where doing normal FPU things would destroy an integer.
Doing things like rounding, normalization, extending division into
fractional bits that have no meaning for an integer, over / under flow,
and so on.
So, the x87 does keep the integers on the same 80 bit stack, (and in
fact, you can mix integer & float operations, provided you know what
you to expect, and of course, you can always just load an integer and
go about your normal business) but if you want it to behave like an
integer, it has to operate on them a bit differently so it doesn't
destroy the number _being_ an integer.
And it's not totally implemented, because, for example, you can't do a
64 bit integer division (FIDIV) and get an integer answer.  You can do
it with a 32 bit integer, but not a 64.  You'd have to do a floating
point one, and live with the fractional bits, or chop them off.  And
then when you are done, of course use FIST to store the integer.
JC>There _are_ bits in the FPU control word that govern the precision to
JC>which the FPU carries out results, but my understanding is that even if
JC>you only compute to, say, 32 bit precision, the result is stored
JC>internally as an 80 bit real anyway.  The control bits only allow you to
JC>set 32, 64 and 80 bit precision - it's two bits, but the fourth
MMMmmmm... That's questionable.  I've never tested something like that,
so I don't really know.  However, even if you did test, the results
would only be valid for that particular FPU.  As long as the operations
meet IEEE 754 floating point number specs (I would _love_ to get hold a
copy of that spec), it doesn't really matter how it works internally.
And the specs say that a float precision only has to be accurate to the
precision of a float (duh), which means that if the FPU did do more
precision, it would be wasted because they couldn't use it, not even for
rounding etc.
(Of course, much of the operations are done in parallel hardware, so
there isn't really any 'waste' to it.  For trig, division, etc. there
would be waste, though.  Although, since there are no standards for
trig, they don't have to meet accuracy results, so they could do what
ever they want.)
So, to give a simple answer to the original question: Although the
numbers the selves are stored on the x87's 80 bit FPU stack, it has to
be loaded, stored, and operated on with special integer operations so
the FPU doesn't destroy the integer nature of the number.
--- QScan/PCB v1.19b / 01-0162
---------------