🚀 go-pugleaf

In article <107302@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Languages Marketing -- MTS) writes:
    
    "modern" compilers tend to do global (well, misnomer, all of a procedure
    at once) analysis; older compilers tended to look at smaller bits of
    code (block, maybe interblock) ... so "modern" compilers have the
    opportunity to do better.

It must be repeated for the Nth time that this is only true if spill
minimization is of paramount importance; if you look at speed, then most
spills avoided by global optimizers with large register sets don't make much
of a difference.
    
    Upshot: modern compilers can employ as many registers are you can design
	in.

But pointlessly... And even old compilers can just register everything in
sight; if there are many registers, then using an optimizer is not very
important.  The hard work, as we have just discussed, is to cache *only* the
variables that matter, for *only* the section of code where they matter (and
this can be done by the programmer using "register" in C, or by the compiler
when fed with either "representative" profile data, or with calculations or
estimations of where hot spots lie).  This tipically requires many less
registers than minimizing spills regardless of whether they are expensive
ones or not.
    
    Naive rationale for infinite (as long as they are free) registers:
				  ^^^^^^^^^^^^^^^^^^^^^^^^

Unfortunately they are not free; more registers make the system stiffer, in
that they do raise the cost of multithreading, which is where os technology
is finally heading (Mach, Os/2, etc...), and they do have costs in real
estate and even, possibly, cycle time lengthening (Cray's law). You only
need a handful of register to capture most of the benefit of expression
optimization, and another to capture most of the benefits of intra statement
optimization (whether you do it via "register" in C or leave it to the
compiler).

Large register banks are only justified for special purpose machines
(vector, VLIW, superscalar) where the only thing that matters is raw speed
in processing batched numeric codes where there is an inherent high degree
of parallelism in the algorithms employed.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk