Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!dogie.macc.wisc.edu!decwrl!shelby!portia!dhinds From: dhinds@portia.Stanford.EDU (David Hinds) Newsgroups: comp.lang.misc Subject: Re: 'register' variables and other goodies (was Re: Common subexpression optimization) Message-ID: <9322@portia.Stanford.EDU> Date: 20 Feb 90 01:06:34 GMT References: <1624@aber-cs.UUCP> <1990Feb19.155810.29127@jarvis.csri.toronto.edu> Sender: David Hinds Organization: Stanford University Lines: 28 In article <1990Feb19.155810.29127@jarvis.csri.toronto.edu>, cks@white.toronto.edu (Chris Siebenmann) writes: > > | When something is simple and mechanical, why not let the computer > | do the drudge work? > | > | I tend to agree in principle. In practice, things are less clear > | cut. To make use of profling and heuristic information, the > | compiler has to run complex analysis and optimizing modules. This > | is *bad*. The beauty of things like 'register' is that they are > | absolutely safe and effective, without any analysis whatsoever. > > One danger of having only programmer-level hints is that quite a few > programmers will add wrong hints, or change their programs such that > hints become incorrect. The only way to make sure that the hints are > correct is to make their gathering and use automatic or nearly so. Not to mention that programmers are not omniscient, and a good programmer's best hints aren't enough. FORTRAN may not be a fashionable language among computer scientists, but twenty years of improvement has yielded highly optimizing mainframe compilers that generally can't be beat by hand-coded assembly language. And on unusual architectures, it is often a nightmare for a programmer to figure out an efficient use of the machine's resources. For example, on a Cray, FORTRAN is presently the only way to make efficient use of the machine's resources. Cray Unix may be "hot" now, but C brings the machines to their knees. -David Hinds dhinds@popserver.stanford.edu