Re: Writing a C Compiler: lvalues

On May 8, 8:34 am, Andri Wagner <andre....@gmail.com> wrote:
> Hello,
>
> I'm writing a C compiler. It's almost over, except that is not
> handling lvalues correctly. ...


> 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.
>
> This gets more confusing when I have expressions such as 'x++'. This
> is simple, since 'x' is obviously a lvalue in this case. In the case
> of the compiler, I can parse 'x' and see that the lookahead points to
> '++', so it's a lvalue.
>
Yes, the post increment operator takes an lvalue as an operand.
K&R C Appendix A 7.2 Unary Operators, unary-expression: ..., lvalue +
+, ...


> But what about '(x)++'? In this case, the compiler evaluates the
> subexpression '(x)', and this expression results the value of 'x', not
> the address. Now I have a '++' ahead, so how can I know the address of
> 'x' since all that I have is a value?


'x' is an expression, and '(x)' is an expression, but in
implementation, you need to delay their treatment until you know what
to do with them, the post increment operator says how to treat them,
each as a 'lvalue'.


By virtue of '(let's say 'x' was declared before)', presumeably your
compiler holds 'x' in its symbol table, along with its attributes. So
at the point of parsing the operator, you now know how to entreat the
lexeme 'x', you take its lvalue, instead of its rvalue and apply the
operator, post increment, to it (in a syntactical sense).


I had similar problems keeping this straight, so I deprecated my
attention to BCPL to learn that it has operators for lvalue .LVAL. and
rvalue .RVAL. which can be applied to a suitable identifier, thus the
following..


My notes..
'
Historically, lvalue and rvalue take their cue
from their position in an assignment statement:
lvalue := rvalue; .such that. (for C Syntax),
          a = b; .where. the value held in the location ident-
ified by variable 'b' is copied to the location identified
by variable 'a'.
.thus. a variable can be said to possess the three attri-
butes of; a lexeme 'b', a location, and a value. In
contrast, a constant has only two attributes; a lexeme '3'
and a value, but no location. .thus. an assignment to a
constant is an error state. Because of this, I think of
lvalue in terms of being the 'location value' of a variable,
and a rvalue in terms of being the 'referenced value' held
in a variable's lvalue.
'
-Two point to the above:
1) I don't mean to say only three attributes, obviously there are
more; scope, type, etc.


2) Using the terminology 'location value' instead of 'address' makes
sense of things like 'register' and user defined types which may not
have have an ordinal address for a pointer.


> 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?


Yes, follow the operator. Again see K&R C, The C Programming
Language, Appendix A C Reference Manual. Supplement with current iso
standards.


hth,


Steve


> [I believe the usual approach is to translate the expression into an
> AST before doing much else, which has the useful effect of making the
> parentheses go away. As you've found, in C you have to treat (x) and x
> the same. It's not Fortran. -John]

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