|Writing a C Compiler: lvalues email@example.com (=?ISO-8859-1?Q?Andr=E9_Wagner?=) (2010-05-08)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Ben Bacarisse) (2010-05-09)|
|Re: Writing a C Compiler: lvalues email@example.com (bart.c) (2010-05-09)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Tom St Denis) (2010-05-09)|
|Re: Writing a C Compiler: lvalues email@example.com (Keith Thompson) (2010-05-09)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Eric Sosman) (2010-05-09)|
|Re: Writing a C Compiler: lvalues email@example.com (Stargazer) (2010-05-10)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Marc van Lieshout) (2010-05-16)|
|[9 later articles]|
|From:||Ben Bacarisse <email@example.com>|
|Date:||Sun, 09 May 2010 17:56:26 +0100|
|Posted-Date:||09 May 2010 16:06:01 EDT|
AndrC) Wagner <firstname.lastname@example.org> writes:
> 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.
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
The C standard (draft PDF available here) 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
Return to the
Search the comp.compilers archives again.