🚀 go-pugleaf

In article <10942@spool.cs.wisc.edu> brianm@jomby.cs.wisc.edu (Brian Miller) writes:
>In article <CEY4QND@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>>In article <2406@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>>> What language allows carrying globals in registers across recursion?
>
>>Any language. All that is required is a good inter-procedural optimiser.
>>That's an implementation detail, not a language feature.
>
>	And as someone pointed out, a cpu with register windows will
>handle inter-procedural globals *and* parameters without compiler
>support.  Example:  Berkley RISC I + II.

This isn't true.  You can do very little without compiler support.
You certainly can't allocate globals to registers without interprocedural
analysis.  Every procedure will need to know where to find the global 
and we must be sure it isn't aliased.  Register windows can't help with 
either problem.

Parameters have some of the same problems.  In C or Fortran, we can
pass parameters in registers, but Pascal and others require more care
since parameters may be referenced from nested procedures and should 
therefore be in memory, in a known locatation.  The nesting also
leads to the same sort of aliasing problems mentioned earlier.

Peter da Silva distinguishes between the language and the implementation,
which is of course important.  However, many (most?) languages are
not very amenable to interprocedural optimization.  

One reason is that the optimizer needs to construct a call multi-graph.
(We say "multi-graph", since one procedure might contain several
calls to another, and the individual call-sites should be distinguished.)
Currently, there are efficient methods for languages that have only
statically declared procedures (no procedure variables or parameters,
like people imagine when they wave their hands about interprocedural
optimization).  There are also versions that can handle procedure parameters
(like Fortran).  Handling procedure-valued variables is very difficult
and isn't done well or efficiently.  This include languages like
C, Oberon, Scheme, ...

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu