Tue, 22 Jul 2014 22:36:40 -0600

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) |

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.