Not on Cardinal

[Okoba]

I tried readying the link and the only thing I can deduct that explains the difference I see between Dword and QWord is this:

Please note that the qword and int64 types are not true ordinals, so some Pascal constructs will not work with these two integer types.

and there is a part saying:

The result of binary arithmetic operators (+, -, *, etc.) is determined in the following way:
If at least one of the operands is larger than the native integer size, the result is chosen to be the smallest type that encompasses the ranges of the types of both operands. This means that mixing an unsigned with a smaller or equal in size signed will produce a signed type that is larger than both of them.
If both operands have the same signedness, the result is the same type as them. The only exception is subtracting (-): in the case of unsigned - unsigned subtracting produces a signed result in FPC (as in Delphi, but not in TP7).
Mixing signed and unsigned operands of the “native” int size produces a larger signed result. This means that mixing longint and longword on 32-bit platforms will produce an int64. Similarly, mixing byte and shortint on 8-bit platforms (AVR) will produce a smallint.

So what step of this rules made it to change the Cardinal to an Integer because of not?

I still do not know why not made a Cardinal (DWord) turn to an Integer, and why that reason does not effect QWord.

[Zvoni]

I tried readying the link and the only thing I can deduct that explains the difference I see between Dword and QWord is this:

Please note that the qword and int64 types are not true ordinals, so some Pascal constructs will not work with these two integer types.

and there is a part saying:

The result of binary arithmetic operators (+, -, *, etc.) is determined in the following way:
If at least one of the operands is larger than the native integer size, the result is chosen to be the smallest type that encompasses the ranges of the types of both operands. This means that mixing an unsigned with a smaller or equal in size signed will produce a signed type that is larger than both of them.
If both operands have the same signedness, the result is the same type as them. The only exception is subtracting (-): in the case of unsigned - unsigned subtracting produces a signed result in FPC (as in Delphi, but not in TP7).
Mixing signed and unsigned operands of the “native” int size produces a larger signed result. This means that mixing longint and longword on 32-bit platforms will produce an int64. Similarly, mixing byte and shortint on 8-bit platforms (AVR) will produce a smallint.

So what step of this rules made it to change the Cardinal to an Integer because of not?

I still do not know why not made a Cardinal (DWord) turn to an Integer, and why that reason does not effect QWord.

This is about binary arithmetic operations, not logical/Bitwise operations, so no idea why you think that has anything to do with it
(except if someone can explain, that arithmetic operations can be "translated" to logical/bitwise operations)

[Okoba]

I don't know too. I was just guessing.
My understanding was that, if you do bitwise operation, you will always get the same type.
For example, for arithmetic operation, you can get a Int64 from multiplying two Integer. But doing shr on a DWord, will always be a DWord. So why "Not" is different or I misunderstood something, is my question.

[cdbc]

Hi
"Not" is a negation operator, so ofc, it will try to give you the negative value, but you can't have negatives in an unsigned type like cardinal, longword, dword, qword, ptruint or for that matter byte! If the compiler was an a***, it would give anything in between 0..high(datatype) that is NOT "2" in your example, so give it credit for trying to play along with your shenanigans...
Regards Benny

[Okoba]

I thought "Not" makes 0 to 1, 00 to 11 and 01 to 10. Am I wrong?

[Zvoni]

Hi
"Not" is a negation operator, so ofc, it will try to give you the negative value, but you can't have negatives in an unsigned type like cardinal, longword, dword, qword, ptruint or for that matter byte! If the compiler was an a***, it would give anything in between 0..high(datatype) that is NOT "2" in your example, so give it credit for trying to play along with your shenanigans...
Regards Benny

You would have to explain, how a logical/bitwise operator "knows" the operand is positive/negative resp. its result
a logical/bitwise operator doesn't care about signed/unsigned, it (should) only care(s) about bits

[TRon]

I tried readying the link and the only thing I can deduct that explains the difference I see between Dword and QWord is this:

Start with the basics first.

Remark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.

Now first ask yourself:
- what is C (typewise) ?
- what is the "native" integer for your platform
- So how does c get promoted/demoted ?

Then apply the rest of the rules.


If you still have no idea what is being talked about then you can proof it:

Code: Pascal  [Select][+][-]

1. program proof;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   math;
7.  
8. const
9.   c = 2;
10.  
11. begin
12.   writeln('c = #', c);
13.   writeln('c = $', HexStr(c, sizeof(c) * 2));
14.   writeln('c = %', BinStr(c, sizeof(c) * 8));
15.   writeln('sizeof(c) = ', sizeof(c), ' bytes');
16.   writeln('sign(c) = ', sign(c));
17.  
18.   writeln;
19.  
20.   writeln('cardinal(c) = #', cardinal(c));
21.   writeln('cardinal(c) = $', HexStr(cardinal(c), sizeof(cardinal(c)) * 2));
22.   writeln('cardinal(c) = %', BinStr(cardinal(c), sizeof(cardinal(c)) * 8));
23.   writeln('sizeof(cardinal(c)) = ', sizeof(cardinal(c)), ' bytes');
24.   writeln('sign(cardinal(c)) = ', sign(cardinal(c)));
25.  
26.   writeln;
27.  
28.   writeln('not c = #', not c);
29.   writeln('not c = $', HexStr(not c, sizeof(not c) * 2));
30.   writeln('not c = %', BinStr(not c, sizeof(not c) * 8));
31.   writeln('sizeof(not c) = ', sizeof(not c), ' bytes');
32.   writeln('sign(not c) = ', sign(not c));
33.  
34.   writeln;
35.  
36.   writeln('cardinal(not c) = #', cardinal(not c));
37.   writeln('cardinal(not c) = $', HexStr(cardinal(not c), sizeof(cardinal(not c)) * 2));
38.   writeln('cardinal(not c) = %', BinStr(cardinal(not c), sizeof(cardinal(not c)) * 8));
39.   writeln('sizeof(cardinal(not c)) = ', sizeof(cardinal(not c)), ' bytes');
40.   writeln('sign(cardinal(not c)) = ', sign(cardinal(not c)));
41. end.
42.  

[TRon]

This is about binary arithmetic operations, not logical/Bitwise operations, so no idea why you think that has anything to do with it (except if someone can explain, that arithmetic operations can be "translated" to logical/bitwise operations)

Yeah well... to make things simpler .. (from here) "Logical operators act on the individual bits of ordinal expressions. Logical operators require operands that are of an integer type, and produce an integer type result.". This act different from the boolean operator as there the operator expects a single bit (true/false) "Boolean operators can only have boolean type operands, and the resulting type is always boolean."

So it /might/ appear that the operators act exactly the same but basically they do not. Ofc you can 'convert' a single bit to an integer or an integer to a single bit (any way you deem fit) so that you can switch between which operator is applied. I personally have not found any use for it though (*)

(*) I forgot one pesky thing. C and its "if x then", which actually represents if x <> 0.