No announcement yet.

Extended Precision - Problems PB + ASM

  • Filter
  • Time
  • Show
Clear All
new posts

  • Extended Precision - Problems PB + ASM

    I would need real Extended precision for my application - some parts
    will also be in assembler for speed.
    Unfortunately and despite searching the forums and having seen the messages
    to 'correct' it, I just can't get it working.
    I post here below working code to highlight and visualise the problem:

    'Extended precision problems...
    #REGISTER NONE 'needed as per PB Forum 6-413 or 4-1471
    xyz% = 0
    ! fstcw xyz%
    ! or xyz%, &B0000001100000000%
    ! fldcw xyz%

    Fs! = 28 / 9 'single precision
    Pi# = ATN(1) * 4 'double
    Pie## = ATN(1) * 4 'extended precision expected... but only double - possibly due to ATN use?
    Fl## = 28/9 : F## = 28/9 'this is still double, not EXT ! Why ???
    ' ! fld F## ;load in ST(0) => FATAL ERROR !!! - can't load EXT ???
    'instruction should be OK to load EXT according to Intel?
    ! fldPi ;push internal constant Pi onto FPU register stack = ST(0)
    '? gives always DOUBLE (rounded 66 bit? according to Intel) instead of EXT
    ! fst Pid# ;copy ST(0) to Pid# (double precision)
    ! fstp F## ;copy ST(0) to F## (in EXT?) and pop register stack

    MSGBOX STR$(Pi#) + CHR$(13) + STR$(Pie##) + CHR$(13) + STR$(Fl##) + CHR$(13) + _
    STR$(Pid#) + CHR$(13) + STR$(F##) + CHR$(13) + STR$(Fs!) 'how can I get Pi in EXT ???
    'F## isn't changed by trying to load Pi in extended precision in F##


    The comments and questions in the code and the result (msgbox) should speak for themselves.
    I would appreciate if anybody can show me how to get at least the PB code working and the
    EXT ASM would be nice to.

    [email protected]


  • #2
    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?

    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.

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


    • #3

      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.





      • #4
        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?

        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



        • #5
          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.

          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.





          • #6

            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.






            • #7
              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)
              #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?

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


              • #8
                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.




                • #9
                  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)
                  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)
                  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)
                  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

                  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)

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

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

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



                  [This message has been edited by Vladimir Shulakov (edited January 03, 2001).]
                  Spherical Panorama Inc. Virtual Reality for: Real Estate, Tourism Advertisment.


                  • #10
                    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.



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

                      E-MAIL: [email protected]


                      • #12
                        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 .

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

                        Only experiments will give you a correct way


                        Spherical Panorama Inc. Virtual Reality for: Real Estate, Tourism Advertisment.


                        • #13

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




                          • #14
                            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).

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