|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)|
|Re: Writing a C Compiler: lvalues email@example.com (Eric Sosman) (2010-05-17)|
|[8 later articles]|
|Date:||Sun, 9 May 2010 18:05:14 +0100|
|Posted-Date:||09 May 2010 16:06:31 EDT|
"Andri Wagner" <firstname.lastname@example.org> wrote
> mov $b, $fp+8 ; $fp+8 is 'x' addess, so I'm storing x's address in
> mov $a, 5
> mov [$b], $a ; here I'm putting what's in $a in the address
> pointed to $b
> Since 'x' is a lvalue in this case, I don't need its value, just the
> address of the variable.
> Now, if I want to access 'x' in the middle of a non-lvalue expressing,
> I would do:
> mov $a, $fp+8
> mov $a, [$a]
> Notice how I get the varible addres, and from it, the value.
> 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.
What you've done sounds about right:
In both cases, the contents of x are referred to by [$r] where $r contains
the address of x (although, in practice most targets will be able to do [x]
directly instead of having to first load the x's address into a register),
Ie. there is usually no difference, in the generated code, between lvalues
and rvalues, other than you will be storing to lvalues (mov [$r],$a),
instead of loading (mov $a,[$r]).
> 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
lvalues are one of those things that get more confusing the more you think
In my case, I check an expression can be an lvalue by taking the address of
it, then immediately dereference the result. Then I can forget all about the
> But what about '(x)++'? In this case, the compiler evaluates the
> subexpression '(x)', and this expression results the value of 'x', not
As the moderator said, you need to look at how the language is parsed. It
sounds like possibly you're trying to generate code directly from reading
the source, but even here, the parentheses should disappear if the parsing
is done properly.
Anyway if this is a C-compiler, then there should be several passes, and it
should be clear, long before code generation, whether you have x or ++x or
Return to the
Search the comp.compilers archives again.