Martin schrieb:
On 14/01/2013 13:54, ik wrote:
On Mon, Jan 14, 2013 at 3:11 PM, Martin <laza...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
