Path: utzoo!attcan!uunet!husc6!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Branch Delay Annullment
Message-ID: <436@m3.mfci.UUCP>
Date: 20 Jun 88 13:08:24 GMT
References: <12300@apple.Apple.COM> <4053@cbmvax.UUCP> <1995@pt.cs.cmu.edu>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 49

In article <1995@pt.cs.cmu.edu> jgk@speech2.cs.cmu.edu (Joe Keane) writes:
>In article <4053@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
>>	I don't know about you, but I tend to write code that looks more
>>like:
>>	if (!error) {
>>		...
>>	} [else { ... }]
>>
>I think that's less common, especially with multiple errors.  A lot of
>my code looks like:
>
>	if ((... = open (...)) < 0)
>	  quit (...);
>	if (!(... = fopen (...)))
>	  quit (...);
>	if (!(... = malloc (...)))
>	  quit (...);
>	if ((... = read (...)) < 0)
>	  quit (...);
>
>It'd be nice if the compiler knew quit (same as `fprintf (stderr,
>...); exit (...);') is a `dead' function, so it knows the branch is
>usually taken.

All true, but I suspect that there is no practical way for my code
generator to produce code so bad that I'd ever care on code sequences
like these.  This stuff isn't where my programs spend their time, so
optimizing branch latency and filling delay slots in this vicinity
probably constitutes nano-tweaking.  Unless code gets executed a lot
of times, I don't especially care how optimal it is, and those system
calls are going to swamp the conditionals by orders of magnitude
anyway.

The interesting cases are in or near the inner loops, where the
conditionals are going to be evaluated zillions of times.  In there,
I care a lot about how good my code is.  But remember (for scientific
code) jumps are very predictable.  Of all branch instructions
executed, typically something like 90% of them will take their
predicted directions.  Or to put it another way, "The more
predictable jumps are much more frequently executed." (Joseph Fisher,
"Wide Instruction Word Architectures:  Solving the Supercomputer
Software Problem", Proceedings of the INRIA Int'l Seminar on
Scientific Supercomputers, Feb., 1987).


Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090