Re: Post Increment Operator ambiguity??
jcoffin@taeus.com (Jerry Coffin) wrote (abridged):
Since I have an intepreter for a subset of C that I wrote several years
ago, I modified it a bit to enforce strict left-to-right evaluation and
did a bit of testing. Given that it's an intepreter and only handles a
subsest of a language the reesults are far from definitive -- but at
least they're a bit more than you're purely subjective feelings on the
subject -- and they point to considerably greater overall impact than
you're suggesting. Over a small set of test programs, the average impact
was about 7%, which definitely not the purely negligible effect you've
suggested.
Some checking shows that the impact is (mostly) a lot less direct than
you've probably considered. Just for example, on variadic functions, the
previous version evaluated and pushed arguments from right to left to
put the first argument at the top of the stack. To evaluate left to
right and still put the first argument on top of the stack, it evaluated
arguments, put the results in temporaries, and then pushed them on the
stack right to left.
It's hard to decide how important this is. Using a strict stack like that,
with code like:
stack[top++] = value1;
stack[top++] = value2;
is often relatively inefficient compared to code like:
top += 2;
stack[top-2] = value1;
stack[top-1] = value2;
because in the former, top is modified and written back twice rather than
once. Many modern CPUs can do arithmetic in address calculations
effectively for free. On a super-scalar CPU, the two stack assignments of
the second sample can be done in parallel but they can't for the first
sample because the operator++() has a side effect.
So most real compilers use code like the second sample, and with this
scheme the value which ends up at the top of the stack does not have to be
the one evaluated last. Evaluation can be done in any order.
So your interpreter was slower with strict left-to-right evaluation, but
presumably you could have optimised it a bit to make order of evaluation
irrelevant. Should we care because you didn't do the optimisations? Even
in your case the speed difference was only 7%.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]