Re: Writing a C Compiler: lvalues

"Andri Wagner" <andre.nho@gmail.com> wrote


> mov $b, $fp+8 ; $fp+8 is 'x' addess, so I'm storing x's address in
> $b
> 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
> lvalue?


lvalues are one of those things that get more confusing the more you think
about them.


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
lvalue business.


> 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
x++.


--
Bartc

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