C problem, order of evaluation

Niels Ull Jacobsen null at diku.dk
Mon Apr 9 04:50:47 AEST 1990


0Q

7#
Hello world!
I'm having a slight problem.
I need to make an expression of the type:

"( stack[++sp]= exp , stack[sp -= N])", where exp contains N "stack[++sp]"'s.

The expression is supposed to have the value of the right side of the
assignment, and to push this on the stack as well. The expression is to be a
part of a function argument, and can therefore not contain any local block
declarations.

I have the traditional problem of order of evaluation. The above construct 
will only work, if the lval is evaluated before the right side.
Unfortunately, this is NOT guaranteed. I can make a construct, which will
work, if the right side is evaluated first, and I can even make a construct,
which will work, if I know that the order of evaluation for two assignments
is always the same. However, even this is not guaranteed by an optimizing
compiler.

The construct, which would work if the order was homogenous:

"(stack[++sp]=exp, stack[sp -= N] = stack[sp])".

What I want to avoid is:

"(stack[++sp]=MARK, stack[sp]=exp,
  stack[sp -= N] == MARK ? stack[sp]=stack[sp+N]:stack[sp])"

, where MARK is a value, that exp cannot evaluate to. 

I also want to avoid introducing "global" temporary variables, as exp can it
self contain expressions of this type. I can not just use
stack[sp+1],...,stack[sp+N] in exp, as this will do bad things for my
garbage collection.


Does anyone have a smart solution for this problem?

In case you're interested, this is to be a part of the code generated by a
(subset of)Scheme to C compiler, that I'm writing. The final compiler will
be a part of an automated compiler generation system, using partial
evaluation.

                        Niels Ull Jacobsen,
                        Inst. of Datalogy, U of Copenhagen,
                        null at diku.dk
                        (Speaking from the void ..)


-- 
               Niels Ull Jacobsen, Inst. of Datalogy, U of Copenhagen.
               null at diku.dk
               (Speaking from the void ..)



More information about the Comp.lang.c mailing list