is ++n equivalent to (n=n+1) ?

[Kobu]

Hi,

I've gotten into the habit of mentally converting big expressions to
parse tress (started doing this after reading some c.l.c posts on parse
trees).

Can someone verify if the following assumptions are correct?

1) For ++n, one can us (n=n+1) as it's equivalent:

| =
| / \
| n +
| / \
| n 1


2) For assignment operators of the form n op= b, the equivalent tree
is:

| =
| / \
| n op
| / \
| n b

3) For n++, one can use n, but with a side condition that (n=n+1) will
occur somewhere between now and the earliest sequence point up the tree
(but n=n+1 is no physically part of the tree)

|
| n
|
| [Side note: (n=n+1) can occure as a side effect anytime before the
| earliest sequence point up the tree]



Are my assumption correct?

 

[Walter Roberson]

:I've gotten into the habit of mentally converting big expressions to
arse tress

:Can someone verify if the following assumptions are correct?

:1) For ++n, one can us (n=n+1) as it's equivalent:

No. Suppose n is an expression that returns an lvalue and which
has side effects. In n = n + 1 then n will be evaluated for both
sides of the assignment, resulting in the side effect being done
twice. In n++ or n op= p n will only be evaluated once.

For example, queuehead()->count = queuehead()->count + 1
differs from queuehead()->count++

 

[Christian Bau]

Hi,

I've gotten into the habit of mentally converting big expressions to
parse tress (started doing this after reading some c.l.c posts on parse
trees).

Can someone verify if the following assumptions are correct?

1) For ++n, one can us (n=n+1) as it's equivalent:

| =
| / \
| n +
| / \
| n 1


2) For assignment operators of the form n op= b, the equivalent tree
is:

| =
| / \
| n op
| / \
| n b

Correct, except that the lvalue n is only evaluated once. So

++(*++p); ++a [i++];

is absolutely not the same as

(*++p) = (*++p) + 1; a [i++] = a [i++] + 1;


but for a plain variable like n it is correct. (2) is quite important if
you need to figure out exactly what happens for example if you have a
complicated case like

unsigned short us;
double d;

us += d;

In a case like that, all you need to do is to read what exactly (us + d)
does, and then you read the rules what assigning a double to an unsigned
short exactly does. Defining it this way must have saved dozens of pages
in the C Standard.

3) For n++, one can use n, but with a side condition that (n=n+1) will
occur somewhere between now and the earliest sequence point up the tree
(but n=n+1 is no physically part of the tree)

|
| n
|
| [Side note: (n=n+1) can occure as a side effect anytime before the
| earliest sequence point up the tree]

Yes.

 

[Kobu]

Hi,

I've gotten into the habit of mentally converting big expressions to
parse tress (started doing this after reading some c.l.c posts on parse
trees).

Can someone verify if the following assumptions are correct?

1) For ++n, one can us (n=n+1) as it's equivalent:

| =
| / \
| n +
| / \
| n 1


2) For assignment operators of the form n op= b, the equivalent tree
is:

| =
| / \
| n op
| / \
| n b

Correct, except that the lvalue n is only evaluated once. So

++(*++p); ++a [i++];

is absolutely not the same as

(*++p) = (*++p) + 1; a [i++] = a [i++] + 1;


but for a plain variable like n it is correct. (2) is quite important if
you need to figure out exactly what happens for example if you have a

complicated case like

unsigned short us;
double d;

us += d;

In a case like that, all you need to do is to read what exactly (us + d)
does, and then you read the rules what assigning a double to an unsigned
short exactly does. Defining it this way must have saved dozens of pages
in the C Standard.

3) For n++, one can use n, but with a side condition that (n=n+1) will
occur somewhere between now and the earliest sequence point up the tree
(but n=n+1 is no physically part of the tree)

|
| n
|
| [Side note: (n=n+1) can occure as a side effect anytime before the
| earliest sequence point up the tree]

Yes.

Good point, I guess I can represent (exp)++ where exp has meaning as
an lvalue as:


| =
| / \
| temp +
| / \
| = 1
| / \
| temp exp <-- exp would really be more branching
| (executed once)


where (exp) = (exp) + 1 would be:

| =
| / \
| exp + <--
| / \ |-- exp related branching in two places
| exp 1 <-- (executed twice)
|

 

[TTroy]

Hi,

I've gotten into the habit of mentally converting big expressions to
parse tress (started doing this after reading some c.l.c posts on parse
trees).

Can someone verify if the following assumptions are correct?

1) For ++n, one can us (n=n+1) as it's equivalent:

| =
| / \
| n +
| / \
| n 1


2) For assignment operators of the form n op= b, the equivalent tree
is:

| =
| / \
| n op
| / \
| n b

Correct, except that the lvalue n is only evaluated once. So

++(*++p); ++a [i++];

is absolutely not the same as

(*++p) = (*++p) + 1; a [i++] = a [i++] + 1;


but for a plain variable like n it is correct. (2) is quite

important

if
you need to figure out exactly what happens for example if you have

a

complicated case like

unsigned short us;
double d;

us += d;

In a case like that, all you need to do is to read what exactly (us

+

d)
does, and then you read the rules what assigning a double to an unsigned
short exactly does. Defining it this way must have saved dozens of pages
in the C Standard.

snip


Good point, I guess I can represent (exp)++ where exp has meaning as
an lvalue as:


| =
| / \
| temp +
| / \
| = 1
| / \
| temp exp <-- exp would really be more branching
| (executed once)


where (exp) = (exp) + 1 would be:

| =
| / \
| exp + <--
| / \ |-- exp related branching in two places
| exp 1 <-- (executed twice)
|

Does this distinction apply to (exp) op= b ? Is exp guranteed to
evaluate only once or is (exp) op= b truly equivalent to (exp) = (exp)
op b ?

 

[Walter Roberson]

oes this distinction apply to (exp) op= b ? Is exp guranteed to
:evaluate only once or is (exp) op= b truly equivalent to (exp) = (exp)
p b ?

The C89 standard says that they are equivilent -except- that (exp)
is evaluated only once for (exp) op= b .

 

[TTroy]

snipped


No. Suppose n is an expression that returns an lvalue and which
has side effects. In n = n + 1 then n will be evaluated for both
sides of the assignment, resulting in the side effect being done
twice. In n++ or n op= p n will only be evaluated once.

For example, queuehead()->count = queuehead()->count + 1
differs from queuehead()->count++

I've never seen that. A function name followed by the -> operator. Is
this part of C or C++? I thought -> only goes with structures.

 

[Kenneth Brody]

TTroy wrote:
[...]

I've never seen that. A function name followed by the -> operator. Is
this part of C or C++? I thought -> only goes with structures.

Hint:

extern struct MyStruct *queuehead(void);

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Walter Roberson]

:Walter Roberson wrote:
:> For example, queuehead()->count = queuehead()->count + 1

:I've never seen that. A function name followed by the -> operator. Is
:this part of C or C++? I thought -> only goes with structures.

-> goes with pointers to structures. A function can return
a pointer. In traditional C, a function could not return a structure
directly.

 

[CBFalconer]

No. Suppose n is an expression that returns an lvalue and which
has side effects. In n = n + 1 then n will be evaluated for both
sides of the assignment, resulting in the side effect being done
twice. In n++ or n op= p n will only be evaluated once.

That depends on the stupidity level of the code generator. For
example, for n = n+1, we might generate:

load address of n to r1
load indirect r1 to r2
add 1 to r2
(load address of n to r1) only in a STUPID code generator.
store indirect r2 via r1

n has been evaluated only once, and the expression value is in r2.
Now the n++ may be more complex, because of the need to use the
original value. The compiler may detect that this is not needed,
but...

load address of n to r1
load indirect r1 to r2
copy r2 to r3
add 1 to r2
store indirect r2 via r1

now the expression value is in r3. Of course all this depends
highly on the machine language instructions available.

Some of the important things in code generation are selecting
registers, and remembering what is in them, and when you don't
know. The more you can put off selecting, filling, and discarding
registers the better the chance of doing it efficiently by finding
out you can reuse something.

 

[Chris Torek]

Good point, I guess I can represent (exp)++ where exp has meaning as
an lvalue as:

| =
| / \
| temp +
| / \
| = 1
| / \
| temp exp <-- exp would really be more branching
| (executed once)

This tree is not quite right, as it never assigns a new value to
exp.

where (exp) = (exp) + 1 would be:

| =
| / \
| exp + <--
| / \ |-- exp related branching in two places
| exp 1 <-- (executed twice)
|

This tree is fine.

If you write a C compiler, you will likely discover that it is
simplest to include tree-operators for op= expressions. (You can
then use these for prefix ++ and --.) Whether you want to include
separate tree-operators for postfix ++ and -- expressions is a more
delicate matter.... (I am not sure what gcc does. By the time
it gets to code generation, however, it has gone from tree to
RTL; in the RTL, exp++ has been replaced with "tmp_reg = exp;
exp = exp + 1;" anyway. You can see this by passing the "-dr"
flag to the compiler to dump out the RTL.)