Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!cernvax!hjm From: hjm@cernvax.UUCP (Hubert Matthews) Newsgroups: comp.lang.c Subject: Re: Re^2: Oh noooooo!! Message-ID: <1098@cernvax.UUCP> Date: 26 Sep 89 17:16:05 GMT References: <7598@goofy.megatest.UUCP> <34566@apple.Apple.COM> <556@tigger.planet.bt.co.uk> <33279@ism780c.isc.com> <10756@dasys1.UUCP> <11132@smoke.BRL.MIL> Reply-To: hjm@cernvax.UUCP (Hubert Matthews) Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 22 In article <11132@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <10756@dasys1.UUCP> rpb@dasys1.UUCP (Robert Brady) writes: >>Sorry, but Dijkstra was wrong. How can you attempt to write a program that >>will be optimized in machine code by using constructs that are alien to >>machine code? > >Actually, most Algol-like languages can be better optimized with less >effort if GOTOs are outlawed. It has almost nothing to do with whether >the machine language supports PC reloads (aka branch instructions). Programs that don't use GOTOs generate only reducible flow-graphs; programs that use GOTOs may generate irreducible flow-graphs. Optimising a reducible flow-graph can be done without having to resort to full data-flow analysis (just consider the problem of trying to find loop-invariant expressions if you don't know trivially where the loops are). Thus, the optimiser can be simpler for languages such as C, PASCAL and Modula-2 compared to FORTRAN. Take a look in the Dragon Book (Aho et al.) for more details. -- Hubert Matthews ...helping make the world a quote-free zone... hjm@cernvax.cern.ch hjm@vxomeg.decnet.cern.ch ...!mcvax!cernvax!hjm