Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!mit-eddie!smh
From: smh@mit-eddie.UUCP (Steven M. Haflich)
Newsgroups: net.lang.c
Subject: Re:  advice statement
Message-ID: <2622@mit-eddie.UUCP>
Date: Tue, 28-Aug-84 08:33:08 EDT
Article-I.D.: mit-eddi.2622
Posted: Tue Aug 28 08:33:08 1984
Date-Received: Wed, 29-Aug-84 01:01:46 EDT
References: <12865@sri-arpa.UUCP>
Organization: MIT, Cambridge, MA
Lines: 22

It has been remarked that program flow-control advice given to a
compiler will rarely yield significant speed increase.  This is true for
much code running on normal architectures.  However, pipelined and/or
vector processors can profit greatly by knowing which path to lookahead.
The programmer needn't bother providing advice except for code fragments
of his choosing.  A significant drawback is that programmers are
probably too lazy to provide advice as often as they should.  Some
pipelined RISC machines (which *need* such advice) solve this problem
marvelously by keeping some sort of branch-frequency record right in the
running object code, the microcode updating it on the fly.

Now for a bit of arcane ancient history:  In the middle (early?) 1960s,
IBM 1620 FORTRAN II had a FREQUENCY statement which allowed the
programmer to give branch advice.  (Let me tell you, with the speed of a
1620, the code generator needed all the advice it could get!)  So far as
I know, the FREQUENCY statement was ignored by the compiler and was
never implemented.  But it suggested a principle which still holds:  A
compiler amplifies a programmer, but cannot be truly efficient unless
programmers are willing to tell it enough so it can figure out what
needs to be done.

Steve Haflich