BBS: Inland Empire Archive
Date: 03-04-93 (08:17) Number: 348
From: ZACK JONES Refer#: NONE
To: CORIDON HENSHAW Recvd: NO
Subj: Unsigned Integers Conf: (2) Quik_Bas
Coridon,
Recently you were talking about unsigned integers in QB. Well here's and
article I clipped out of Basic Pro Magazine. See if it makes any sense to
you. It really doesn't to me - I'm not much for bits and stuff like that.
Take Care, Zack Jones.
Beginning of article
**************************************************
As I mentioned earlier, Basic's INTEGER type has a range of +/- 32K.
There are times, though, when you need to use a two-byte variable to
represent an unsigned number with a range of 0 to 65,535, such as when
calling C routine to DOS services.
Basic uses the high bit of an integer to indicate the sign of the number,
so whenever such a variable exceeds 32,767, bit 16 is set and it's
interpreted as a negative number. The key to faking an unsigned
integer, then, is to test the value and adjust the sign bit manually.
Say you want to use CALL INTERRUPT to readk 48K bytes from a file. Since
48K is outside the rand of a Basic integer, you'll have to convert this
value to an unsiged integer to get to get it into the CX register for the
call. Here's the brute-force method:
Bytes& = 49152
IF Bytes& > 32767 THEN
CX% = Bytes% - 65536
ELSE
CX% = Bytes&
END IF
This code simply checks the value of Bytes& and if it's too large, flips the
sign bit by subtracting 65536.
When CALL INTERRUPT returns, CX% will contain the number of bytes actually
read from the file. If this number is greater then 32K, it will look to
Basic like a negative number, so you'll have to make the conversion in the
opposite direction:
Bytes& = CX% + 65536
ELSE
Bytes& = CX%
END IF
This addition and subtraction technique is perfectly valid and no one will
laugh at your code if you use it. But if you're as obsessive about size and
speed as I am, you'll love the alternative!
The code snippet below stores the value of Bytes& in CX% as an unsigned
integer. (see if you can figure out how it works):
CX% = Bytes& and &H7FFF
CX% = CX% OR -(Bytes& AND &H8000)
Give up? The secret is the bitwise operators, AND and OR.
When you AND two numbers, the result in a given bit position is True
(denoted by a binary 1) only when that bit is set in both numbers.
Conversely, the result of and OR is True if a given bit is set in either
number.
So the first line in the above code ANDs the contents of Bytes& with the
hexadecimal value of 7FFF (binary 01111111111111111). This clears the
sign bit, and stores the lower 15 bits in CX%. The second line ANDs
Bytes& with 8000 hex, which returns the state of the sign bit. That
result is OR'd with CX%, thereby setting it's 16th bit to match that of
Bytes&.
The only question that remains is Why is there a minus sign in front of
Bytes& and &H8000)? If bit 16 is set, the result of this operation will
be 65,636 (2^15), and ORing CX% with that value will cause an overflow
error. But by negating the result of the AND, you reduce the equation to:
CX% = CX% or -1
This handly avoids the overflow error, and adds only two bytes of code!
Converting an unsigned value back to a signed one is even simpler:
Bytes& = CX% and &HFFF&
This superimposes the binary image of CX% on the lower 16 bits of a long
integer (yes, the training & is vital!), and stores the result in Bytes&.
Either of these methods will work in QB, PDS and both versions of VB. The
addition/subtraction approach is straight forward - it's immediately
apparent what's happening when you look at the code. But if efficiency is
more imporant to you than readibility, you'll be interested to know the
code employing bitwise operators compiles 12 bytes smaller and runs 40%
faster then that using arithmetic.
*****************************************************
End of article.
___ Blue Wave/QWK v2.12
--- Maximus 2.01wb
* Origin: Zack's Shack ZyXEL 16.8! (210) 653-2115 (1:387/641)
