How many bits internally on FPU? - SUN

This is a discussion on How many bits internally on FPU? - SUN ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: How many bits internally on FPU?

  1. How many bits internally on FPU?

    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.

    http://chessdb.sourceforge.net/ - a Free open-source Chess Database

  2. Re: How many bits internally on FPU?

    >>>>> "Dave" == Dave <(from the UK)" > 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


  3. Re: How many bits internally on FPU?

    Raymond Toy wrote:
    >>>>>>"Dave" == Dave <(from the UK)" > 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.

    http://chessdb.sourceforge.net/ - a Free open-source Chess Database

  4. Re: How many bits internally on FPU?

    On Sep 1, 5:13 am, "Dave (from the UK)" below.com> wrote:
    > Raymond Toy wrote:
    > >>>>>>"Dave" == Dave <(from the UK)" > 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."


  5. Re: How many bits internally on FPU?

    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.

    > 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!






  6. Re: How many bits internally on FPU?

    >>>>> "Dave" == Dave 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.

    Ray

  7. Re: How many bits internally on FPU?

    On Sep 6, 3:57 am, Dave 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!


    Have fun. The Arch manual I found here:
    http://www.sparc.com/standards/v9.ps.Z


  8. Re: How many bits internally on FPU?

    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)


    Intel chip gives -89.76 dBm (I don't know any more places). SPARC chip

    -89.7434558385774039

    Doing this in Mathematica, using 100 digits of working precision, I get:

    -89.74345583857740387143584746291068890792783429908 25094614875506378


    Writing all 3, one above the other:

    -89.74345583857740387143584746291068890792783429908 2 (Mathemaitca)
    -89.7434558385774039 (SPARC)
    -89.76 (Intel)

    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.

    http://chessdb.sourceforge.net/ - a Free open-source Chess Database

  9. Re: How many bits internally on FPU?

    In article <46e283f9@212.67.96.135>,
    Dave (from the UK) 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)
    >


    >-89.74345583857740387143584746291068890792783429908 2 (Mathemaitca)
    >-89.7434558385774039 (SPARC)
    >-89.76 (Intel)


    -89.743455839 HP 32S calculator

    So somebody at Intel screwed 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

+ Reply to Thread