Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <633@l.cc.purdue.edu>
Date: 24 Dec 87 12:27:42 GMT
References: <4668@pyr.gatech.EDU> <3873@uw-june.UUCP> <6896@brl-smoke.ARPA> <1448@dataio.Data-IO.COM>
Organization: Purdue University Statistics Department
Lines: 40
Summary: More programmer input is needed

In article <1448@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes:
> In article <1574@copper.TEK.COM> timc@copper.UUCP (Tim Carver) writes:
		.........
> In fact, what the committee should do is deprecate the 'register' keyword. For a
> modern compiler, it is not very useful. Candidates for placing variables in
> registers can be trivially discovered by:
> 	1. Looking at all automatics and parameters.
> 	2. Throw out all that have their address taken.
> 	3. Rank the remainder by frequency of use, using a multiplier of
> 	   10 for those inside loops.

The algorithm producer frequently knows so much more about how often something
is used that automation is impossible.  It is quite possible that a short
section of code can account for 99+% of the total number of instructions used,
and that most of the length of the code is for "exceptions" which must be 
handled, but may occur only one time in 10^50.  No compiler can get this
information from looking at the code; I can only know this by analyzing the
algorithm.

> 	4. Throw out all that have such a small number of uses that it
> 	   isn't worth the register push and pop.

Another use for register variables is for instructions which _require_ that
an argument is in a register.  In fact, some might require that it is in a
particular register.  Most programmers are, unfortunately, ignorant of the
insertion capabilities for assembler instructions, and most compilers do not
help here.  If one is doing such things as double long integer operations,
one register might tie up another; only the programmer can handle this at
present.
  
> I have seen many people spend inordinate amounts of time fiddling with
> register declarations, only to have all their careful 'tuning' work be
> negated when they ported to a different CPU with a different number of
> registers. The compilers should do this grunt work for the coder.

If it can.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet