Re: How to type braces for computed gotos

wclodius@earthlink.net (William Clodius)
Tue, 22 Jul 2014 22:36:40 -0600

          From comp.compilers

Related articles
[3 earlier articles]
Re: How to type braces for computed gotos ivan@ootbcomp.com (Ivan Godard) (2014-07-18)
Re: How to type braces for computed gotos (was: Best "simple" C Compil anton@mips.complang.tuwien.ac.at (2014-07-21)
Re: How to type braces for computed gotos gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-07-21)
Re: How to type braces for computed gotos federation2005@netzero.com (2014-07-21)
Re: How to type braces for computed gotos wclodius@earthlink.net (2014-07-21)
Re: How to type braces for computed gotos gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-07-23)
Re: How to type braces for computed gotos wclodius@earthlink.net (2014-07-22)
Re: How to type braces for computed gotos anton@mips.complang.tuwien.ac.at (2014-07-25)
| List of all articles for this month |

From: wclodius@earthlink.net (William Clodius)
Newsgroups: comp.compilers
Date: Tue, 22 Jul 2014 22:36:40 -0600
Organization: Compilers Central
References: 14-05-013 14-07-033 14-07-048 14-07-054 14-07-056
Keywords: Fortran, syntax
Posted-Date: 23 Jul 2014 09:39:36 EDT

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:


> William Clodius <wclodius@earthlink.net> wrote:
>
> (snip on labeled variable GOTO, Fortran ASSIGNed GOTO, and such)
> ...
> If you consider something like Duff's device, then it isn't so obvious
> that computed GOTO is so different from C's switch/case. (Well, when
> the labels are sequential starting at one.)
>
> As I noted previously, the Fortran standard now considers SELECT CASE
> as a replacement for computed GOTO, though the latter hasn't yet been
> removed from the standard.


In the case of Anton I think for the applications he is best know for,
high performance interpreters, the lack of syntactic block is a minor
advantage in that the


100 SELECT CASE(i)
              CASE(0)
              ...
              GO TO 100
              CASE(1)
              ...
              GO TO 100
              CASE(2)
              ...


can be replaced by


              GO TO(10, 11, 12, ...) I
10 ...
              GO TO(10, 11, 12, ...) I
11 ...
              GO TO(10, 11, 12, ...) I
12 ...


Saving an extra step in indirection. The bigger problem is the fall
through semantics for out of range with its implicit additonal test and
branch before the goto's implicit branch table. That can be avoided by a
modulo operation


GO TO(10, 11, 12, ...) MODULO(I, N) +1


where N is the number of labels appearing in the computed GOTO. If I is
an 8 bit integer and N is 256 a sufficiently smart compiler should
recognize the semantics of an unsigned 8 bit integer, fit the jump table
in a single level 1 cache line, optimize out the MODULO, the addition of
1, and the test for out of range and give him the efficiency he used to
get with gcc's "computed goto". Whether that sufficintly smart compiler
is gfortran with gcc's backend would be a different matter.


Post a followup to this message

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