[net.arch] RISC/CISC/microcode: personal experience

skef@cmu-cs-spice.ARPA (Skef Wholey) (06/23/85)

The Xerox Alto and its descendents (Dolphin, Dandelion, Dorado, etc.) support
multiple instructon sets (BCPL, Mesa, Smalltalk, InterLisp), although I don't
believe one can run several instruction sets concurrently on these machines.

The Perq (made by Perq Systems Corporation) is architecturally similar to the
low-end D-Machines (the Dolphin and Dandelion), but has 16K words of writable
control store instead of 4K that the D-Machines have.  At CMU we've managed to
cram three instruction sets and microcode support for critical OS functions
into that 16K.

    From doug@terak.UUCP (Doug Pardee) Fri Jun 21 19:36:28 1985

    > A reasonable approach to producing CISC machines ... to have the 
    > instruction set be changeable for different languages.  

    If the machine is going to do multi-programming, it's going to need
    bank-switched micro-instruction memory or the like.

The Accent operating system, written at CMU as part of the SPICE and DSN
projects, supports both multiple resident instruction sets and microcode
overlays (process context has the "current" micro-pc and an overlay
identifier, if necessary).  Currently one instruction set, QCodes, is used for
Pascal, C, and Ada, and another nameless instruction set is used for Common
Lisp.  All these are resident, except for some Pascal set-manipulation
instructions, which are overlayed.

    From mjl@ritcv.UUCP (Mike Lutz) Fri Jun 21 21:30:12 1985

    The biggest problem, as Henry noted, was the inability to create a
    program using routines written in different languages.  I know our
    group did some preliminary research on this issue, but we dropped it
    when other more exciting projects came along.

Accent is a message-based operating system.  In addition to providing network
resources in a transparent fashion, this lets programs written in other
languages to communicate in a common message-passing "language."  Of course,
the message passing and context switch overhead makes this way of
communicating more expensive than a procedure call, but by communicating with
farily large pieces of data, this overhead can become negligible.

The QCode instruction set is an extended version of the UCSD P-Code
instruction set.  It it bascially a stack machine, and as such makes the life
of the Pascal and Ada compilers somewhat easier.  The C compiler is based on
the Portable C Compiler, which knows something about registers, so it had to
be lobotomized to deal with the stack machine model.  The Lisp instruction set
is also a stack machine, more or less.  Recently, register instructions were
added to both instruction sets to boost performance, but since most of the
compilers were not written with a register model in mind, they are not used
optimally.

I am currently in the process of bringing up a new C for the Perq based on an
instruction set I developed called MCodes (for "My Codes").  Mcodes are very
similar to RISC instructions.  Most of my work has been hacking on the
Portable C Compiler and writing an optimizing assembler so that the RISC
instructions are utilized effectively.  Benchmarks indicate that MCode C will
run approximately twice as fast as QCode C.

The Perq micromachine was designed to interpret QCodes, and has some strange
features and flaws that make other instruction sets more difficult to
implement, but a RISC instruction set still comes out ahead.  I believe the
added performance comes about because of the combination of a smarter compiler
and a simpler instruction set.

CISC's like the Vax and 32032 can make a compiler-writer's life easier, but
there will usually be some runtime penalty for taking the easy way out.  The
ability to do memory-to-memory operations eliminates the need to load and
store registers, but operands that are accessed frequently should be in
registers anyway.  Writing a compiler for a RISC brings that issue to the
foreground.

    From henry@utzoo.UUCP (Henry Spencer) Thu Jun 20 13:48:52 1985

    Speaking from only the vaguest memories, RPG and friends are well-suited
    to microcode implementations:  a small set of relatively high-level
    primitives.  Snobol would probably be another favorable case.  But when
    the language primitives get low-level (C, Pascal, Ada) so that one does
    not get as much mileage out of mapping lots of ordinary-machine
    instructions into one customized-machine instruction, then things fall
    down badly.

Exactly.  The Perq does relatively well compared to a Vax for Lisp, but not
nearly as well for C (benchmark figures are backed-up by user testaments here
-- people using Lisp usually prefer the Perq to the Vax, but QCode C users
have the opposite preference).  The Xerox and Lisp Machine folks are still
getting good mileage out of very complicated instruction sets.  When
type-checked RISC's come along, then Lisp and Smalltalk users will be able to
get high performance from non-microcoded machines.  The future of
general-purpose personal machines is probably with fixed-instruction-set
microprocessors, be they RISC or CISC.

--Skef
-- 
uucp: ...!seismo!cmu-cs-spice!skef
arpa: skef@CMU-CS-Spice