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