🚀 go-pugleaf

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.]