Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!stevew
From: stevew@wyse.wyse.com (Steve Wilson xttemp dept303)
Newsgroups: comp.arch
Subject: Re: How to use silicon (was Re: Intel/MIPS Dhrystone ratio)
Message-ID: <2163@wyse.wyse.com>
Date: 21 Mar 89 21:02:34 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <16058@cup.portal.com>
Sender: news@wyse.wyse.com
Reply-To: stevew@wyse.UUCP (Steve Wilson xttemp dept303)
Organization: Wyse Technology
Lines: 23

In article <16058@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>I claim a much better use of multiple functional units is to execute many
>"small" RISC instructions at the same time, i.e., "super scalar" or
>multiple instructions per clock.  It just doesn't make sense to bundle,
>bind is a better word, many operations into one instruction.  Doing so
>simply thwarts compiler optimization.  Adresssing modes are probably the
>worst form of semantic binding, in my opinion.  So, if we are going to
>have "too many transistors," we should use them to realize a superscalar
>*implementation*, not a complex *architecture.*

If anything, VLIW is more RISCy than RISC in the sense that it exposes
all of the functional units' pipelines to the compiler.  You just can't
say VLIW in the same sentence with "simply thwarts compiler optimization."
Your denying the basis of why to go to VLIW in the first place.  The compiler
has the option to "optimize" along a straight line code just like you suggest,
or, in the inner most loop of an application you can have multiple 
instances of the same loop running simulataneously.  All due to the compiler!
If anything, you've got more opportunity for compiler optimizations, not
less.

Steve Wilson

The above opinions are mine, not those of my employer.