Re: Writing a C Compiler: lvalues

AndrC) Wagner <andre.nho@gmail.com> writes:


> I'm writing a C compiler. It's almost over, except that is not
> handling lvalues correctly.
<snip>
> 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.


Yes, that's normal -- at least as the level of the abstract machine
which seems to be roughly what yo pseudo-assembler is.


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


The C standard (draft PDF available here[1]) tells you which expression
forms denote lvalues and which don't. As you traverse the parse tree,
the "lead operator" of the tree will tell you whether you need l- or
r-value evaluation. The result will be rather naive code, but it is a
start.


[1] http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
<snip>
--
Ben.

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