Path: utzoo!mnetor!uunet!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: Proposed architecture characterization survey form
Message-ID: <354@m3.mfci.UUCP>
Date: 21 Apr 88 02:53:12 GMT
References: <2048@gumby.mips.COM> <49983@sun.uucp> <1468@pt.cs.cmu.edu>
Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 39

In article <1468@pt.cs.cmu.edu> butcher@G.GP.CS.CMU.EDU (Lawrence Butcher) writes:
>When is a RISC not a RISC?  Today I got copies of the 80960KB Programmer's
>and Hardware Designer's reference manuals.  32 AND 64 bit instructions.
>Enthusiastic addressing modes.  Multiple-cycle instructions.  Confused
>call/return instructions.  Decimal data type.  Trig functions in microcode
>instead of manufacturer-sanctioned subroutines.  No delayed branching.
>Zero-cycle branches anyway by making other instructions SO SLOW that the
>branch is finished before the previous instruction is done.  Multiplexed
>address/data bus.  No memory management.  No support for page faults.
>Maximum instruction time 75878 clocks +- 40%. (probably typo :-)

I'll skip this question in the hopes of keeping whatever friends I
still have at Intel...:-)

>This thing seems like a step in the direction of a RISC VLIW.  If things
>like page faults were figured out, and if interrupts could happen without
>causing registers to be overwritten before being used, and if delayed
>branching really wasn't important as claimed, and if the ALU ops were
>simple (only one ALU could multiply or divide), would this instruction
>set really be 2 or more times faster than today's RISCs at the same speed
>for roughly the SAME cost?  Would it be as economical for a conventional
>RISC to fetch 2 instructions at the same time and execute them in parallel
>if there were no data dependency??

I had a fairly sarcastic reply all typed in, but I'll spare
you...Multiflow's TRACE does all of the above, and I think I can make
a much stronger claim for its being a RISC than some of the other
machines listed in the other thread of discussion currently going on
in this newgroup:  load/store, no microcode, simple instructions,
delayed branches, and the ultimate in moving runtime functionality to
compile-time (trace-scheduling!).  We could have an interesting
discussion on what it would take to realize a similar VLIW on a chip,
though -- you need pretty high interconnectivity, and a very wide
instruction cache to tell all the functional units what to do.  

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