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