Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM RISC
Message-ID: <8163@pt.cs.cmu.edu>
Date: 25 Feb 90 04:38:00 GMT
References: <8064@pt.cs.cmu.edu> <1505@zipeecs.umich.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 25

In article <1505@zipeecs.umich.edu> billms@eecs.umich.edu 
	(Bill Mangione-Smith) writes:

>As many people have said in the past
>(seemingly everyone at ASPLOS III :}, didn't anyone study anything
>else that year?) there isn't much fine-grain parallelism available in
>'UNIX' code.  Thus, gcc doesn't have much parallelism available, and
>if it did, there isn't hardware to support it (because it isn't
>floating point code).

The conclusion I take from the literature, and from ASPLOS III, is
that compilers that _don't_ use trace scheduling, have on the
average found a parallelism of approximately 2-2.5 in integer
programs. 

The IBM can issue one ALU operation, and one comparison, and one
branch, per clock. That's not "ideal": it would be nice if it had,
say, two ALUs. I believe that Intel has promised this for the next
i960.

Which reminds me: the only benchmarks I've seen for the superscalar
i960 were on the order of Dhrystone 1.1. Has anyone got an integer
SPECmark by now?
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science