Newsgroups: comp.sys.mips
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!csn!boulder!news!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Subject: Re: MIPS code generator
In-Reply-To: murphy@mips.com's message of 7 Jun 91 22:33:29 GMT
Message-ID: <1991Jun10.173004.18730@colorado.edu>
Sender: news@colorado.edu (The Daily Planet)
Nntp-Posting-Host: foobar.colorado.edu
Reply-To: grunwald@foobar.colorado.edu
Organization: University of Colorado at Boulder
References: <33839@shamash.cdc.com> <12503@scolex.sco.COM> <4460@spim.mips.COM>
Date: Mon, 10 Jun 1991 17:30:04 GMT
Lines: 18


The other alternative is to tell them to target their compiler to
generate 'C' output. This way, they can use e.g., the MIPS code
generator or the new DEC RISC C compiler as well. Obviously, it will
be slower, but they can probably ignore most of the optimization
issues entirely, passing those onto the backend. They'd still have to
do non-C-ish things themselves, like inter-procedural optimization.

I use several `compilers' (Scheme->C, Fortran->C, Pascal->C,
Modula3->C) that do this, and they're generally easier to retarget and
not really all that much slower (since the front-end can ignore
optimization, which is the slow part). Not to mention that your
customers time-to-market would be cut a lot, it doesn't involve any
licenses and you can target a broader market quicker.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@cs.colorado.edu)