Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!hplabs!hao!nbires!opus!rcd
From: rcd@opus.UUCP (Dick Dunn)
Newsgroups: net.arch
Subject: Re: time for a RISCy bus
Message-ID: <1056@opus.UUCP>
Date: Tue, 29-Jan-85 03:32:12 EST
Article-I.D.: opus.1056
Posted: Tue Jan 29 03:32:12 1985
Date-Received: Sat, 2-Feb-85 00:46:41 EST
References: <4940@utzoo.UUCP>
Organization: NBI,Inc, Boulder CO
Lines: 36

> Of late, we have seen announcements of the VME bus, the Multibus II,
> the IEEE whatever-it's-called-this-week bus, the TI Nu-bus, and maybe
> one or two that I've missed.  While all these bus schemes do have
> interesting characteristics, there is one disturbing problem that they
> all share:
> 
> Every last one of them is appallingly complex.

I'll agree that they seem complex, but I can't see the same level of
complexity as I see in the definition of a processor like the VAX.  I was
able to muddle through the VME bus spec in a few hours and get a good
enough understanding (for a software type) that I knew where everything was
and could find answers to questions with little trouble.  I suspect that if
I started to gain the same level of understanding of the VAX, it would take
several days starting from scratch.  My point is that, although a simple
bus would be a good idea, it's just not as big or urgent a problem.

> It is high time somebody did for bus structures what the RISC has done
> for machine architecture:  provided a simple, high-performance alternative
> to the convoluted, baroque "mainstream" approach.  Preferably before
> we need a forklift to carry a bus spec -- a day that is fast approaching.
> Anybody got any bright ideas?

One characteristic to keep in mind is that RISC architecture tosses out a
certain amount of "how things were done" and there's a certain loss in
compatibility of sorts.  We may have to accept the same sort of thing with
a reduced bus.  For example, study the VME spec and ask yourself, "how much
of this junk could we toss out if we could assume one size for the
instruction and data paths?"  VME handles 8/16/32 bit data transfers and
16/24/32 bit addresses.  I'm not knocking the idea.  Who knows--it might be
more cost-effective overall to build all your cards with a 32-bit interface
and eliminate the signals and logic that it takes now for smart cards to
deal with dumb ones.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Never offend with style when you can offend with substance.