Re: Using C as a back end

zs@ender.cs.mu.oz.au (Zoltan Somogyi)
31 Oct 2000 14:36:28 -0500

          From comp.compilers

Related articles
[13 earlier articles]
Re: Using C as a back end predictor@my-deja.com (Pred.) (2000-10-26)
Re: Using C as a back end ONeillCJ@logica.com (Conor O'Neill) (2000-10-26)
Re: Using C as a back end kst@cts.com (Keith Thompson) (2000-10-26)
Re: Using C as a back end jacob@jacob.remcomp.fr (jacob navia) (2000-10-26)
Re: Using C as a back end nr@labrador.eecs.harvard.edu (2000-10-31)
Re: Using C as a back end sweeks@my-deja.com (Stephen T. Weeks) (2000-10-31)
Re: Using C as a back end zs@ender.cs.mu.oz.au (2000-10-31)
Re: Using C as a back end thp@cs.ucr.edu (Tom Payne) (2000-10-31)
Re: Using C as a back end engler@Stanford.EDU (2000-10-31)
Re: Using C as a back end anton@mips.complang.tuwien.ac.at (2000-10-31)
Re: Using C as a back end joachim_d@gmx.de (Joachim Durchholz) (2000-10-31)
Re: Using C as a back end conway@ender.cs.mu.oz.au (2000-11-01)
Re: Using C as a back end kst@cts.com (Keith Thompson) (2000-11-01)
[9 later articles]
| List of all articles for this month |

From: zs@ender.cs.mu.oz.au (Zoltan Somogyi)
Newsgroups: comp.compilers
Date: 31 Oct 2000 14:36:28 -0500
Organization: A poorly-maintained Debian GNU/Linux InterNetNews site
References: 00-10-148 00-10-154 00-10-212
Keywords: C
Posted-Date: 31 Oct 2000 14:36:28 EST

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]







Post a followup to this message

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