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
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
On 14 Jan 2013, at 14:11, Martin wrote:
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
On 14 Jan 2013, at 14:54, ik wrote:
On Mon, Jan 14, 2013 at 3:11 PM, Martin laza...@mfriebe.de wrote:
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
On 14/01/2013 14:10, Jonas Maebe wrote:
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
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
On 14/01/2013 15:27, Hans-Peter Diettrich wrote:
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
On 14 Jan 2013, at 16:44, 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
On 14/01/2013 15:52, Jonas Maebe wrote:
On 14 Jan 2013, at 16:44, 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
In our previous episode, Martin said:
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.
On 14 Jan 2013, at 17:03, Martin wrote:
On 14/01/2013 15:52, Jonas Maebe wrote:
On 14 Jan 2013, at 16:44, 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
Martin schrieb:
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.
This is casting a set of bits (neither signed, nor unsigned - a set is
not a number at all)
12 matches
Mail list logo
