Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!yale!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: Proposed architecture characterization survey form
Message-ID: <355@m3.mfci.UUCP>
Date: 21 Apr 88 12:21:14 GMT
References: <2048@gumby.mips.COM> <50070@sun.uucp> <2052@gumby.mips.COM> <50217@sun.uucp>
Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 45

In article <50217@sun.uucp> dre%ember@Sun.COM (David Emberson) writes:
>
>
>I vaguely remember hearing someone about ten years ago give a talk on the
>subject of architecture comparison.  Unfortunately I do not remember who it
>was, but they defined two measures of an architecture, R and S.  The R measure
>was a metric of the number of register references and the S measure was a
>metric of the number of memory references (storage) in a given piece of code.
>Presumably a high R/S is desirable, although this is far from certain in the
>presence of write-back caches.  In any case, these indicators are independent
>of implementation technology.  It would be nice if we could develop some such
>set of metrics which would allow architectures to be compared for efficiency
>and ease of implementation.  I haven't a clue as to how to measure something
>for ease of implementation--I'll leave that to some enterprising person.  I am
>in full agreement with your statement that implementations are the most
>interesting.  We can get real numbers from them and identify real areas for
>improvement.
>			Dave Emberson
>			(dre@sun.com)

I bet you're remembering the Military Computer Family work of the
mid-to-late '70s done at Carnegie-Mellon.  R was the "canonical
processor cycles" for a benchmark; S was the program size, and M was
the memory bus traffic.  In our "Computers, Complexity, and
Controversy" paper in Computer magazine Sept. 1985 we applied this
evaluation method to Berkeley's RISC-II, mostly as an intellectual
exercise, but partly to show that the field had already outgrown this
kind of approach to architectural evaluation.  My feeling was that
the fundamental problem was that MCF was extremely careful to
separate implementation from architecture, and RISC is quite willing
to mix the two freely (trading object code compatibility across
products in a company's product line (Sun-4/Sun-3) for the added
performance available when you can max-out a given set of
implementation constraints.

It's probably easier to gauge "difficult-of-implementation" than
"ease"; if, in a blindfold test, you gave me the VAX instruction set
and RISC-I's, I'd have no problem picking the one I'd find easier to
implement, and I'd have a list of reasons why.  But of course, then
you'd want to quantify how much easier, and that's a good question.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090