Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!utcsrgv!garfield!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards,net.lang
Subject: Re:  smart compilers
Message-ID: <2083@umcp-cs.UUCP>
Date: Sat, 22-Dec-84 17:18:21 EST
Article-I.D.: umcp-cs.2083
Posted: Sat Dec 22 17:18:21 1984
Date-Received: Mon, 24-Dec-84 15:41:57 EST
References: <6599@brl-tgr.ARPA> <979@opus.UUCP> <6831@watdaisy.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 31

> It is usually necessary for optimizations to break certain obscure points
> that conform to the language definition, e.g. which order STATEMENTS are
> executed in so that code can be moved out of loops.

Depends on what you mean.  If the loop is guaranteed to be executed at
least once, then moving loop-invariant expressions out of loops is
fine.  If the loop might not get executed, then you can always optimize

	for i := j to k { ... invariant-expr ... }

into

	if j <= k then {
		temp := invariant-expr;
		i := j; do { ... temp ... } while ++i <= k;
	}

(please excuse the syntax).  Note that the "do" is probably slightly
more efficient than the "for", and should probably be used to avoid
degrading performance when j always <= k.

Of course, if you allow such things as interrupts which modify variables
into your language, then the optimizer must be either MUCH smarter (has
to read and understand all your interrupt handlers [.5 :-)]) or you need
hints like ``volatile''.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland