Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!amdcad!sono!miklg
From: miklg@sono.uucp (Michael Goldman )
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <1991Apr16.192516.4747@sono.uucp>
Date: 16 Apr 91 19:25:16 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> <1991Apr12.001324.5@ux1.cso.uiuc.edu>
Organization: Acuson; Mountain View, California
Lines: 42

msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes:

>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.

Actually, as I follow the 68020 to the 68030 to the 68040 I find a number
of deleted instructions as well as added insrtuctions at each move.  The
added instructions are either essential (MMU support) or not (BKPT).
The deleted instructions are of the same nature.  That this requires
rewriting code is just one of those things you're supposed to put up
with to maintain application compatibility.  The 680x0 doesn't have a
lot of really complex instructions like the 80x86 family.  The string
handling instructions of the 80x86 come to mind as something best
implemented as library functions.  The context switching instructions
of the 80286 are sufficiently involved as to be part of a large function.

I think one of the problems with the incredibly complex instructions
for OS stuff in the 80286 and beyond, is that you may not WANT to 
implement your OS the way they designed the instruction.  Another
problem is that it takes learning about the instruction set that
much harder and longer.  This results in delays in implementation and
bugs.  Then, also, as pointed out above, you've got compatibility issues
if you actually wrote your OS around their specific hardware concept
of how context switching, should be done.