Variable Type

[Don Ewald]

Greetings!

I'm looking at some hex from a file that reads "60 2F 0F 1B 00 00 00 00". In the hex editor I call this a QUAD and it converts to the decimal value of "453980000". I then lop off the ending four zeros and have the real number that I want. In my PowerBASIC TYPE, I used QUAD as the variable type too, convert it to a string and lop off the last four zeroes before displaying it. Sweet, same number.

My method is working; but, something doesn't feel right to this process and I'm curious if my ignorance is blinding me.

[Paul Dixon]

Don,
it would be quicker to divide your quad by 10000 instead of manipulating it as a string.

x&&=&h000000001b0f2f60
PRINT x&&\10000

Paul.

[Don Ewald]

Thanks Paul, that makes more sense than what I've been doing.

[Michael Mattias]

Methinks that might be a decimal-scaled binary with a scale of four: "X AS CUR"

[Don Ewald]

Greetings Michael!

I've not used the Currency variables before. I did some reading in the PB help file and I wrote a small example for me to play with and see how the numbers react. This appeared to be perfect. I loaded up my original TYPE and changed the definition from "AS QUAD" to "AS CUR" and the results are exactly as I want--no further conversion or division needed.

Much thanks, Michael. It's always nice to learn something new.

[Michael Mattias]

CUR types are really handy for the kind of applications I do so I use them a lot.

Basically the only "decimals" I ever use are are prices, quantity and extension - two places after the decimal is sufficient for quantity and perfect for dollars and cents.

Avoids all the rounding crap you get with any of the floating point types (SINGLE, DOUBLE or EXT).

[Mike Doty]

Fine, if you know they are quads, but what if LONGS?

If values are DWORDS division by 10000 may not work.
Changed to a negative in this example.

#COMPILE EXE
#DIM ALL
'DWORD MAXIMUM       4,294,967,295
$EDITOR  = "60 2F 0F 1B 00 00 00 00"
FUNCTION PBMAIN () AS LONG
  LOCAL q AS QUAD, l AS LONG, d AS DWORD
  q = -453980000
  l = q
  d = q
  ? "QUAD"  + STR$(q\10000)  + "  " _
    "LONG"  + STR$(l\10000)  + "  " _
    "DWORD" + STR$(d\10000)
  SLEEP 2000
END FUNCTION

[Mike Doty]

Fine, if you know they are quads, but what if LONGS?

The logic with 10000 might be okay since DWORDS can't be negative.

[Kev Peel]

Function PBMain
    
  Local q As Quad
  Local p As Dword Ptr
  
  q = &h000000001b0f2f60
  p = VarPtr(q)
  ? Format$(@p[0])
 
End Function

[Michael Mattias]

"LONG" and "DWORD" are concepts of convenience only.

Each is a 32-bit binary integer.

The only "difference" if you want to call it that is the treatment of bit 31. When you read or write "as long" bit 31 is a sign bit; when you read or write "as dword" bit 31 is interpreted as just another binary digit conveying magnitude. (FWIW: BIT = BInary DigiT).

This is one reason why using inline numeric literals without type-casting is a bad habit to aquire: if the compiler assumes "LONG" instead of "DWORD" any arithmetic you do may be off by both the sign and the magnitude.

eg

NOT "q = &h000000001b0f2f60"; rather, "q = &h000000001b0f2f60<something>

What does the compiler use here? SINGLE, DOUBLE, EXT, QUAD, CUR and CUX will all hold the value

Better to use "q = &h000000001b0f2f60 {&&|!|@|@@|#|##} " here to eliminate any 'bad guesses' by the compiler.

MCM

[John Petty]

"LONG" and "DWORD" are concepts of convenience only.

Each is a 32-bit binary integer.
MCM

REALLY, do you know the difference between "two's complement" and "one's complement". There are a lot of extra transistors on you CPU chip to give you that convenience. One is a 31 bit signed integer, the other is actually a 32 bit positive only integer.
The compiler must know which it is dealing with to create the correct (very different) instructions to handle what are two totally different numeric types.

[Michael Mattias]

When a "LONG/DWORD" is returned from a WinAPI function, you get 32 bits. Read ("cast") it as you will, consistent with the rest of your program.

When passed by value as a parameter, all 32 bits are pushed on the stack. When this is a variable, you have controlled all those bits in your assignment statements. When passed as an expression or untyped literal , you haven't.

And yes I do the difference between ones complement ("NOT") and twos complement ("NOT" plus 1, discarding any overflow). And because the compiler knows, too, it knows which math routine to use depending on an operand's stated variable type.... which means you have just made my point for me.

Which is, "programmer is responsible for selecting the correct data type for the application and relying on defaults is a stone loser so don't use expressions or untyped numeric literals unless you can live with any sin you might commit however inadvertently."

MCM

[John Petty]

Thank you Michael it seems you do know a little programming, so why would you say that

'bad guesses' by the compiler.

A single also only uses 32 bits, is that a "matter of convenience" too? They also push 32 bits on the stack etc so what has it got to do with WINAPI functions.
Last I looked nobody yet has built a computer or compiler that can accurately guess what the programmer was thinking, so why are you posting about compilers "bad guesses"
Old saying "put mind in gear before opening mouth" so why would you post to younger and mayby less experienced programmers that the only difference is bit 31 as a sign bit which takes us back to the dark ages of having +0 and -0
Regards
John

[Michael Mattias]

... why are you posting about compilers "bad guesses"

So the younger people don't fall into the habit of allowing the compiler to make them!

(FWIW although it could/will/should bore the snot out of that same audience: when you cast your 32 bits "AS LONG" bit 31 IS a sign bit: when set, you must take twos complement and negate to obtain magnitude. When cast "AS DWORD", you have to treat bit 31 as a significant digit. I suspect we have semantic rather than substantive differences here).

[John Petty]

So the younger people don't fall into the habit of allowing the compiler to make them!

(FWIW although it could/will/should bore the snot out of that same audience: when you cast your 32 bits "AS LONG" bit 31 IS a sign bit: when set, you must take twos complement and negate to obtain magnitude. When cast "AS DWORD", you have to treat bit 31 as a significant digit. I suspect we have semantic rather than substantive differences here).

Sorry can't agree, compilers never make guesses ( at least not on this site) they follow very strict rules. If you post that it is a matter of convenience or guess then you do this site a great disservice so please think before you post

[Michael Mattias]

> compilers never make guesses ( at least not on this site) they follow very strict rules.

You're right. It's just that they SEEM like guesses when you can't find those very strict rules in the documentation. (Even worse when you know those very strict rules are there somewhere).