Path: utzoo!mnetor!uunet!mcvax!unido!mucmot!ron
From: ron@mucmot.UUCP (Ron Voss)
Newsgroups: comp.arch
Subject: Re: RISC  a short answer??
Message-ID: <310@mucmot.UUCP>
Date: 5 May 88 13:31:50 GMT
References: <1036@nusdhub.UUCP> <21149@pyramid.pyramid.com> <307@mucmot.UUCP> <381@m3.mfci.UUCP>
Organization: Motorola GmbH Microsystems Munich
Lines: 61
Summary: Another definition

From article <381@m3.mfci.UUCP>, by root@mfci.UUCP (SuperUser):
> In article <307@mucmot.UUCP> ron@mucmot.UUCP (Ron Voss) writes:
> =From article <21149@pyramid.pyramid.com=, by csg@pyramid.pyramid.com
> =(Carl S. Gutekunst):
> == In article <1036@nusdhub.UUCP= rwhite@nusdhub.UUCP (Robert C. White Jr.)
> == writes:
> ===Can someone give me [short answer style] a description of what "RISC"
> ===means.
> == 	[see earlier article for Carl's response]
> =[see earlier article for my response]
> 
> But let's not get too provincial.  What lessons there are to learn
> from RISC apply to more than just one-chip processors, and it isn't
> obvious how to extend your "finite chip real estate" metric to
> board-level machine design.  And watch out for something else.  A
> processor running a general UNIX/university job mix is going to look
> a lot different than a scientific computer, which spends a lot more
> of its time doing fairly complex operations (floating point ops).
> The key is to 1) keep what you absolutely need; 2) include things you
> can prove will help performance; 3) move whatever you can to
> compile-time.  And no matter what you design, by all means call it a
> RISC (mega-smiley here).
> 
> Bob Colwell            mfci!colwell@uunet.uucp
> Multiflow Computer
> 175 N. Main St.
> Branford, CT 06405     203-488-6090

Well said.  I offer an even shorter answer to Robert's (not Bob's) original
question:
    1.  Instructions all the same length.
    2.  Instructions execute in one cycle.
    3.  Instructions are not microcoded.
                           (adapted from Motorola's 88000 press release)
As to Bob's points, Motorola has tried to solve the board-level machine
design problem by providing a compatible chip set, which includes a
physical cache with bus snooping.  The design is general-purpose (ala UNIX)
as opposed to scientific, but floating add and multiply have been included.
As to the above-mentioned keys:
    1)  Integer, bit, and floating +* have been kept.
    2)  11-way pipelined instruction execution, cache as above,
        Harvard parallel architecture.
    3)  Compilers continue to get smarter.
Making a profit means designing for the best price/performance ratio,
which indirectly translates to number of units sold, which indirectly
translates to satisfied customers (is my order reversed?).
The marketplace will determine if Motorola has done a good job.
Caveat my affiliation.

------------------------------------------------------------
Ron Voss                Motorola Microsystems Europe, Munich
mcvax!unido!mucmot!ron                         CIS 73647,752
my opinions are just that, and not necessarily my employer's
------------------------------------------------------------

-- 
------------------------------------------------------------
Ron Voss                Motorola Microsystems Europe, Munich
mcvax!unido!mucmot!ron                         CIS 73647,752
my opinions are just that, and not necessarily my employer's
------------------------------------------------------------