Announcement

**Lance Edmonds** · 2 Jan 2001, 05:58 PM

i'm not at my dev pc to try your code, but have you enabled 80-bit precision as per the note in the faq forum?

http://www.powerbasic.com/support/pb...hread.php?t=45

a design "quirk" (feature/bug/whatever) in windows means that the fpu is set for 54-bit precision by default, and this affects extended maths precision results.

------------------
lance
powerbasic support
mailto:[email protected][email protected]</a>

**Bernard Chapman** · 2 Jan 2001, 09:22 PM

Lance,

In that link you state that both extended precision (floating point) and quad (integer) variables are affected and limited to 54 bits of precision.

I am currently (previously in blissful ignorance) using a quad integer (only one) as a mask that seems to be successfully giving me at least 18 digits of precision rather than the 16 digits that would be applicable with 54-bits ie 2^53.

Does this limitation really apply to quad integers or is my setup possibly quirky and achieves it without the enabling code.

If so it will probably fail for many of my clients.

FYI I am using Win98SE on a 650MHz PIII laptop and two desktops running Win98FE.

Regards,

Bern

------------------
Bern

www.insighttrading.com.au

**Jules Verschueren** · 3 Jan 2001, 12:31 AM

Lance,
As I formulated in my original message, I read and 'implemented' the FAQ.
That code is at the beginning of my example program, but clearly doesn't help for me?

Bern,
I had to use the Quad as well very recently and for me that also worked without problem
up to at least 18 digits precision. I did however encounter a problem with STR$ (even
when used as STR$(var,18) and will post that separately later.

So, there is a clear different behaviour for EXT and QUAD on my Athlon processor under W98 SE.

As before, a solution to use EXT (also in ASM) would very much be appreciated.
Thanks, Jules

------------------

**Bernard Chapman** · 3 Jan 2001, 02:17 AM

Some more experimentation has revealed that in my major app for some reason quad integers are working fine in 64 bit precision but if I make a very small test app of just a few lines they operate with the reduced precision.

In some of my smaller utility apps the precision is also stuck at 54-bit.

In all code utilising 64-bit precision I now call the following sub designed according to the above link and in all cases it has sucessfully enabled 64-bit precision.

Code:

SUB enable64bitprecision
LOCAL xyz AS INTEGER

#REGISTER NONE

xyz% = 0
ASM fstcw xyz%
ASM OR    xyz%, &B0000001100000000%
ASM fldcw xyz%

END SUB

Thanks a lot for the tip as it probably explains some strange behaviour observed by a few clients. I will test it out in the coming weeks to see if their problems are fixed.

Regards,

------------------
Bern

www.insighttrading.com.au

**Bernard Chapman** · 3 Jan 2001, 02:27 AM

Jules,

I have also used STR$(var,18) and seems to work OK for me for displaying quad integers except of course that they have 19 digits of precision.

I will be interested to see your post on this aspect.

Regards,

------------------
Bern

www.insighttrading.com.au

**Lance Edmonds** · 3 Jan 2001, 02:52 AM

Bern, I'm afraid I'm not able to answer your first question as you appear to be asking questions about the design of the floating point processor, and quirks of Windows, neither of which we have any control or complete documentation on.

As noted in the FAQ, the "problem" is not documented by Microsoft, yet was created by their hand.

It seems possible that PowerBASIC or a sub/function called by your code could be switching the FPU to 80-bit precision, hence the results you note in your second message.

Jules, now I've had a few minutes to study your code, I see that you did include the FPU 80-bit code. The first part of your question about Double Vs Ext results of 28/9 is because you did not type-cast the numeric literals, and therefore the results were of a lower precision than you expected. Try this code to see the difference in the last couple of decimal places (note that STR$() can display a maximum of 18 decimal places only)

Code:

#compile EXE
function pbmain
    #REGISTER NONE
    dim xyz%, a#, b##
    
    xyz% = 0
    ! fstcw xyz%
    ! or xyz%, &B0000001100000000%
    ! fldcw xyz%
  
    a# = 28/9
    b## = 28[b]##[/b]/9[b]##[/b]
    msgbox str$(a#,18) + $CR + str$(b##,18)
end function

Unfortunately I'm not an assembler guru, so I'm not able to provide an answer as to why the assembly code is failing to allocate the result to the extended-precision variable. I'll ask R&D about it and see what they say. Maybe one of the assembler guru's here can throw some light on this in the mean time too?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Jules Verschueren** · 3 Jan 2001, 09:16 AM

Thanks so much Lance,

Its the STR$ limitations that tricked me once more with regard to the
PB EXTended precision and even the ATN(1)*4 is able to return an extended Pi.
The type-casting of numerical literals didn't make any difference and
obviously that was just an example as in an application this would mostly be
a calculation of other variables and not a numerical literal assignment.

Now its just waiting for a guru assembler person to help me out showing how to
load and work with extended precision variables and calculations in ASM???
Many thanks in advance.

Jules

------------------

**Vladimir Shulakov** · 3 Jan 2001, 09:56 PM

Jules,
Some Information:

The 80x87 FPU supports a littel data types:

Type Description
Single 32-bit single-precision FP format
sign bit 31
exponent bits 30..23 8-bit excess-127 format (bias=07Fh)
signi-
ficand bits 22..0 24-bit one's complement format
(24th bit implied)
digits 7 to 8
range approx. 1.18*(10**-38) to 3.40*(10**+38)
(this data type is sometimes called 'short real')

Double 64-bit double-precision FP format
sign bit 63
exponent bits 62..52 11-bit excess-1023 (bias=3FFh)
signi-
ficand bits 51..0 53-bit one's complement format
(53rd bit implied)
digits 15 to 16
range approx. 2.23*(10**-308) to 1.79*(10**+308)
(this data type is sometimes called 'long real')

Extended 80-bit extended-precision FP format
sign bit 79
exponent bits 78..64 15-bit excess-16383 (bias=3FFFh)
signi-
ficand bits 63..0 64-bit one's complement format
(no implied bit)
digits 19 to 20
range approx. 3.37*(10**-4932) to 1.18*(10**+4932)
(this data type is sometimes called 'temporary real')

Packed 80-bit signed packed decimal integer
decimal sign bit 79
ignored by FPU bits 78..72
18 BCD digits bits 71..0
range -999,999,999,999,999,999 to
+999,999,999,999,999,999

Word 16-bit two's complement integer
integer range -32,768 to 32,767

Short 32-bit two's complement integer
integer range -2,147,483,648 to +2,147,483,647

Long 64-bit two's complement integer
integer range approx. -9.22*(10**18) to +9.22*(10**18)

Note:
===>With the exception of the 80-bit extended-precision format, all
===>these data types exist in memory only. When they are loaded into
===>FPU data registers they are automatically converted to extended-
===>precision format and operated on in that format. When stored
===>from an FPU data register into memory they are automatically
===>converted to the format of the destination.

Note:
--->For the single-real and double-real formats, only the fraction
--->part of the significand is encoded. The integer is assumed to be
--->one for all numbers except zero and denormalized finite numbers.
--->For the extended-real format, the integer is contained in bit
--->63, and the most-significant fraction bit is bit 62. Here, the
--->integer is explicitly set to one for normalized numbers,
--->infinities, and NaNs, and to zero for zero and denormalized
--->numbers.

---------------------------------------------------------------
You can independently find the decision of the problem.
FPU has some cunnings

V.Shulakov

------------------

[This message has been edited by Vladimir Shulakov (edited January 03, 2001).]

**Jules Verschueren** · 4 Jan 2001, 05:23 AM

Thanks Vladimir,

This info is certainly of good use but doesn't directly help me to do my
calculations in EXT in ASM.
My problem starts with the fact that I get a FATAL ERROR when I try to load
an extended precision variable to the FPU stack, eg. using "! fld F##".

I would be very grateful if you could show me how to:
1. load EXT variables onto the FPU stack?
2. can you load constants (other than the internal ones like fld1) to the stack?
3. in my original example code, would it be possible to load Pi (loaded in ST(0)
by "! fldPi") into an extended memory variable (eg. F##)?
According to Intel these internal constants are in extended format but I do not
understand why I can only get the result in a double format variable
and actually an error when trying to store in an extended variable?

I understand that the further calculations would automatically be
in extended format?

Again, many thanks for your help.
Jules

------------------

**Semen Matusovski** · 4 Jan 2001, 06:09 AM

Probably, I lost something, but compiler simply generates wrong code.

------------------
E-MAIL: [email protected]

**Vladimir Shulakov** · 4 Jan 2001, 06:36 AM

Jules ,
I guess, that this your problem is connected to
a make the graphics...(fast speed)

PB inline ASM (FPU,MMX) - has some special features of use !!!
PB inline ASM - NOT SUPPORTS ALL ASM "NEW" INSTRUCTIONS...
Only PB R&D own PB-ASM completely features.

You can look my some FPU code in source forums.
Maybe you find the decision of a your FPU problem in this examples.

I use for similar tasks - DOUBLE (Double precision) 64 bits (8 bytes)
Usually it's Enough .

Note:
Some my testing Has shown - that
Sometimes PB-FPU-ASM is Slower than PB-FUNCTION.

Only experiments will give you a correct way

V.Shulakov

------------------

**Jules Verschueren** · 4 Jan 2001, 10:21 AM

Vladimir,

You're right, I need to create some deep zoom fractals and thats why
double precision just isn't enough... I previously had checked your ASM codes
and use some of that.

I did some further experiments and apparently from the real vars only DOUBLEs
can be loaded onto the stack, and I guess stored back as well. This is not in agreement
with the PB Help which says that "32-bit floating point opcodes" are supported: they
actually are not, but the 64-bits (double real) are.

Is there anywhere a list of the actual PB supported ASM upcodes available??
PB R&D, can you help here? Certainly for a beginner, it takes a long time to try to
find out what is and isn't supported and I often don't know if the problem is me or PB?

Anyway, this is one more request to PB R&D to get more extensive support for ASM
in the next PBDLL release...

Regards,
Jules

------------------

**Lance Edmonds** · 4 Jan 2001, 04:23 PM

Ok, I've just heard back from R&D and they confirm that the compiler is encoding the FSTP mnemonic wrongly, hence your problem. You found a wee bug! Thanks! (this will definitely be fixed in the next update to the compiler).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Announcement

Extended Precision - Problems PB + ASM

Extended Precision - Problems PB + ASM

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment