Speculation on Intel CPU's and Floating-Point Standards

[David G. Hough on validgh]

     Recent issues of Slater's Microprocessor Report have mentioned some
rumors about the shape of the unannounced Intel 586.  I'd quote the Report but
somebody ripped off the relevant issue from my bulletin board at work.  Basi-
cally it's something like this:

     The 586 will have a RISC core plus sufficient support to efficiently exe-
     cute the x86 instruction set (x <= 4).

     This suggests that the 586 will be able to obtain good performance on
existing x86 programs and RISC-like performance by using the RISC core
directly.   The Report says Intel is projecting 70 SPECmarks at 66 MHz, which
is about as good as a Snake.

     If all this is true, or even mostly true, it suggests that there might
not be a lot of need for other instruction sets in the future, because they
will be able to add so little value for most users - hence will achieve rela-
tively small installed bases - hence will not be able to fund the technology
development at comparable rates and hence will tend to fall further behind.
Even if it's mostly wrong for the 586, it might be true for the 686.  I'll
suppose that it's true for some future generation that could be called the
r86, r to be determined.

     The x86/MSDOS/Windows installed base has up to now basically lacked two
things - RISC performance and the Macintosh user interface, for which the i486
and Windows are still said to be poor substitutes.   If RISC performance is
attained, then all that's needed is a way to attack Mac users.  The long term
expensive but no-hassle way is to pry ROMs out of old discarded Macs; the
short term expensive way is to reverse engineer the ROMs in software and
attack the user interface copyright; Intel has lots of lawyers who can argue
either side of any question with ease, I suppose.

     Anyway assume you have two instruction sets, a CISC and a RISC.  They
differ in op codes and in data types, in general.   Actually the data type
problems are more refractory in practice: byte order and alignment issues in
particular.   Of course from my perspective floating-point issues are impor-
tant too: is there 80-bit extended or 128-bit quad or neither?  It would be a
nuisance if "long double" meant something different in each system.

     But one way or another you can design compilers with two options: one to
choose whether to issue CISC or RISC instructions, another to choose whether
to align data according to CISC or RISC requirements (CISC usually means
structures are smaller but slower to access in a RISC system).

     Then you can imagine a range of products like this:

very low end PC's
     x86 CPU's with a new operating system that emulated RISC instructions in
     supervisor software - no different from the way most x86 CPU's handle the
     missing floating-point coprocessor.   RISC-op-compiled codes would be
     pretty slow.

low end PC's
     r86 CPU's that can run either RISC-op or CISC-op compiled codes effi-
     ciently.

high end PC's
     A CISC-only CPU and a RISC-only CPU could be used instead of an r86 with
     a fast clock and a big cache, if that offered better performance, but
     that envisions an operating system that would assign processes to proces-
     sors depending on their flavor.

mainframes
     A very-high-performance RISC-only CPU, implemented in GaAs or whatever
     else Seymour Cray is using these days, could still emulate the CISC
     instructions pretty fast in the supervisor, although that would be more
     for the convenience of the customers and for marketing points than to
     solve any real need.

     It's appropriate to observe that all of the foregoing could apply to any
two CPU architectures - it's only a matter of cost and performance.  But if
you want compatibility with the current mass market installed base, one archi-
tecture had better be x86, and if you want competitive performance, the second
architecture had better be a RISC, and if you want efficient compatibility
with existing databases, the RISC better have the same datatypes and byte
order and efficient access according to CISC alignment rules, though it may be
even more efficient with databases created with RISC alignment rules, and if
you want the low end to be competitive, it should be convenient to package
this CISC and RISC in one chip that can be produced at mass-market prices.

     The foregoing constraints can be more readily solved if mixed-mode
processes are disallowed, i.e. the entire executable must be either all-RISC
or all-CISC.   But think of the advantages if there's a technical solution to
the more aggressive target: allowing mixed RISC and CISC code in one execut-
able, but only one flavor per compiled module. Then for many applications
whose performance limitations are in standard system libraries, one executable
could be dynamically linked to work on every system from the very low end to
the mainframe with close to optimal performance on each.    I don't know if
the x86 op code map has sufficient holes to permit such mixing, nor do I know
enough about x86 calling sequence conventions to know if they'd work for cal-
ling from CISC code to RISC code.

     It is surely true that any amount of CISC compatibility will limit per-
formance of a RISC design relative to a pure RISC design, other things being
equal, but other things are not equal.   Otherwise Lisp Machines would still
be in business making dedicated Lisp processors.   The other thing that wasn't
equal in their case was that the general-purpose RISC market was large enough
to drive technology faster than the special-purpose Lisp market.

     Given the foregoing considerations, if Intel were to deliver RISC perfor-
mance with good forward and backward CISC compatibility at a price that made
new CISC-only or RISC-only designs uninteresting at least for the mass market,
why would ISV's be interested in writing software for any other architecture?
Then why would anybody buy any other kind of computer - except possibly for
the usual small gang that write their own software and will pay any price to
run it as fast as possible.   Their business is significant in dollars but not
in installed base.

     It seems to me that by defining uniform expression evaluation and
floating-point semantics that can be more or less efficiently implemented on
both sides, Intel could eliminate the need for standards groups to consider
these issues - as NCEG is doing - in favor of the installed base defining the
standard as fait accompli.   I hope it's not too much like the 860!

     All the foregoing might be good or bad in its total effect on the econ-
omy, but it's definitely unsettling to me and perhaps to others who have
invested effort in other RISC architectures that chose the other byte order
(as I recall SPARC wanted to be compatible with Sun's then-current MC68010 and
future 68020/68881 installed base).  On the other hand there are some consol-
ing thoughts:

     Intel engineering has never shown much understanding of software issues
     when designing hardware such as the 860.

     Intel marketing has never shown much interest in strategic rather than
     tactical advantage, so I'd expect them to do things like making the RISC
     part optional, or the CISC part optional, or pricing the r86 as high as
     possible, all in order to maximize current revenues at the expense of
     missing an opportunity to seriously impede all the competition long term.

     Intel's management's bonuses are presumably based on current-year return
     on assets or stock price, like everybody else in the US, although not in
     Japan.

     Intel legal might eventually suffer a reversal if some court decides that
     reverse-engineering the x86/7 is OK.

     r86 yields might be too low to sustain mass production, or they may never
     get all the bugs out - high performance x86 is complex enough without all
     the RISC stuff as well.

     There might be specific technical problems with the x86 instruction set
     architecture that will keep an r86 from ever being competitive in perfor-
     mance with pure RISCs, regardless of technology.

     There might be some specific technical advantage that one of the newer
     Intel byte-order RISCs such as R4000 or ALPHA can bring to bear in order
     to either emulate the x86 efficiently in software or incorporate hardware
     assists for emulation if not a complete x86 instruction and register set.
     As long as these processors can keep r86 from a decisive victory, all the
     other RISCs can continue to justify their development in hopes of discov-
     ering a decisive advantage later on.