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