Announcement

Collapse
No announcement yet.

Can I cast a larger HEX$, grin?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Can I cast a larger HEX$, grin?

    In PB 3.5, the following code returns an (expected!) overflow when
    we hit quad integer sizes. But I need hex string functions for them
    anyway. Now what can I do to cast a larger hex$, grin?

    Code:
    CLS
    PRINT
    PRINT "TESTING "; 9999999991
    QMZ& = 999999999
    QMY&& = 9999999991
    PRINT "QMZ& = ";  QMZ&
    PRINT "QMY&& = "; QMY&&
    PRINT "HEX$ QMZ& = "; HEX$(QMZ&)
    PRINT "HEX$ -QMZ& = "; HEX$(-QMZ&)
    PRINT "HEX$ QMY&& = "; HEX$(QMY&&)  '  oops! 
    PRINT "HEX$ -QMY&& = "; HEX$(-QMY&&) ' natch!
    PRINT
    Will someone teach me how to become an even better PowerBasic warlock!




    ------------------
    Mike Luther
    [email protected]

    [This message has been edited by Mike Luther (edited March 04, 2005).]
    Mike Luther
    [email protected]

  • #2
    not directly but you might consider converting the number(s) to
    binary then chopping the binary string to hex$ equivelents.

    there is a binari$ function in
    http://www.powerbasic.com/support/pb...ad.php?t=24418

    that will build a string length of 32k (if you can representate
    a number that big) that maybe of assistance.

    remember, if you go this route, you will give up pb's built in
    functions and your program will probably run slower.


    ------------------
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      Maybe write your own function?

      Hints: MyValue MOD 16 ; Myvalue\16
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        Code:
        function bighex$(q&&)
        dim p as long ptr
        p=varptr32(q&&)
        if @p[1] then
                function=hex$(@p[1])+right$("0000000"+hex$(@p),8)
                else
                function=hex$(@p)
                end if
        
        end function
        ------------------

        Comment


        • #5
          Hi Mike,

          This routine can handle a Hex String over a Terabyte.

          DIM N AS QUAD

          N=999999999999999999
          PRINT USING$("###,###,###,###,###,###",N) REM just formatting the decimal for displaying

          GOSUB GETHEX
          PRINT HEXSTRING1$
          PRINT HEXSTRING2$
          END

          GETHEX:
          REM Could put into a sub
          REM HEXSTRING1$= Intel Little endian
          REM HEXSTRING2$=HEX STRING

          H8=N\7.205759403792794D+16:N=N-(7.205759403792794D+16*H8)
          H7=N\281474976710656#:N=N-(281474976710656#*H7)
          H6=N\1099511627776#:N=N-(1099511627776#*H6)
          H5=N\4294967296#:N=N-(42949672 96#*H5)

          H4=N\16777216#:N=N-(16777216#*H4):H3=N\65536!:N=N-(65536!*H3):H2=N\256:N=N-(256*H2):H1=N\1
          REM
          HEXSTRING1$=CHR$(H1)+CHR$(H2)+CHR$(H3)+CHR$(H4)+CHR$(H5)+CHR$(H6)+CHR$(H7)+CHR$(H8)
          HEXSTRING2$=HEX$(H8)+HEX$(H7)+HEX$(H6)+HEX$(H5)+HEX$(H4)+HEX$(H3)+HEX$(H2)+HEX$(H1)
          HEXSTRING2$=LTRIM$(HEXSTRING2$,"0")
          RETURN

          Best Regards,
          Tim http://www.omnixray.com


          [This message has been edited by Tim Camarda (edited March 07, 2005).]

          Comment


          • #6
            Thanks to all of you for your contributions.

            But, it leads to another thought on this. OK, PB 3.5 for DOS handles
            quad integers. It must do this by storing them at some point in memory
            for them to be usable. Thus, what does PB use to process this in
            memory as it's resident way of doing this? With that thought in mind,
            is there a more 'coordinated' way to do this by using a pointer to
            the location in memory where the number is stored? Then reading that
            data directly from memory? And as an obviously related question; how
            many digits in memory space does PB use to represent that && variable?

            Which brings the next thrust of my quest forward. So I get the data
            format for the && integer into hex. Now I need to cast it back into
            the && style variable in PB 3.5 for DOS, so I can print it on the
            screen and on paper and so on!

            You can see these longer and larger number print in pure digit format
            on the screen. Not base E represented. Thus PB is doing this internally
            in some way. So why can't I use the data the way PB does this to do all
            this, just like I've done for years with 'long' integers?

            Inquiring mind wants to know! Thanks..




            ------------------
            Mike Luther
            [email protected]
            Mike Luther
            [email protected]

            Comment


            • #7
              Mike,
              QUADs are just 8 bytes in memory and are a standard Intel data type, usually handled by the FPU in PB, but you probably don't need to know that.
              Intel data types are little endian, lowest byte is in lowest address.
              You can access them using pointers like any other data type:
              Code:
              a&&=&h1234567890123456   'a QUAD
              
              dim p as byte ptr
              p=varptr32(a&&)          'pointer to the bytes in that QUAD
              for r& = 7 to 0 step-1
              print right$("0"+hex$(@p[r&]),2);" ";
              next
              print
              <<So why can't I use the data the way PB does this to do all this, just like I've done for years with 'long' integers? >>

              Don't know. Why can't you?

              Paul.

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

              Comment

              Working...
              X