Path: utzoo!mnetor!uunet!husc6!uwvax!umn-d-ub!umn-cs!ems!nis!viper!john
From: john@viper.Lynx.MN.Org (John Stanley)
Newsgroups: comp.lang.c
Subject: Re: (So-Called) ANSI C
Message-ID: <461@viper.Lynx.MN.Org>
Date: 26 Dec 87 16:41:37 GMT
References: <4668@pyr.gatech.EDU> <3873@uw-june.UUCP> <6896@brl-smoke.ARPA> <1448@dataio.Data-IO.COM> <633@l.cc.purdue.edu>
Reply-To: john@viper.UUCP (John Stanley)
Organization: DynaSoft Systems
Lines: 56

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.  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.

  Any time someone uses the word "impossible" I find myself asking
"Impossible for whom?".  The example given, of code where 99% of the
routine is spent in one short section doesn't sound all that
impossible to handle.  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.  In any case, the one exception in "10^50" is -NOT- a
valid argument against using global optimizations of the type
mentioned by Walter Bright.  Optimization is to get things to work
faster most of the time...  There is no way to automaticly optimize a
program that won't fail under some bizzare instance.  I'd rather have
it most of the time and just not enable it if I have something it
can't handle...

 >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.  Why bother
using an obviously dangerous procedure as an argument against allowing
optimizations that never should be used on those very examples?

  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...

 >-- 
 >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

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!meccts!viper!john