Re: backend question

"Joachim Durchholz" <>
20 Nov 2002 15:17:18 -0500

          From comp.compilers

Related articles
backend question (Martin Doering) (2002-11-12)
Re: backend question (Diego Novillo) (2002-11-13)
Re: backend question (Hannah Schroeter) (2002-11-13)
Re: backend question (Fergus Henderson) (2002-11-13)
Re: backend question (Joachim Durchholz) (2002-11-13)
Re: backend question (2002-11-17)
Re: backend question (Joachim Durchholz) (2002-11-20)
Re: backend question (David Chase) (2002-11-20)
Re: backend question (Fermin Reig) (2002-11-24)
Re: backend question (felix) (2002-11-24)
Re: backend question (Fergus Henderson) (2002-11-24)
Re: backend question (2002-11-24)
Re: backend question (Mark) (2002-11-24)
[9 later articles]
| List of all articles for this month |

From: "Joachim Durchholz" <>
Newsgroups: comp.compilers
Date: 20 Nov 2002 15:17:18 -0500
Organization: Compilers Central
References: 02-11-063 02-11-078 02-11-099
Keywords: C, design
Posted-Date: 20 Nov 2002 15:17:18 EST wrote:
> Joachim Durchholz <> wrote:
> +
> + [C] begins to bite if you're doing
> + concurrency, exceptions, fancy integer arithmetic, tail-call
> + elimination, or state machines.
> Standard C lacks an indirect jump (though one can be kludged a switch
> statement).


> Anything that can be done in say MIPS assembly language
> can be done in gcc, which has an indirect goto.

Indirect goto is good for state machines (and it's been used for that
purpose). It doesn't help with the other issues.

> Where necessary, one can generates comments that preserve the memory
> of what got abstracted away.

It's not abstracted away in the generated C code, it's abstracted away
by the language. For example, tail-call elimination goes like this:
For the last subroutine call in a routine, don't push the parameters
and do a JSR; instead, pop the return address and the parameters of
the caller, push the parameters of the callee, push the popped return
address, then do a direct jump to the subroutine. (You can optimize
the push-pop sequence if the new stack frame is not larger than the
old one.) Impossible in C since C abstracts away the call stack. (A
Good Thing for human-written programming languages. Unsuitable for
compiling functional languages where loops are represented as

You can work around a lot of limitations of C - it's going to be ugly
and inefficient, but it's possible. Tail-call elimination is not
feasible (unless gcc offers another extension to handle exactly this,
of course *g*).


Post a followup to this message

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