Unsigned 32-bit integers
Tom Coe
unsigned 32-bit integer type in the upcoming 32-bit Object Pascal.
I think many of the negative responses were from Object Pascal
developers, explaining the difficulty of generating efficient code
with unsigned 32-bit integers.
But are you aware that even the Ada language community has thrown
in the towel on this issue? To quote from the January 1995
"Ada 95 Rationale", II.12 (page 32):
Another important improvement which will be a
great relief to systems programmers is that the language
now includes support for unsigned integer types (modular
types). This provides shift and logical operations as
well as modular arithmetic operations and thus enables
unsigned integers to be manipulated as sequences of bits.
I hope there will not be a response to this post that claims that
Object Pascal will never be suitable for "systems" level
programming!
Please let there be an unsigned 32-bit integer type in the 32-bit
Object Pascal!
Tom Coe
Senior Research Associate
University of Nevada, Las Vegas
c...@nevada.edu
Duncan Murdoch
>Delphi Developers Guide, pg. 21 says the type for unsigned 32bit integer
>is "Comp". However, this code demonstrates that its the same as longint:
But Comp is a 64 bit signed type. It's treated as a floating point type; you
can't use things like Shr, Shl, Mod, or Div on it.
>var
> a: comp; {same result as longint}
>begin
> a := $FFFFFFFF; { or -1 also works }
Both $FFFFFFFF and -1 are different ways to represent the longint value -1.
> if a > 0 then
> MessageDlg('never get this', mtInformation, mbOk, 10);
Since Comp is signed, this is what you should expect.
>Debugger also shows -1 regardless how var 'a' is defined. Is this a bug?
>Maybe they will fix it in Delphi32. I am using Delphi16.
I think it's more like a bug in the Delphi Developers Guide.
Duncan Murdoch
Don Beusee
> Please let there be an unsigned 32-bit integer type in the 32-bit
> Object Pascal!
Delphi Developers Guide, pg. 21 says the type for unsigned 32bit integer
is "Comp". However, this code demonstrates that its the same as longint:
var
a: comp; {same result as longint}
begin
a := $FFFFFFFF; { or -1 also works }
if a > 0 then
MessageDlg('never get this', mtInformation, mbOk, 10);
end;
Debugger also shows -1 regardless how var 'a' is defined. Is this a bug?
Maybe they will fix it in Delphi32. I am using Delphi16.
Regards,
Don.
Don Beusee
> In article <423sk7$l...@inet-nntp-gw-1.us.oracle.com> dbe...@us.oracle.com (Don Beusee) writes:
>
>
> >is "Comp". However, this code demonstrates that its the same as longint:
>
> can't use things like Shr, Shl, Mod, or Div on it.
>
> > a: comp; {same result as longint}
> >begin
> > a := $FFFFFFFF; { or -1 also works }
>
>
> > MessageDlg('never get this', mtInformation, mbOk, 10);
>
>
> >Maybe they will fix it in Delphi32. I am using Delphi16.
>
>
> Duncan Murdoch
Oh - you are right. The Delphi Developers Guide is wrong!! Argh!
Len(a) returns 8, which supports your statement. However, if its 64 bits,
how come $ffffffff is -1? $ffffffff is a 32bit value. I expected it to
come out to $00000000ffffffff (in hex).
After more playing with this, I found out its because the compiler treats
my $ffffffff as an Integer constant. Ugh!
The compiler should match the constant with what you are assigning it to.
How can I assign a value larger than $ffffffff to a Comp variable?
Regards,
Don.
Duncan Murdoch
>After more playing with this, I found out its because the compiler treats
>my $ffffffff as an Integer constant. Ugh!
>The compiler should match the constant with what you are assigning it to.
No it shouldn't. The LHS almost never affects the calculation of an
expression. (Never in standard Pascal.)
>How can I assign a value larger than $ffffffff to a Comp variable?
Use a floating point constant. I don't think there's a way to express those
in hex, you'll need to use decimal. Or use Move.
For example,
var
c : comp;
l : longint;
begin
c := 4294967295.0;
{ or }
l := $FFFFFFFF;
c := 0;
move(l,c,sizeof(l));
end.
These should both have the same effect, since the internal encoding used by
the Comp type is just like a 64 bit integer.
Duncan Murdoch
Steve Teixeira
>dmur...@mast.queensu.ca (Duncan Murdoch) writes:
>> In article <423sk7$l...@inet-nntp-gw-1.us.oracle.com> dbe...@us.oracle.com (Don Beusee) writes:
>>
>>
>> >Delphi Developers Guide, pg. 21 says the type for unsigned 32bit integer
>> >is "Comp". However, this code demonstrates that its the same as longint:
>>
>> But Comp is a 64 bit signed type. It's treated as a floating point type; you
>> can't use things like Shr, Shl, Mod, or Div on it.
>>
>> >var
>> > a: comp; {same result as longint}
>> >begin
>> > a := $FFFFFFFF; { or -1 also works }
>>
>> Both $FFFFFFFF and -1 are different ways to represent the longint value -1.
>>
>> > if a > 0 then
>> > MessageDlg('never get this', mtInformation, mbOk, 10);
>>
>> Since Comp is signed, this is what you should expect.
>>
>> >Debugger also shows -1 regardless how var 'a' is defined. Is this a bug?
>> >Maybe they will fix it in Delphi32. I am using Delphi16.
>>
>> I think it's more like a bug in the Delphi Developers Guide.
>>
>> Duncan Murdoch
>
>Oh - you are right. The Delphi Developers Guide is wrong!! Argh!
>
>Len(a) returns 8, which supports your statement. However, if its 64 bits,
>how come $ffffffff is -1? $ffffffff is a 32bit value. I expected it to
>come out to $00000000ffffffff (in hex).
>
>my $ffffffff as an Integer constant. Ugh!
>
>The compiler should match the constant with what you are assigning it to.
>
>
Take a look at the other article I posted today -- I explain how comp works and why it's in
that chart.
-Steve Teixeira
stei...@borland.com
Don Beusee
> In article <426hbn$d...@inet-nntp-gw-1.us.oracle.com> dbe...@us.oracle.com (Don Beusee) writes:
>
> >my $ffffffff as an Integer constant. Ugh!
>
> >The compiler should match the constant with what you are assigning it to.
>
> expression. (Never in standard Pascal.)
Delphi's OP is not standard Pascal!
> >How can I assign a value larger than $ffffffff to a Comp variable?
>
> Use a floating point constant. I don't think there's a way to express those
> in hex, you'll need to use decimal. Or use Move.
>
> For example,
>
> var
> c : comp;
> l : longint;
> begin
> c := 4294967295.0;
> { or }
> l := $FFFFFFFF;
> c := 0;
> move(l,c,sizeof(l));
> end.
>
> These should both have the same effect, since the internal encoding used by
> the Comp type is just like a 64 bit integer.
>
> Duncan Murdoch
This is a work-around to a deficiency in the language! And this gets ugly
when you need to move larger than $FFFFFFFF into the comp variable or need to
do bit manipulations on it. I could use the decimal.0 approach, but it is not
very intuitive for that usage. We should have an unsigned 32bit type! I
don't think thats asking for too much! My range checking code on 32bit ints
should not have to be coded in a convoluted fashion.
Regards,
Don.
Don Beusee
>>>
>>>
>>>>Delphi Developers Guide, pg. 21 says the type for unsigned 32bit integer
>>>>is "Comp". However, this code demonstrates that its the same as longint:
>>>
>>>But Comp is a 64 bit signed type. It's treated as a floating point type; you
>>>can't use things like Shr, Shl, Mod, or Div on it.
>>>
>>>>var
>>>> a: comp; {same result as longint}
>>>>begin
>>>> a := $FFFFFFFF; { or -1 also works }
>>>
>>>Both $FFFFFFFF and -1 are different ways to represent the longint value -1.
>>>
>>>> if a >0 then
>>>> MessageDlg('never get this', mtInformation, mbOk, 10);
>>>
>>>Since Comp is signed, this is what you should expect.
>>>
>>>>Debugger also shows -1 regardless how var 'a' is defined. Is this a bug?
>>>>Maybe they will fix it in Delphi32. I am using Delphi16.
>>>
>>>I think it's more like a bug in the Delphi Developers Guide.
>>>
>>>Duncan Murdoch
>>
>>Oh - you are right. The Delphi Developers Guide is wrong!! Argh!
>>
>>Len(a) returns 8, which supports your statement. However, if its 64 bits,
>>how come $ffffffff is -1? $ffffffff is a 32bit value. I expected it to
>>come out to $00000000ffffffff (in hex).
>>
>>my $ffffffff as an Integer constant. Ugh!
>>
>>The compiler should match the constant with what you are assigning it to.
>>
>>
>
>that chart.
>
> -Steve Teixeira
> stei...@borland.com
Well, its definately not same as C's unsigned long....fix that pls!
Can you suggest to Delphi developers to make LHS := RHS assignments a little
smarter? Or at least provide a way to have RHS assignments > longint? Having
to work around this makes for very ugly code that is harder to follow.
Also, since $ffffffff is an automatic overflow to a LongInt (which the compiler
is using for number constants), the compiler should generate an error unless
overflow checking is disabled.
Regards,
Don.
Duncan Murdoch
>Also, since $ffffffff is an automatic overflow to a LongInt (which the compiler
>is using for number constants), the compiler should generate an error unless
>overflow checking is disabled.
I think the logic behind the lack of an error is this: you use hex constants
to represent bit patterns. $FFFFFFFF is the bit pattern of -1, so in all
respects the compiler treats it just like a longint value of -1. In general,
the logic is: figure out the bit pattern by decoding the hex string, convert
it to a value assuming it's a longint, and then use it.
So $FFFFFFFF is *not* a way to represent the number 4294967295. The only way
to do that is to use a floating point literal, like "4294967295.0".
Duncan Murdoch
Duncan Murdoch
> My range checking code on 32bit ints
>should not have to be coded in a convoluted fashion.
Maybe not, but it's not a big deal. Code it once, stick it in a unit, and
then use that unit for the rest of your Delphi life.
Duncan Murdoch
Jeroen Pluimers
Thursday August 31 1995 00:26, c...@nevada.edu wrote:
ce> Please let there be an unsigned 32-bit integer type in the 32-bit
ce> Object Pascal!
During the Borland Developers Conference I saw something like DWORD in the
Delphi32 code they showed. However, I'm not sure if that is a real unsigned
32-bit type or an alias for Integer.
Jeroen
Bengt Richter
>Duncan Murdoch
PMJI again, but
"... since $ffffffff is an automatic overflow to a LongInt ..." ??
Are you [DB] implicitly saying that hex constants are unsigned
_numbers_? I agree there should be overflow if so, but I hope
the lack of overflow doesn't mean signed number.
I.e., [DM], while "$FFFFFFFF is the bit pattern of -1," it is
also the bit pattern of endless other things, and IMHO should not
be treated as -1 or as MAXDWORD unless and until the context
makes it appropriate. I.e., there should be no implicit immediate cast
to long int or anything else (except perhaps blob) by the compiler.
So, (by a fine distiction) I agree that $FFFFFFFF is not a way to
represent the number 4294967295 (I'll trust you that that is 2 to the
32nd minus 1), _but_ $FFFFFFFF _is_ a way to represent the bitpattern
that in turn represents 429etc as a DWORD value.
Or -1/4 in 32-bit signed fixed point with two fractional bits.
Or Cardinal 429etc, I would think.
And so on.
So there should be no impediment to DWORD implementation
for the hex constant department.
Make it so, Borland. >>:-)
Regards,
Bengt Richter
----------------------------------------------------------------------------------------------------------------
P.S. I believe my mail program glitched on posting the above, but
apparently not on emailing it. So I'll take the opportunity to
amend my comments, after DM's response (which I hope he doesn't
mind my quoting):
[...]
>You're welcome to your opinion, but the language definition says explicitly
>that it's a longint. See pages 6 and 13 of the Language Guide.
>Duncan Murdoch
I think the problem is that hexadecimal digits are commonly used in
two ways: 1) as the digits of a radix-16 number system notation, and
2) as glyphs for 4-bit bit patterns. The two views are closely
related, so the concepts are often blurred for expediency's sake.
I think the following fom p.6 of the Language Guide is a case in
point:
"Hexadecimal numbers denote integer-type constants; they must be
within the range $00000000 to $FFFFFFFF. The resulting value's sign
is implied by the hexadecimal notation."
Notice two things: They didn't say "range $80000000 to $7FFFFFFF",
so they were apparently thinking unsigned radix-16. And the "sign
is implied..." is conceptual fudge, even though we all know how to
get the result. So there is already a foggy zone to cross between
hexadecimal notation and integers in the Language Guide. And
foggy zones can be dangerous. What happens to $FFFF as a
generic integer going from 16 to 32-bit implementation? Will it
be $0000FFFF or $FFFFFFFF? How do you distinguish between
$FFFF carried forward from 16-bit and the same written natively
in 32?
Whoa! I just noticed the syntax diagram on p.6 of the LG. It says:
unsigned integer --+---[digit sequence]-----------------+------->
^^^^^^^ \---($)---[hex digit sequence]--/
>You're welcome to your opinion, but the language definition says explicitly
>that it's a longint. See pages 6 and 13 of the Language Guide.
I don't think we have an unambiguous specification of the language.
Looks like $FFFFFFFF may be a DWORD internally before it's
transmogrified into a longint. You could resolve the ambiguities
lots of ways. I guess I think letting hex be interpreted by default
as a a bigendian representation of a blob/bitstring type would open
up more useful options than limiting hex to 32 bits. Hex could then be
a consistent alternate representation in place of any type constant.
While they're at it, I would also wish for a corresponding
little-endian blob representation, e.g., $<123456CDEF>
would match $EFCD563412. (I bow to tradition in big-endian
representation of nybbles within bytes). Of course hex would not
be in the unsigned integer syntax diagram in the old way any more
(a blob box would occupy that branch, as well as being on alternate
paths for constants of other types).
...shoot, why do I do this?
Sorry if I've bugged anyone with redundant post/mail.
Bengt Richter
Tom Coe
>>should not have to be coded in a convoluted fashion.
>
>Maybe not, but it's not a big deal. Code it once, stick it in a unit, and
>then use that unit for the rest of your Delphi life.
>
It's still a convoluted way to interface to and from external data that has
unsigned 32-bit integer binary data embedded in a "data structure".
Tom Coe