Having recently asked about and learned that it is mainly a hint about performance. I have now another question about this hint:

   project1.lpr(6,9) Hint: Mixing signed expressions and longwords gives

a 64bit result

Actually not so much about the hint, as about the fact that in the below example fpc extends the operands to 64 bits.

program Project1;
var
   x: cardinal;
   i, j: integer;
begin
   i:= x or j
end.

I understand the need for a 64 bit operation for +/-/</>/*/...

But the "or" operator works bitwise, it does not treat the operands as numbers which could either be signed or unsigned? Or does it? If it does not, why does it need to use 64 bit?

i is an "integer" type, and you try to assign it a number that might have 64 bit value.
It might overflow the memory itself.

Furthermore, if you are at 32 bit OS/CPU, you can not do actions on 64 bit in a normal way, because the registers are not supporting it. So you can create your own operands and create your own custom implementation for 64 bit numbers at 32 level (a record of two 32 integer types).

That is not it.

program Project1;
var
   x: cardinal;
   j: integer;
   i: qword; // int64;
begin
   i:= x or j
end.

Happens too, if the left site is int64 or qword.

I understand, the hint is about the fact that doing 64 bit calculations on 32 bit are more expensive. But that was not my question.

Why does " signed_32bit or unsigned_32bit " need to be extended and calculated in 64 bit? "or" operates on a set of bits. Afaik for the "or" statement, there is no diff in signed/unsigned?

---------
BTW, the thin text should really be changed. It is (from what I can see / was told) not at all about the result. It is about the operation. e.g in "if signed32 < unsigned32 then" there is a boolean result (Which I do not think will be a 64 bit bool?). So saying a "64 bit result" appears actually wrong.

Hint: Mixing signed expressions and longwords will use 64bit operations

Pascal evaluates expressions independent of how their result is used. The result of that "x or j" could just as well be assigned to a 64 bit variable, or e.g. passed to a function that is overloaded with both 32 and 64 bit parameters. In those cases the result type of that expression would matter.

That said, the compiler contains an optimization pass that tries to remove 64 bit widenings on 32 bit platforms in case it turns out they were not necessary. It will also catch the above example and the generated code will only contain a 32 bit operations. Semantically, the result of that expression remains 64 bit though.

Jonas

And as an addendum to my previous mail, related to the above: in case range checking is on, then the widening will not be removed and the full (signed) 64 bit value will be range checked against the type of the variable to which the result is assigned.

Jonas

So I am right about the 64 bits not needed.
And the hint is simply because the compiler (for keeping it simple) will first extend *all* mixed signed/unsigned to 64 bit (even if not needed in the end).

During above calculation ("or") a sign extension is required because the result *must* have a definite sign. Else a following comparison of e.g. (x or j)>0 could not determine a result.

An optimization is possible, though, depending on a couple of conditions:
- range checks off?
- overflow checks off?
- any following operation sign sensitive?
The last condition will be hard to check in complex expressions.

Eventually a type cast will help, casting one operand to the type of the other one, or both to the target type?

DoDi

This is casting a "set of bits" (neither signed, nor unsigned - a set is not a number at all) into a number. This only needs to have a definition, if it should cast to signed or unsigned type.

Extending it, and then using the 64 bit result will mean that, the sign will be excluded from the "or" operation. This is not sign is stored in one of the bits (and part of the set of bits), in should be affected.
Here in an example
signed($80000001) OR unsigned($80000002)
will be extended to
signed($ffffffff80000001) OR signed($0000000080000002) the sign is now present in the to pupper dword / for the unsigned value this is empty. Therefore the sign is simply copied from the signed value, without being ever affected by the "or" itself.

The operation could be done with 32 bit
set_of_bits := s32 or u32;

and if you do
set_of_bits > int
set_of_bits + int
or anything then set_of_bits must be cast to an int type. It needs to be defined if that should cast in to signed or unsigned.

Martin wrote

This is casting a "set of bits" (neither signed, nor unsigned - a set is not a number at all) into a number. This only needs to have a definition, if it should cast to signed or unsigned type.

It has to be signed, because otherwise any negative number in the operation would trigger a range check error when it gets converted to a (larger) unsigned type. The nature of the operation that is used afterwards is irrelevant, range checking always operates in exactly the same way when performing a type conversion from one type to another. This is required to have predictable behaviour in a programming language.

Jonas

not sure if I follow. If "or" performs on a "set of bits" (rather than a number), and a set (not being a number) is neither signed or unsigned, then before the "OR" both operands (independent of being signed or not) will be cast to a set. The result is a set. The set can be converted to either signed or unsigned. The set has no range checking.

   result := bit_set32(a) or bit_set32(b)

If result has also 32 (or more) bits, then no range check error can occur. In the set, the high-bit has no meaning. It is neither part of the (unsigned positive) numer, nor is it sign indicator. This meaning is only applied by casting it to a numeric type.

Same as
var i: set of (b0, b1, b2 .... b31);
signed := integer(i);
unsigned := cardinal(i);

Just to menion:

I am NOT trying to get anything changed. It works fine for me as it is.

I would however like to widen/correct my understanding of the matter

In our previous episode, Martin said:

You are redoing what Wirth did 32 years ago. Pascal's successor, Modula2 does exactly that. (though bitwise operations on integers was a very common extension)

It doesn't operate on a set. The left and right operands are whole numbers, and hence the operator works on whole numbers and returns a whole number. In Pascal, sets and whole numbers are completely distinct types with different operators. There is no magic type conversion from integer to a set and back just because you use the "or" operator.

Jonas

A set of bits should be incompatible with ordinal values, as is, then everything is fine. The compiler would flag any mix as an error, instead of doing something unwanted.

Unsigned integer types can be represented as subranges of the next bigger signed type, then all problems with unwanted sign extension go away. When e.g. a file size exceeds 31 bits, it's not a good idea to store it as an unsigned 32 bit value, which will be too small again a few weeks later.

Right. The intended cast should be inserted by the coder.

DoDi