Re: Writing a C Compiler: lvalues

Marc van Lieshout wrote:
> On 08-05-10 15:34, Andri Wagner wrote:
>> What I'm trying to say is: the compiler yields different assembly
>> code for when 'x' is a lvalue and when 'x' is not a lvalue.


>> All documentation that I found about lvalues were too vague, and
>> directed to the programmer, and not to the compiler writer. Are there
>> any specific rules for determining if the result of a expression is a
>> lvalue?
>
> An lvalue is an expression that evaluates to an address, so it *can*
> be used on the left hand side of an assignment. But this is not
> necessarily the case. In an expression like (x + 5) x *is* an lvalue,
> but it isn't used as such, so it should be compiled as an ordinary
> rvalue. So in the expression x = foo, x should be compiled as an
> lvalue (an address to which a value is assigned), and in the
> expression foo = x, x should be compiled to an rvalue (code that
> results in the value of x).


Actually there is little difference between lvalues and rvalues:


A variable x used as an lvalue involves taking the address of x and
automatically dereferencing to store a value into it.


A variable x used as an rvalue involves taking the address of x and
automatically dereferencing to load a value from it.


The compiler can treat them the same, other than checking that it qualifies
as an lvalue.


Some terms and expressions (such as the result of a+b) generally don't
involve addresses so can only be rvalues.


There might be some confusion when such an operation actually yields an
address value; in this case, this is still an rvalue, unless accompanied by
explicit dereferencing (depending on language):


  *f(a) = x; /* '*f(a)' is the lvalue */


In fact it is probably the act of derefencing (implicitly or explicitly)
that tells the compiler to check for lvalue-ness.


And since this is cross-posted to comp.lang.c, there are always the usual
exceptions mentioned whenever the subject comes up: register variables,
bitfields and so on, which in C cannot have their address taken, yet are
still lvalues!


This is not a big deal: it is possible to have an abstract concept of the
address of a register or bitfield, since to qualify as an lvalue, no actual
address need taken, only the potential for one is important (as the address,
or taking the address, is accompanied by the dereference, so these cancel
out).


--
Bartc

Return to the comp.compilers page.
Search the comp.compilers archives again.