Xref: utzoo comp.lang.c++:2093 comp.lang.c:14328 comp.lang.forth:658 comp.lang.fortran:1518 comp.lang.misc:2172 comp.arch:7334
Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.forth,comp.lang.fortran,comp.lang.misc,comp.arch
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: Assembly or ....
Message-ID: <1988Nov28.205129.2216@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1388@aucs.UUCP> <729@convex.UUCP> <1961@crete.cs.glasgow.ac.uk> <6529@june.cs.washington.edu> <1031@l.cc.purdue.edu>
Date: Mon, 28 Nov 88 20:51:29 GMT

In article <1031@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>... What can one think of a compiler 
>designer who has relegated to a subroutine an operation whose inline code
>is shorter than the caller's code to use the subroutine? ...

If the operation is infrequently used and not efficiency-critical, then
what one can think is "this guy knows his tradeoffs".  Adding an operation
to a compiler is not free.

>... But one
>of the most amazing things that I have seen in the workings of the 
>designers is the assumption that the compiler has all the information
>necessary to produce optimized code!  There is no provision for input
>as to frequency of branches...

Not true; some C implementations will take advice from the profiler on
this.  It's practically a necessity for the VLIW folks.  (Oh, you meant
advice from the *programmer*? :-)  The guy who's wrong 3/4 of the time
about such things?  Silly idea.)  (No, I'm not kidding -- programmer
intuition is vastly inferior to measured data in such matters.  This
has been known for many years.)
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu