Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!nagler@seismo.CSS.GOV@olsen.UUCP From: nagler@seismo.CSS.GOV@olsen.UUCP (Robert Nagler) Newsgroups: comp.lang.modula2 Subject: Re: Modula-2 standard Message-ID: <8612141228.AA02495@olsen.uucp> Date: Tue, 16-Dec-86 02:28:16 EST Article-I.D.: olsen.8612141228.AA02495 Posted: Tue Dec 16 02:28:16 1986 Date-Received: Wed, 17-Dec-86 04:53:35 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 67 From Marty Smith: When I want a program optimized for execution speed rather than memory usage, I want the compiler to optimize for speed. I agree with the above statement whole-heartedly. I think all compilers should have a range of optimization: execution speed vs. space vs. compilation time. The programmer could specify it on the command line. The compiler could then trade off on the amount of loop unrolling, size of procedures to inline, complexity of register coloring algorithms, etc. From Doug Johnston: The decision to include procedures inline may often be better done by compilers but compilers often do not have all of the information necessary to make good decisions. Exactly what information does the compiler have that the programmer doesn't? I think there are many things that the programmer shouldn't know that the compiler does, e.g. knowing the cache size of the target is 128Kbytes (fully associative), thus it might be a good idea to re-execute the 5 lines of code from the cache than re-fetching the instructions if the procedure is called three times in a row. ...I know that programmers may not always make the best decisions but it is not my job to control them. Given two tasks, people always tend towards the easier one. Micro-optimizing source code is *easy* for your average programmer, but designing quality systems is hard (documented, maintainable, extensible, robust). I make this statement after catching a lot of very fast bugs. As a manager, I want the programmers I work with to design fast systems not optimize bad designs. Sometimes, I think it would be better if we weren't even allowed to write code and we would have to hand over a design to a data entry typist who knows how to translate pseudo-code to Modula-2. Getting to the bits is very important, but only in a very few cases (10% of the code does 90% of the work). I don't know. Maybe I am wrong. If this discussion results in a Modula-2 standard for INLINE, I think we should also consider the following primitives: LOCKDOWN - inserted before a memory declaration (procedure or variable), the declared memory is ``locked down'' in so that swapping or paging will not occur. REGISTER - before a variable declaration indicates that the variable should be kept in memory (even globals). Before a parameter procedure (in def mod of course) would specify that the parameters should be passed in the registers. SUBEXP[xxx] - before a parenthesized expression indicates to the compiler that the following expression is identified as 'xxx'. If another SUBEXP[xxx] appears, then the compiler should use the previous value instead of generating the code for this new expression. REF - before a parameter declaration indicates to the compiler that the parameter should be passed by reference, but to the caller it should appear as a pass-by-value. The idea of course is that the called procedure will probably not touch the variable. This would replace the over-used VAR (see Strings.Length in Logitech's library for a good use of this new primitive). DONTLOOK - instead of these silly function-like coercions that always seem to get in the way. This primitive would tell the compiler to turn off all levels of type, range, etc-checking until a matching END statement. Did I leave out anything? If you would like to see a more complete list, see the "C Puzzle Book". Rob Nagler [If my employer knew what I was writing, I think he would fire me for wasting time. As far as opinions go, my employer has a lot of them.]