Path: utzoo!mnetor!uunet!hsi!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: Survey of architectures was (Re: Proposed architecture characterization)
Message-ID: <366@m3.mfci.UUCP>
Date: 26 Apr 88 03:14:46 GMT
References: <29220@amdahl.uts.amdahl.com> <1988Apr22.095544.86@mntgfx.mentor.com>
Reply-To: colwell@m3.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 55

In article <1988Apr22.095544.86@mntgfx.mentor.com> mbutts@mntgfx.mentor.com (Mike Butts) writes:
>From article <29220@amdahl.uts.amdahl.com>, by esf00@amdahl.uts.amdahl.com (Elliott S. Frank):
>> In article <7657@ames.arpa> eugene@pioneer.UUCP (Eugene N. Miya) writes:
>>>This form raises an interesting question.
>> reacted to over the last twenty years or so.  I've probably slighted
>> the VLIW and parallel crowd, but I haven't [yet] seen a lot of
>> impact on other architecture that's come out of their research.  Machines,
>> yes.  Architectural principles, no.
>> 

Just wait.  When the RISC micro designers finally achieve their goal
of one op/instr, the logical next step is multiple ops/instr.  If you
want to control those ops, you need instruction bits...we call that a
VLIW.

>Allow me to add:
>
>* DG Nova -- arguably an early (circa 1970) and quite popular RISC, which is a 
>    direct descendant of...
>
>* PDP-8 -- extremely RISC.  Just as the minimality of today's RISCs allow chip-
>    level implementation, so did PDP-8's minimality allow rack-level 
>    implementation in its day (25 years ago.)

I thought nobody still defined their RISCs by the number of
instructions.  Given that Multiflow's TRACE can have up to 2**1024
instructions, I guess you wouldn't consider our machine to be a RISC.
But I can make a strong case for that, I think.

The minimality of today's RISCs doesn't "allow chip-level
implementation"; there are people in the world designing VAXes with
the same technology, and 68xxx's, and 80?86's.  RISC proponents claim
two important things:  faster time-to-market, and higher performance
when it gets there.  Not feasibility per se.

>* FPS-164 -- original (1981) VLIW mini-super (it's **not** an array processor)

OK, it's an *attached* processor.  Either way, it's not a VLIW and it's
not a mini-super.  For all its interesting features, such as
fine-grained parallelism at the hardware microcode level, neither the
FPS-164 nor the AP120B supported virtual memory.  And they couldn't
do their own I/O.  And they weren't designed to be the targets of
highly optimizing compilers.  Call them forerunners of the parallel
uniprocessors of today; looking back on them, one can pick out design
directions they could have taken that might have made it easier for
today's programming environment.  But the name VLIW was coined by the
people who invented them, and it encompasses too many other things
that the FPS machines don't.

>Mike Butts, Research Engineer         KC7IT           503-626-1302

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