acz@pucc-k (John R. Jackson) (06/27/86)
Sorry this is lengthy, but here goes.
I do maintenance and development on the C compiler for the CDC Cyber
205 supercomputer.
Among other oddities about the hardware are a very large set of general
purpose registers (256 of them!). All (non-vector) operations are
performed register to register, so it is best to have as many variables
declared register as possible. Since most C programs do not often use
the register declaration, I need to study how to automatically promote
locals.
I am aware of some work done at HCR in this area, and would appreciate
any information they can give me. I would also appreciate any ideas
anyone has. I am aware of the problems of anything pointing to
anything, but it will be better to help most of the cases and then go
back and disable the promotion where it causes problems (via the auto
keyword???).
A second use of the register file could be to hold global variables.
Since most routines only have a few local variables, even promoting
everything will not use the registers fully. One possibility I am
considering is an extension to the register declaration to specify what
register the variable should be assigned to. Something like:
sub (parm)
register parm; {
register (0x9a) global;
.
.
.
}
The register storage declaration for parm would be treated as normal,
i.e. the next available free register will be assigned. The global
declaration would force register #9A to be used. Variables declared in
this way would not be saved across function calls, unless they happen
to overlap a register that will be saved anyway. The scope would be
the routine the variable was declared in.
An alternative, or extension, would allow the register storage class to
be used outside the function body, again with the syntax extension to
specify a particular register. The scope would then be the rest of the
source file just like any other external or static variable.
Note that I am not particularly interested in the portability issue.
My intent is to provide a performance boost for programs designed for
the 205. This compiler already has so many syntax extensions for
vector references, one more isn't going to make any difference.
Does the C standard say anything about either of these issues? By the
way, how do I get a copy?
Please reply by mail as much as possible, as I do not want to start a
net war about this.
Thanks in advance.
John R. Jackson Senior 205 Systems Programmer
ARPANET: jrj@asc.Purdue.EDU Purdue University Computing Center
or jrj@purdue-asc.ARPA Mathematical Sciences Bldg.
BITNET: JACKSON@PURCCVM West Lafayette, IN 47907
USENET: jrj@pucc-j.UUCP 317/494-1787rcd@nbires.UUCP (Dick Dunn) (07/03/86)
In article <1409@pucc-k>, acz@pucc-k (John R. Jackson) writes: > I do maintenance and development on the C compiler for the CDC Cyber > 205 supercomputer. > > Among other oddities about the hardware are a very large set of general > purpose registers (256 of them!). All (non-vector) operations are > performed register to register, so it is best to have as many variables > declared register as possible... >... > A second use of the register file could be to hold global variables. See a very interesting paper presented at the SIGPLAN Compiler Construction Conference, Palo Alto, 27 June 1986, appearing in the July SIGPLAN Notices (the conference proceedings). The paper is "Global Register Allocation at Link Time", by David Wall of DEC Western Research Lab. The idea is to use either data flow analysis or execution profile information to make decisions about what (scalar) variables should be allocated to registers, and to include enough information with the compiled code that the register-allocation decisions can be deferred to link time so that you can take into account global considerations. It was applied to a machine with 64 registers, but results are also indicated as applicable to machines with a small number of registers. I'm not associated with the work in any way; I heard the talk (which was realistic and well-presented) and it sounded like an interesting idea. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Simpler is better.