I know the Intel floating point units (8087, 80287, 80387, 486 etc) all
use 80 bits internally which gives about 19 significant digits. When
writing to RAM only 64 bits (8 bytes) are used.
Does a SPARC FPU use more than 64 bits interally? I'm particulary
interstined in the UltraSPARC II CPUs in my Ultra 80.
--
Dave (from the UK)
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@althorne.org
Hitting reply will work for a few months only - later set it manually.
>>>>> "Dave" == Dave <(from the UK)" <see-my-signature@see-below.com>> writes:
Dave> I know the Intel floating point units (8087, 80287, 80387,
Dave> 486 etc) all use 80 bits internally which gives about 19
Dave> significant digits. When writing to RAM only 64 bits (8
Dave> bytes) are used.
Dave> Does a SPARC FPU use more than 64 bits interally? I'm
Dave> particulary interstined in the UltraSPARC II CPUs in my
Dave> Ultra 80.
I'm pretty sure there are only 64 bits. There might be more, but I
know of know way to access them.
Raymond Toy wrote:
>>>>>>"Dave" == Dave <(from the UK)" <see-my-signature@see-below.com>> writes:
>
>
> Dave> I know the Intel floating point units (8087, 80287, 80387,
> Dave> 486 etc) all use 80 bits internally which gives about 19
> Dave> significant digits. When writing to RAM only 64 bits (8
> Dave> bytes) are used.
>
> Dave> Does a SPARC FPU use more than 64 bits interally? I'm
> Dave> particulary interstined in the UltraSPARC II CPUs in my
> Dave> Ultra 80.
>
> I'm pretty sure there are only 64 bits. There might be more, but I
> know of know way to access them.
>
> Ray
>
IIRC I did find a way on the Intel CPU of getting all 80 bits, in
assembly code. But it must be 15+ years since I wrote any assembly code.
But I was more interested in not whether one can get them or not, but
whether they are used internally.
--
Dave (from the UK)
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@althorne.org
Hitting reply will work for a few months only - later set it manually.
On Sep 1, 5:13 am, "Dave (from the UK)" <see-my-signat...@see-
below.com> wrote:
> Raymond Toy wrote:
> >>>>>>"Dave" == Dave <(from the UK)" <see-my-signat...@see-below.com>> writes:
> > Dave> I know the Intel floating point units (8087, 80287, 80387,
> > Dave> 486 etc) all use 80 bits internally which gives about 19
> > Dave> significant digits. When writing to RAM only 64 bits (8
> > Dave> bytes) are used.
> > Dave> Does a SPARC FPU use more than 64 bits interally? I'm
> > Dave> particulary interstined in the UltraSPARC II CPUs in my
> > Dave> Ultra 80.
> > I'm pretty sure there are only 64 bits. There might be more, but I
> > know of know way to access them.
> IIRC I did find a way on the Intel CPU of getting all 80 bits, in
> assembly code. But it must be 15+ years since I wrote any assembly code.
I recall the same thing but that book mouders away in the basement so
I cannot
say for sure, but popping 80 bit results results off the FPU stack
auto populated the
target memory area...?
> But I was more interested in not whether one can get them or not, but
> whether they are used internally.
What do you mean by internally?
Anything could be thought of as internal... ; >
A quote from the The SPARC Architecture Manual Version 9
"The store quad floating-point instruction (STQF) copies the contents
of a quad floatingpoint
register into a word-aligned quadword in memory."
and :
"3.1.2 Floating-Point Unit (FPU)
The FPU has 32 32-bit (single-precision) floating-point registers, 32
64-bit (double-precision)
floating-point registers, and 16 128-bit (quad-precision) floating-
point registers,
some of which overlap."
>> IIRC I did find a way on the Intel CPU of getting all 80 bits, in
>> assembly code. But it must be 15+ years since I wrote any assembly code.
>
> I recall the same thing but that book mouders away in the basement so
> I cannot
Same with me I suspect.
> say for sure, but popping 80 bit results results off the FPU stack
> auto populated the
> target memory area...?
>
>> But I was more interested in not whether one can get them or not, but
>> whether they are used internally.
>
> What do you mean by internally?
> Anything could be thought of as internal... ; >
I was thinking along the lines of that the actual computations might use
>64 bits, so that the all 64 bits were most likely to be correct, and
so the last few not inaccurate due to rounding errors.
>
> A quote from the The SPARC Architecture Manual Version 9
>
> "The store quad floating-point instruction (STQF) copies the contents
> of a quad floatingpoint
> register into a word-aligned quadword in memory."
> and :
> "3.1.2 Floating-Point Unit (FPU)
> The FPU has 32 32-bit (single-precision) floating-point registers, 32
> 64-bit (double-precision)
> floating-point registers, and 16 128-bit (quad-precision) floating-
> point registers,
> some of which overlap."
Interesting about the 128 bit ones. That suggest that perhaps the
internal computations are done with more than 64-bits. Although perhaps
it means you can read a 128-bit register which simply has the data from
two 64-bit registers, which contain totally unrelated numbers.
I guess from a practical point of view it does not make too much
difference to me. I'm surprised someone else's C code averages 3 numbers
with 4 digits (two before the decimal point and two after) and gets a
value which differs from that on my Sun by 0.02. (It's slightly more
complex than simple averaging as the numbers known are the logs of the
numbers that need averaging, so an anitlog has to be performed first).
Perhaps we have discovered another bug in the FPU of an Intel CPU! What
did the one on the early Pentium cost Intel? I will investigate this a
bit more I think!
>>>>> "Dave" == Dave <someplace@nowhere-nice.com> writes:
Dave> gerryt wrote:
>>> IIRC I did find a way on the Intel CPU of getting all 80 bits, in
>>> assembly code. But it must be 15+ years since I wrote any assembly code.
>> I recall the same thing but that book mouders away in the basement so
>> I cannot
Dave> Same with me I suspect.
There is an instruction to save all 80 bits to memory. (And load it
from memory too.)
>> say for sure, but popping 80 bit results results off the FPU stack
>> auto populated the
>> target memory area...?
>>
>>> But I was more interested in not whether one can get them or not, but
>>> whether they are used internally.
>> What do you mean by internally?
>> Anything could be thought of as internal... ; >
Dave> I was thinking along the lines of that the actual
Dave> computations might use 64 bits, so that the all 64 bits were
Dave> most likely to be correct, and so the last few not
Dave> inaccurate due to rounding errors.
I'm pretty sure all 64 bits are correctly rounded. I don't know how
many extra bits are needed to make sure all operations are correctly
rounded. I think you need at least a sticky bit to indicate something
about all the bits that were thrown away when rounding.
Dave> Interesting about the 128 bit ones. That suggest that perhaps the
Dave> internal computations are done with more than 64-bits. Although
Dave> perhaps it means you can read a 128-bit register which simply has the
Dave> data from two 64-bit registers, which contain totally unrelated
Dave> numbers.
AFAIK, no Ultrasparc actually implements the 128-bit floats in
hardware. Everything is emulated via kernel traps. In fact, I
vaguely recall some note saying that the quad-float instructions
should probably not be used, and the quad-float subroutines should be
used instead, because of the kernel trap overhead.
I think Fujitsu's Sparc chip might implement 128-bit floats, but I'm
not sure.
Dave> I guess from a practical point of view it does not make too much
Dave> difference to me. I'm surprised someone else's C code averages 3
Dave> numbers with 4 digits (two before the decimal point and two after) and
Dave> gets a value which differs from that on my Sun by 0.02. (It's slightly
Dave> more complex than simple averaging as the numbers known are the logs
Dave> of the numbers that need averaging, so an anitlog has to be performed
Dave> first).
But this could be due to all kinds of things. Computations being done
in a different order, the Intel chip using all 80-bits whereas a Sparc
only has 64, or special functions aren't implemented with the same
accuracy, etc., etc.
On Sep 6, 3:57 am, Dave <somepl...@nowhere-nice.com> wrote:
> gerryt wrote:
> >> IIRC I did find a way on the Intel CPU of getting all 80 bits, in
> >> assembly code. But it must be 15+ years since I wrote any assembly code.
> > I recall the same thing but that book mouders away in the basement so
> > I cannot
> Same with me I suspect.
Mouldering away in a basement??!
Never mind : >
> > say for sure, but popping 80 bit results results off the FPU stack
> > auto populated the
> > target memory area...?
> >> But I was more interested in not whether one can get them or not, but
> >> whether they are used internally.
> > What do you mean by internally?
> > Anything could be thought of as internal... ; >
> I was thinking along the lines of that the actual computations might use
> >64 bits, so that the all 64 bits were most likely to be correct, and
> so the last few not inaccurate due to rounding errors.
Havent seen the die or the tapes but I would hope that a few gates
switched on or off would do the calcs in hardware, end up in the stack
where you then you pop the results off into memory woth a STQF.
> > A quote from the The SPARC Architecture Manual Version 9
> > "The store quad floating-point instruction (STQF) copies the contents
> > of a quad floatingpoint
> > register into a word-aligned quadword in memory."
> > and :
> > "3.1.2 Floating-Point Unit (FPU)
> > The FPU has 32 32-bit (single-precision) floating-point registers, 32
> > 64-bit (double-precision)
> > floating-point registers, and 16 128-bit (quad-precision) floating-
> > point registers,
> > some of which overlap."
>
> Interesting about the 128 bit ones. That suggest that perhaps the
> internal computations are done with more than 64-bits. Although perhaps
> it means you can read a 128-bit register which simply has the data from
> two 64-bit registers, which contain totally unrelated numbers.
Possibly but why offer fake goods..
> I guess from a practical point of view it does not make too much
> difference to me. I'm surprised someone else's C code averages 3 numbers
> with 4 digits (two before the decimal point and two after) and gets a
> value which differs from that on my Sun by 0.02. (It's slightly more
> complex than simple averaging as the numbers known are the logs of the
> numbers that need averaging, so an anitlog has to be performed first).
>
> Perhaps we have discovered another bug in the FPU of an Intel CPU! What
> did the one on the early Pentium cost Intel? I will investigate this a
> bit more I think!
> Dave> I guess from a practical point of view it does not make too much
> Dave> difference to me. I'm surprised someone else's C code averages 3
> Dave> numbers with 4 digits (two before the decimal point and two after) and
> Dave> gets a value which differs from that on my Sun by 0.02. (It's slightly
> Dave> more complex than simple averaging as the numbers known are the logs
> Dave> of the numbers that need averaging, so an anitlog has to be performed
> Dave> first).
>
> But this could be due to all kinds of things. Computations being done
> in a different order, the Intel chip using all 80-bits whereas a Sparc
> only has 64, or special functions aren't implemented with the same
> accuracy, etc., etc.
>
> Ray
The Sun result is the more accurate of the two, which is stange, given
it is probably using less bits (64 vs 80 on an intel chip).
I'm using gcc on a Sun. Someone else is using gcc inside Cywin on a
Windows box.
--
Dave (from the UK)
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@althorne.org
Hitting reply will work for a few months only - later set it manually.
In article <46e283f9@212.67.96.135>,
Dave (from the UK) <feb-2007@althorne.org> wrote:
>Raymond Toy (RT/EUS) wrote:
>
>> Dave> I guess from a practical point of view it does not make too much
>> Dave> difference to me. I'm surprised someone else's C code averages 3
>> Dave> numbers with 4 digits (two before the decimal point and two
>after) and
>> Dave> gets a value which differs from that on my Sun by 0.02.
>(It's slightly
>> Dave> more complex than simple averaging as the numbers known are the logs
>> Dave> of the numbers that need averaging, so an anitlog has to be
>performed
>> Dave> first).
>>
>> But this could be due to all kinds of things. Computations being done
>> in a different order, the Intel chip using all 80-bits whereas a Sparc
>> only has 64, or special functions aren't implemented with the same
>> accuracy, etc., etc.
>>
>> Ray
>
>The Sun result is the more accurate of the two, which is stange, given
>it is probably using less bits (64 vs 80 on an intel chip).
>
>These are 3 the numbers:
>
>-90.55 , -90.06 6 and -88.81
>
>These are power levels in something callled dBm.
>
>http://en.wikipedia.org/wiki/DBm
>
>
>I need to find the average of these 3 power levels, but because they are
>logs of powers, I need to use this method. Assume they are d1, d2 and d3
>
>d1 = -90.55
>d2 = -90.06
>b3 = -88.81
>
>p1=10^(d1/10)
>p2=10^(d2/10)
>p3=10^(d3/10)
>
>mean power = pm = (p1+p2+p3)/3
>
>mean power in dBm= 10*log10(pm)
>
So somebody at Intel ******* up. What else is new?
Or the C math library functions are not the same in both cases (Sun and Intel).
Or the two versions of the program are not identical.
You could run some test cases on both systems, around the values from
-89.0 to -91.0 to see how close the computed 10*log10(10^(x/10))
is to the input value of x.
Also look for possible discrepancies in the value of "10", single- or double-
precision. See if division by 10 is written as multiplication by 0.1.
carl
--
carl lowenstein marine physical lab, u.c. san diego clowenstein@ucsd.edu
How many bits internally on FPU? 
Linear Mode
