🚀 go-pugleaf

As one of the designers of the new optimizing compiler for the NS32000,
I enjoyed reading the articles posted on the above subject. I am going to 
describe the way that our implementation deals with some of the issues that 
were mentioned (see title).

It is needless to say (but I'll say it anyway...) that I completely agree 
with all those who condemn using pointers to local variables, and assumming
that incrementing the pointer will point to the next declared variable.
Not only that any of these variables may end up in a register, but
even those that stayed in memory (because there was no free register for them)
are reallocated to fill the "holes" created by the lucky ones (i.e. variables
that won a register). This reduces the size of frames (sometimes down to zero).

Someone from Sun (don't remember the name) has suggested to declare all 
variables that are not affected by pointers or by other functions as 
'register' in order to help the optimizer. 
As far as I understand this is completely unnecessary.
According to the "white book" 'register' storage class is applicable 
only for automatic variables or function parameters, and it is not
possible to take the address of a register variable. This leaves us with
local variables whose address is never taken, which are considered safe 
by the optimizer since they cannot be affected by pointers or by other 
functions (unless we play dangerous games with pointers, which we already 
promised not to!!). 


The conventions for saving registers by the caller vs. the callee were
mentioned too, but no one mentioned the posibility of a compromise between
the two - combined caller and callee save. This convention is used by
good old Portable C Compiler (pcc). By this convention, the registers
are divided into two groups: volatile and non-volatile registers
(on the VAX and NS32000 the volatile registers are R0..R2 and the rest are 
non-volatile). Volatile register means that a procedure call may change
its contents, so it has to be saved by the caller (or not used across
procedure calls). Non-volatile register means that a procedure call is
guaranteed to retain its old value, so it has to be saved by the callee
(if used by the callee).
The pcc uses non-volatile registers for 'register' declarations and 
volatile registers for expression evaluation. This means that every
'register' declaration causes save and restore of that register in
the beginning and end of the procedure that contains the declarations.
Declaring a variable that is used only once or twice as 'register'
may therefore cause perfomance degradation (depending on the exact
instruction timings). 
Since most expressions do not contain function calls, using non-volatile
registers for expression evaluation is very efficient.

Our optimizer uses the same convention (so modules compiled by either
compiler are compatible) but squeezes a little more performance out of it 
by using the following strategy: 
a variable that spans across procedure calls
(in optimizers' jargon: a variable whose live range contains procedure calls)
is allocated a non-volatile register (if still profitable after taking
into account the cost of save/restore). A variable that doesn't live across
procedure calls is allocated a volatile register (if available), which is
cheaper to use because it does not require save/restore (because, by
convention, the caller does not expect it to retain its value...).

I hope this answers the original question: what is the available number
of registers for 'register' declaration.


Uri Postavsky (...utgpu!syntron!orcisi!urip)

Currently with O.R.C. Toronto,
 formerly with National Semiconductor Tel Aviv.