Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: GOTO considered essential??
Message-ID: <1094@m3.mfci.UUCP>
Date: 27 Oct 89 13:34:00 GMT
References: <1989Oct27.050923.5294@ico.isc.com>
Sender: colwell@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Distribution: na
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 49

In article <1989Oct27.050923.5294@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes:
>The trade press (such as it is) would have us believe that America has made
>some major innovation in providing five instructions executing in parallel.
>However, to achieve this rate--which has actually been billed as "5
>instructions/cycle"--you have to do a branch in one of every five instruc-
>tions!  Since the magic figure of 5 requires using the floating-point
>unit's multiply-and-accumulate capability, if you're doing only integer
>work, you need a branch every three instructions!  You NEED goto's!
>
>I do *not* want to maintain the sort of code that will keep this processor
>running at max issue rate!

You're obviously talking assembly here, right?  

>Now, mind you, I am not trying to belittle the work IBM has done.  Branches
>are in some sense the nemesis of very fast CPUs, and it helps to be working
>ahead and being able to handle branches without too much delay.  I'm only
>pissed off at the pseudomarketing we're seeing in the trade press.  The
>processor may be able to issue 5 instructions in some ideal cycle, but it
>does NOT run at 5 instructions/cycle for any believable piece of code!

Aw, geez, Dick, you're just mired in reality.  Next you're going to turn
to the i860, 88000, and all the other new processors that have the hardware
to do multiple ops at once and realize that they have similar problems.
Keep this up and Eugene Brooks is going to sic his KILLERS on you.

>(Or maybe it could...who knows; you might be able to replicate code and
>scramble the branches around enough to get close for some codes.  But it
>would take a compiler which could look down various paths and figure out
>how instructions could be scheduled along the different paths and
>replicated, sorting out the hazards...I suppose you could call it something
>like "trace scheduling"...Bob Colwell, you there?  I see a customer for
>your technology!:-):-):-)

We discussed this problem in our IEEE Transactions paper, and Ellis 
also goes over it in his thesis.  When you compact a lot of different
instructions into a wide-word instruction, in a sense, you drag their
branches in too.  So it helps to have your branching abilities scale
with the number of functional units you're keeping busy.  Of course,
lots of other things, such as the number of memory ports you can 
keep busy at once, the number of register read/write ports plus the
number of registers, and the instruction stream bandwidth also need
to scale with the number of functional units if you are trying to 
create a balanced architecture.

Bob Colwell               ..!uunet!mfci!colwell
Multiflow Computer     or colwell@multiflow.com
31 Business Park Dr.
Branford, CT 06405     203-488-6090