Path: utzoo!mnetor!uunet!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: Performance increase - a suggestion
Message-ID: <231@m2.mfci.UUCP>
Date: 3 Feb 88 13:49:50 GMT
References: <235@unicom.UUCP> <28200088@ccvaxa> <3536@batcomputer.tn.cornell.edu>
Reply-To: colwell@m6.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford, CT. 06405
Lines: 25
Keywords: VLIW

In article <3536@batcomputer.tn.cornell.edu> kahn@tcgould.tn.cornell.edu (Shahin Kahn) writes:
>>Another approach is to execute all of the instructions come what may.
>>This is the VLIW, trace-scheduling, approach commercialized by Multiflow.
>>
>>Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
>>    aglew@gould.com     	- preferred, if you have nameserver
>
>VLIW has been part of Floating Point Systems' machines for more than 
>10 years.

Under that definition of VLIW, every microcoded machine ever made
qualifies.  It's never been that big a trick to make a machine with
many parallel functional units.  The trick is to be able to keep them
busy without hand coding, and to provide the right interface so that
the compiler can express the parallelism that it finds.

Read Ellis' thesis;  he presents reasonable arguments as to why FPS'
architectures have hot spots that make it a very difficult target
for a compiler.


Bob Colwell
Multiflow Computer  <Above is personal opinion only!!>
175 N. Main St.
Branford CT 06405    mfci!colwell@uunet.uucp  203-488-6090