Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!apple!portal!cup.portal.com!mmm
From: mmm@cup.portal.com (Mark Robert Thorson)
Newsgroups: comp.arch
Subject: Re: What's in the '586?
Message-ID: <42573@cup.portal.com>
Date: 22 May 91 03:49:50 GMT
References: <1991May14.002130.4740@vax5.cit.cornell.edu>
  <8840035@hpfcso.FC.HP.COM>
Organization: The Portal System (TM)
Lines: 43

mjs@hpfcso.FC.HP.COM (Marc Sabatella) says:
 
> Hopefully, a Motorola "spokesman" will shortly produce an equally amusing
> summary of the 68050.

The design of the 68050, at least a few months ago when I left that group
(flunked the piss test), has four on-chip execution units for
executing more than one instruction per clock cycle.  This architecture
will be the first superscalar CISC processor, hence its nickname "ROTC"
(i.e. "Revenge of the CISC's").
 
The goal of superscalar execution might seem to be in conflict with
our two major design constraints:  binary compatibility with earlier
680x0 processors, and expansion of the instruction set to include
graphics primitives required by a certain major personal computer manufacturer.
 
The goal and the constraints were satisfied through a novel architecture,
in which the microcode memory is moved off-chip, into the general address
space.  This doesn't hurt performance, because each of the four execution
units is equipped with an on-chip microcode cache, in addition to a ROM
implementing a RISC-like subset of the family instruction set.

With the microcode in memory, the instruction decoder can also be
eliminated from the chip.  In fact, it has been replaced with a pseudo-
Huffman decoder.  A binary program in the 680x0 instruction set is
compiled into microcode, then Huffman-coded;  these two steps occur
in software.  The chip then executes the program by pulling appropriate
parts through the hardware Huffman decoder, and loading them into the
appropriate on-chip cache(s).

Because microcode programs tend to be rather small programs, and because
formal proofs of program correctness can only be applied to small programs,
and because we felt that our instruction-execution programs are the most
critical programs to get correct, it was decided that all microcode would
be formally verified.  (This line of reasoning was suggested by a Berkeley
professor who clearly had our best interests at heart.)

A few of us voiced objections to this plan, favoring instead the "quick
and dirty" approach of using test suites composed from the large body
of existing 680x0 code.  I guess our point of view was the result of
brain damage, however, because when the random drug tests came back
we were all dismissed--leaving the "clean and sober" group to plow
ahead with their more arduous plan.  :-)