Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!lll-lcc!pyramid!prls!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: comp.arch
Subject: Re: C machine
Message-ID: <1061@winchester.UUCP>
Date: Sat, 5-Dec-87 23:35:12 EST
Article-I.D.: winchest.1061
Posted: Sat Dec  5 23:35:12 1987
Date-Received: Thu, 10-Dec-87 23:23:00 EST
References: <759@auscso.UUCP>
Reply-To: mash@winchester.UUCP (John Mashey)
Distribution: na
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 71
Keywords: C, Lilith (sp?), In Progress?

In article <759@auscso.UUCP> stevem@auscso.UUCP (Steven G. Madere) writes:
>A year or so ago I read about a machine called the Lilith (sp?) that
>was developed in Switzerland.  From what I read it seemed that this
>machine had been developed with Modula 2 applications in mind....

>If this is true, I would like to know if anyone out there is working
>on a similar machine designed to work more efficiently with C programs....

>If there are problems inherint in the design of C that make such a machine
>impossible I would like to know what these are.  If there are no such
>problems then why in the world haven't I heard about it?  I read all of 
>the UNIX literature I can get my hands on and it seems that someone would
>have noticed the potential of such a machine by now.

What does it mean to develop a machine that works efficiently with C?
It means using the statistics of real C-compiler generated code,
and real C programs to help drive the design of the architecture.

At least the following, to some extent or other, were so done (with
recent references, which have many references to earlier work).
(Others are invited to post references).
*'d machines are commercially available today.

Bell Labs "C" machines and CRISP
	Ditzel, McLellan, and Berenbaum, "Design Tradeoffs to Support
	the C PRogramming Language in the CRISP Microprocessor",
	Proc ASPLOS II, ACM SIGARCH 15, 5 (Oct 87) 158-163.

*HP Precision
	Magenheimer, Peters, Pettis, Zuras, "Integer Multiplication and
	Division on the HP Precision Architecture.", Proc ASPLOS II, 90-99.

*MIPS R2000
	Chow, Correll, Himelstein, Killian, Weber, "How Many Addressing
	Modes Are Enough?", Proc. ASPLOS II, 117-121.

*Sun SPARC (via some heritage from Berkeley RISC, at least)
	I don't have an immediate reference to a published paper
	that has statistical analyses: maybe someone from Sun can point at one.)

I'm sure there are more, but at least these machines or their predecessors
had considerable modeling work designed to make C good on them.

Now, the more serious issue is whether or not it's a good idea to build
a UNIX machine that's optimized ONLY for C, or in fact for any single
language in particular.  Contrary to popular belief, many UNIX machines
run FORTRAN also, or even (gasp!) COBOL, BASIC, PL/I, ADA, LISP, Prolog, Modula,
etc.  Whether or not you care about these things depends on what markets you
think you're in.  For many of them [RISC bias on], you do fine if you just
make sure loads, stores, branches, and function calls go fast.  For others,
you may have to do more work. [RISC bias off]

Of the machines above, as far as I can tell [originators, please correct me
if I'm wrong], tunings were mostly driven as follows:

C machine & CRISP: C

HP Precision: C, COBOL (there are 1-2 instructions that help
decimal arithmetic in an appropriate RISC fashion); FORTRAN

MIPS R2000: C+FORTRAN, PASCAL; not particularly COBOL, but turns out OK.

SPARC: C, LISP.

In general, unless botched badly, most reasonably modern (CISC or RISC)
designs are at least reasonable for running C.
-- 
-john mashey	DISCLAIMER: 
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086