Path: utzoo!utgpu!water!watmath!clyde!ima!johnl
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.arch
Subject: Re: taken -vs- untaken branches, Fortran FREQUENCY declaration
Summary: letting the programmer declare never worked well
Message-ID: <836@ima.ISC.COM>
Date: 6 Jan 88 22:35:51 GMT
References: <496@cresswell.quintus.UUCP> <638@l.cc.purdue.edu> <20339@amdahl.amdahl.com> <588@PT.CS.CMU.EDU> <18251@bu-cs.BU.EDU>
Reply-To: johnl@ima.UUCP (John R. Levine)
Organization: Not enough to make any difference
Lines: 31

In article <18251@bu-cs.BU.EDU> hen@bucsd.bu.edu (Wm. H. Henneman) writes:
>As I recall, the original FORTRAN (for the IBM 704) had a FREQUENCY
>statement which allowed the programmer to give hints about the
>probability of branches being taken.  It was used by the compiler for
>index register optimization.  
>
>[Why did it disappear in later versions?]

The FREQUENCY statement disappeared for two reasons, as far as I can tell.
The first is that it didn't improve the code much; changing the order of
the "branch if greater" vs. the "branch if less" instructions after a test
made little difference on the non-overlapped, non-pipelined 7094.  The
second, consequent reason, is that practically nobody ever used it.  The
first Fortran I compiler put enormous emphasis on optimization because there
was a well-founded fear that if the object code were too much worse than what
an assembler programmer would have written, nobody would take the compiler
seriously.  The FREQUENCY statement helped the optimization.  In reality,
people took to Fortran quite fast.  Then they asked if the compiler, which
was pretty slow, couldn't run faster.  IBM added a switch to bypass most of
the opmization so as to produce worse code mroe quickly.  Guess what fraction
of compiles left optimization on after that.

But enough of this, it's a far cry from hardware architecture.  The lesson
here seems to be that the compiler should make its branch predictions
automatically based on the code or perhaps iteratively based on information
gathered from profiling a previously compiled version.

-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Gary Hart for President -- Let's win one for the zipper.