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