[fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

[Hans-Peter Diettrich]

Martin schrieb:
> On 14/01/2013 13:54, ik wrote:
>> On Mon, Jan 14, 2013 at 3:11 PM, Martin <lazarus at mfriebe.de> wrote:
>>> 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 is an "integer" type, and you try to assign it a number that might
>> have 64 bit value.
>> It might overflow the memory itself.
>>
> 
> 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?

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