FPU question

[RuiLoureiro]

Hello !
Do you know ?
FXTRACT (Extract exponent and significand)
exponent of what base ?  base 2 ?
significand is not the mantissa ?
Given a number X,  is it = to 2^(exponent+significand ) ?
Is this ? So log2(X)= exponent+significand.
No ? Could you help ?

[Gunther]

Hi RuiLoureiro,

here's a quote from the Intel Manual, Vol. 2A 3-355:

Separates the source value in the ST(0) register into its exponent and significand, stores the exponent in ST(0),
and pushes the significand onto the register stack. Following this operation, the new top-of-stack register ST(0)
contains the value of the original significand expressed as a floating-point value. The sign and significand of this
value are the same as those found in the source operand, and the exponent is 3FFFH (biased value for a true exponent
of zero). The ST(1) register contains the value of the original operand's true (unbiased) exponent expressed
as a floating-point value. (The operation performed by this instruction is a superset of the IEEE-recommended
logb(x) function.)
This instruction and the F2XM1 instruction are useful for performing power and range scaling operations. The
FXTRACT instruction is also useful for converting numbers in double extended-precision floating-point format to
decimal representations (e.g., for printing or displaying).
If the floating-point zero-divide exception (#Z) is masked and the source operand is zero, an exponent value of –
∞ is stored in register ST(1) and 0 with the sign of the source operand is stored in register ST(0).
This instruction's operation is the same in non-64-bit modes and 64-bit mode.

Hope that helps.

Gunther

[dedndave]

yes - one part will be the exponent of st(0), with the bias removed
the other part will be the significand (same as mantissa) of st(0) with a biased exponent of 0

st(0) becomes st(1) and the old value is overwritten by the exponent
the new st(0) will have the significand

Given a number X,  is it = to 2^(exponent+significand ) ?

no - the value is (-1)^s * 2^e * m
s = sign bit
e = exponent with bias removed
m = mantissa (1.xxxxxxx.....)

to evaluate denormals, add 1 to the exponent, mantissa = 0.xxxxxxx.....
(denormals are stored with exponent = 0, the actual biased exponent is 1)

[dedndave]

here is a great guide
although, it also covers SPARC stuff, which does not apply to intel FPU's (ignore that part)

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_preface.html

chapter 2 is what you want   :t

[jj2007]

chapter 2 is what you want   :t

And again, they talk about 18-21 digits for REAL10 ::)
I'd really like to see an example where a non-bignum algo can display PI with more than 19 digits...

[dedndave]

the extra digits may not match the actual value of PI

what they are saying is, if i start with a real10 value
then convert it to an ascii decimal string
then convert it back to a real10
it will be the same as the original real10

understandable that it may take a couple extra digits to reduce the round-off errors enough to duplicate the original

[Gunther]

Hi Jochen,

I'd really like to see an example where a non-bignum algo can display PI with more than 19 digits...

I think that this is impossible with REAL10.

Gunther

[dedndave]

Code Select Expand

4000_C90FDAA2_2168C234: +3.141592653589793238295968524909085317631252110004425048828125

4000_C90FDAA2_2168C235: +3.14159265358979323851280895940618620443274267017841339111328125

4000_C90FDAA2_2168C236: +3.1415926535897932387296493939032870912342332303524017333984375



http://141592653589793238462643383279502884197169399375105820974944592.com/

[Gunther]

Hi Dave,

Code Select Expand

4000_C90FDAA2_2168C234: +3.141592653589793238295968524909085317631252110004425048828125

4000_C90FDAA2_2168C235: +3.14159265358979323851280895940618620443274267017841339111328125

4000_C90FDAA2_2168C236: +3.1415926535897932387296493939032870912342332303524017333984375



http://141592653589793238462643383279502884197169399375105820974944592.com/

and you're sure that this are REAL10 values? I think that's a special long number library.

Gunther 

[MichaelW]

The hex numbers look like the representable values in the vicinity of Pi, but I'm not sure how the digit strings were derived.

Code Select Expand


;==============================================================================
    include \masm32\include\masm32rt.inc
;==============================================================================
    .data
        r10 LABEL REAL10
        dd0 dd 0
        dd1 dd 0
        dd2 dd 0
    .code
;==============================================================================
start:
;==============================================================================
    fldpi
    fstp r10
    printf("%X_%X_%X\n\n", dd2, dd1, dd0)
    inkey
    exit
;==============================================================================
END start


Code Select Expand


4000_C90FDAA2_2168C235


[RuiLoureiro]

chapter 2 is what you want   :t

And again, they talk about 18-21 digits for REAL10 ::)
I'd really like to see an example where a non-bignum algo can display PI with more than 19 digits...

well Jochen, invent an algo, it gives the same noone
                read it after the 3/4  first digits !

Thanks Gunther, and Dave for your answers  :t

[jj2007]

Actually, the three values Dave posted do give different values. Look at ...9323829. It seems there is a 2, 4, 6, 8 sequence of the digit following 3238. The question is how to translate that into a printable qword...

[dedndave]

Jochen already knows this, as we used this program to evaluate some real10's, long ago
it was our favorite argument discussion   :lol:

http://www.masmforum.com/board/index.php?topic=11781.msg89774#msg89774

the eval program works like this:
create a large buffer (~21 kb)
convert the 64-bit significand to a decimal string
divide or multiply the decimal string by 2 repeatedly to adjust for the exponent

Code Select Expand

Ebuff   db 4916 dup(?)   ;allow shift-left digits
AscBuf  db 20 dup(?)     ;the original 64-bit decimal string
ebuff   db 16452 dup(?)  ;allow shift-right digits

notice that, for real10's, the bias is 3FFFh (16383)
also notice that the "one's" bit is the high-order bit of the significand
so, we adjust the exponent bias by 63 to make the low order bit the "one's" bit
that gives you a "fraction-adjusted" bias of 403Eh (16446)
so, subtract 403Eh from the exponent
if the result is positive, you multiply (shift left) by 2^(exponent-403Eh)
if the original exponent is 403Eh, you don't have to shift at all - the 64-bit decimal digits are the value of the real
if the result of subtraction is negative, you divide (shift right) by 2^(403Eh-exponent)
when you are all done, you have to put a sign and decimal point in there and "e+/-xxxx" at the end   :P
(my original program didn't use scientific notation, just a bunch of 0's - lol)

this is how you might evaluate a floating point value, if you had to do it "by hand", with a calculator
the result is - it evaluates the real to full precision, even though many of the digits are meaningless

i am working on a new version that i will post, soon   :t