Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!msp33327
From: msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <1991Apr12.001324.5@ux1.cso.uiuc.edu>
Date: 12 Apr 91 00:13:24 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <1991Apr5.172533.6717@agate.berkeley.edu> <9782@mentor.cc.purdue.edu> <7117@auspex.auspex.com> <1406@ncis.tis.llnl.gov>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 27

In <1406@ncis.tis.llnl.gov> turner@lance.tis.llnl.gov (Michael Turner) writes:

>If implementing them used up space on the chip that would have been
>wasted otherwise, then there has been some good done, and little harm
>but for a possible slight decrease in yield.  I don't know that that's
>the case with the 68020.  From what I'm hearing of the 68040, it even
>seems doubtful.  But that shouldn't get in the way of my point: that
>when you're designing an architecture for single-chip implementation,
>at some point you've got a little left-over real estate to play around
>with.  Maybe you can even (*gasp*) add some instructions.  If this be
>treason, make the most of it, I say.

The problem is that you will have to include those instructions in the
next version of your processor in order to remain binary compatible,
and if things work out differently, as they probably will, they may be
hard to implement.  That happens in microcoded machines: we have some
extra microcode store space, lets add some instructions.  Next
version, you have to work like hell to cram all those instructions in
because things worked out differently, and probably almost no one uses
those instructions anyway.

--


Michael Pereckas               * InterNet: m-pereckas@uiuc.edu *
just another student...          (CI$: 72311,3246)
Jargon Dept.: Decoupled Architecture---sounds like the aftermath of a tornado