Path: utzoo!mnetor!uunet!husc6!uwvax!rutgers!iuvax!pur-ee!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: <636@l.cc.purdue.edu>
Date: 28 Dec 87 21:24:32 GMT
References: <4668@pyr.gatech.EDU> <3873@uw-june.UUCP> <6896@brl-smoke.ARPA> <461@viper.Lynx.MN.Org>
Organization: Purdue University Statistics Department
Lines: 66
Summary: Some clarification

In article <461@viper.Lynx.MN.Org>, john@viper.Lynx.MN.Org (John Stanley) writes:
> In article <633@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>  >
>  >The algorithm producer frequently knows so much more about how often 
>  >something is used that automation is impossible.  .....
			........
>   Any time someone uses the word "impossible" I find myself asking
> "Impossible for whom?".

Impossible for an entity, machine or human, who does not know what is going
on in the algorithm.

> .......What I assume Herman is refering to is one
> short section of code in a much larger function (the only way his
> example would have a high probability of being mis-optimized).  I
> don't know about Herman, but if I were writing a segment of code where
> this was true, I'd be very likely to place the short 99% loop in a
> sub-function where -I- can specify register allocations to get it to
> work faster. .........

The cost of a function call is far too great, and loses more than would be
gained. 

>  >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.
> 
>   Since no function using Walter's suggested register optimizations
> could ever safely be optimized if it contained assembler insertions, I
> fail to see why this is a factor.  If you use asm insertions, you're
> obviously already talking about code that assumes the programmer knows
> more about how things should be done than the compiler. .....

 
>   Perhaps I'm being unreasonable, but I'm assuming someone who knows
> enough about their system to try assembly code inserts into a C
> function would know to compile that function without optimization...

I do not see why the compiler could not optimize if the programmer
specified that certain things must be kept in registers.  There are even
possible extensions to the idea.  For example, if something must be in a
register for an operation to work, it could be stored if the registers are 
needed, and then reloaded.

I will make a suggestion which I think touches all the bases mentioned.
Instead of having the compiler make the decisions merely by scanning the 
program, have the programmer give a frequency for each block of code,
including frequencies for branches.  Defaults can be established in
case the programmer does not do this, in the manner suggested above.
The compiler should be provided with some idea of the costs involved.
Of course, the assembler instructions should be able to specify
register symbolic addresses, as a (very) few do, instead of requiring
that assembler instructions which use register arguments must specify
the actual register number.  However, because some instructions use
specific registers, that information must be available to the compiler.

There is no reason why both the compiler and the programmer cannot
participate in the optimization process.
-- 
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