🚀 go-pugleaf

In article <952@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes:
[much deleted]
> ...This is a very good
> support for my position on "register" (where a competent programmer is
> expected to do this, with great simplication of the compiler, because
> compilers cannot possibly know which variables are the most frequently used
> dynamically).

Where did this idea come from, and what can we do to send it back???
All it takes for the compiler to allocate based on dynamic frequency is
the right information from an execution profile.  (Q to MIPS folk--don't
you have tools for this right now?)  In practice it may be tedious to
develop a compiler system to do this, but the principle is simple:  Compile
the program once with lots of instrumentation to gather frequency-of-use
info for variables.  Run the instrumented program on what you consider
"typical" data, and catch the output of the instrumentation.  Feed this
data and the program back to the compiler for the super-optimizing pass.

> Or the "register" keyword, and you are a competent programmer. Possibly
> extended to global variables...

There are several flaws here.  First, people who've played with execution
profiles know that very good programmers are often surprised to find out
where a program spends its time.  It's a very common blind spot.  That's
why people build execution-profile tools.  But then note that if you've got
some execution-profile tools, you're on the road to building what you need
to get the compiler doing the tuning for you.

Second, "register" is so weak it's almost useless.  It's only a single
binary attribute; it only gives you one bit of quantifying the "importance"
of a variable--either it is or it isn't.  You get no chance to make
statements about the relative importance of register variables.  This is
tied closely to the question, "How many variables should I declare as
register?  (What frequency of use merits a register attribute?)"

You can't say that a variable is used heavily in one part of the code but
seldom in another part--i.e., keep it in a register for a while, then toss
it back into memory.

But even if "register" gave you enough control, it would still remain a
property of the code rather than of the execution of the code.  If you
change the flow of one part of a program, it may very well change frequency
of use of variables in a far-removed part enough to merit changing register
assignments.  Why should you have to re-comprehend the whole program to
make some localized changes and maintain efficiency.  (Sounds like
something a computer could do.:-)
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Relax...don't worry...have a homebrew.