Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: [really CISC] (no, really, the AMD 29k claims)
Message-ID: <767@apple.UUCP>
Date: Thu, 14-May-87 18:31:50 EDT
Article-I.D.: apple.767
Posted: Thu May 14 18:31:50 1987
Date-Received: Sat, 16-May-87 14:11:37 EDT
References: <3810030@nucsrl.UUCP> <491@necis.UUCP> <3530@spool.WISC.EDU> <16658@amdcad.AMD.COM> <388@dumbo.UUCP>
Reply-To: bcase@apple.UUCP (Brian Case)
Distribution: world
Organization: Apple Computer Inc., Cupertino, USA
Lines: 47

In article <388@dumbo.UUCP> hansen@mips.UUCP (Craig Hansen) writes:
>instructions).  The branches that terminate these basic blocks are taken
>more than 50% of the time, so I don't see how a branch target cache performs
>comparably to an instruction cache, in a real system environment.

it can perform comparably because, logically, part of the instruction cache
is in the external rams.  the branch target cache is only there to cover the
latency of the initial access in that external ram (how many times do we
have to say this?).  so, in essence, the Am29000 branch target cache can
cache 32 loops of *any* size.  this is most certainly not true of traditional
instruction caches.  on the other hand, this is not necessarily a very
important attribute; the point is that a branch target cache can perform,
and in fact does perform, as well as an instruction cache.  i feel that it
should be i (or someone defending the am29000) who should be asking *you*
to defend a traditional instruction cache relative to the branch target
cache (always assuming an external burst mode memory for the branch target
cache, of course.  the burst mode memory is a critical part of the concept.).

>I guess the AMD folks are excited about their new child, but when reality
>sets in, and you try to build a real UNIX-based computer system out of this
>fine controller part, you'll be sorely disappointed if you expected 17 MIPS
>at 25 MHz with a nibble-mode DRAM as your primary memory system.  Based on

*not* nibble-mode, video dram; there is a big difference.

>their benchmarks (puzzle, dhrystone, and a tiny piece of linpack; sorry, but
>that's all they've got to compare with...) with an external cache, external
>cache control hardware, and a fast main memory system, a 29000 at 25 MHz that
>you can build next year doesn't perform any faster than a MIPS R2000 system
>at 16.7 MHz that you can build now.

i will be one of the first to say that mipsco has a good part.  you guys have
done a great job in the sense that you have gotten great performance at lower
clock rates.  but what happens to your bus at 25, 30, 35 mhz?  i'm not saying
that you are guys are going to fail to fix things, but let's not be casting
stones!  how do you know that amd will be sorely dissapointed in its
expectations of 17 mips at 25 mhz?  there are accurate simulations to support
just this data!  i am not trying to say you are wrong, but don't just make
the statement, back it up with solid data or at least some observations you
have made about problems with the architecture/implementation!  please,
follow the lead of your co-worker john mashey.

sorry, i know the note i am responding to is old, so if this issue has already
been put to bed, forgive me.  i have been off the net for a while because of
a job change.

    bcase