Re: Using C as a back end

Keith Thompson <kst@cts.com> writes:
>[You can get the effect of a computed goto in standard C using a
>switch full of goto's, and any decent compiler should generate about
>the same code as for an explicit computed goto, so I don't see that
>particular wart as a major one. -John]


The absence of computed gotos in standard C is a major wart for
systems compiling to C because it forces you to choose between two
undesirable alternatives. Either you compile everything into a single
humongous switch statement, which gives up separate compilation and
requires the use of low optimization levels for even remotely
acceptable compilation times, or you compile each module in your
source language into a separate C source file, which gives up the
speeds that you can get from computed gotos.


The Mercury compiler always compiles different Mercury source files
into different C source files. It can generate either standard C or C
with gcc extensions. Except for testing, we always use the extensions
on platforms on which they are available. The testing we have done
showed that using gcc's nonlocal gotos got a speedup of roughly 50%,
while nonlocal gotos and global variables together tripled the
speed. We did these experiments several years ago, and the numbers
will be somewhat different on today's hardware and with today's
compilers, but the conclusion that the absence of nonlocal gotos is a
problem when using C as an intermediate language should still be
valid.


Zoltan
[I think you mean assigned goto's, not computed ones. A computed goto
takes an integer index into a fixed array of labels and jumps to one
of them, something you can easily fake with a switch containing gotos.
An assigned goto is jump via a variable, which I agree that standard C
doesn't permit. -John]

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