Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!j.cc.purdue.edu!pur-ee!hankd
From: hankd@pur-ee.UUCP (Hank Dietz)
Newsgroups: comp.sys.apple
Subject: Re: ROMable High Level Languages
Summary: The importance of highly malleable toy compilers
Keywords: ROMable code, porting/retargeting
Message-ID: <10970@pur-ee.UUCP>
Date: 13 Mar 89 17:39:33 GMT
References: <8902152259.AA04690@wpi> <500@madnix.UUCP> <39027@tut.cis.ohio-state.edu>
Reply-To: hankd@pur-ee.UUCP (Hank Dietz)
Distribution: usa
Organization: Purdue University Engineering Computer Network
Lines: 41


As an optimizing/parallelizing compiler researcher, I have designed and
written many small prototype compilers, and I think the level of Ron Cain's
Small C (as it appeared long ago in Dr. Dobbs) is very useful both for
checking-out nasty experimental compiler analysis/transformations and for
generating ROMable code for the many wimpy microprocessors/microcontrollers
used in embedded systems.  In general, I am talking about "C programs
without printf, etc." -- C code for a bare machine.

Small C is not a large subset of C, but it is quite workable and the compiler
is completely self-contained (even self-compiling) and easy to understand
(hence easy to modify, although the implementation is somewhat kludgey).
The code it generates is dumb, but not grossly inefficient; the way it
manages locals and the stack happens to work really well, except for the
fact that it allocates stack space one variable at a time (easy to fix).
The stack allocation of temporaries makes it very easy to make Small C
handle a machine with general registers by simply treating the registers as
a "stack cache" -- a lousy way to allocate registers, but it does work.

I guess I've now got about 20 different mutations of Small C for various
different machines ranging from processors for a few proposed parallel
supercomputers all the way down to lowly TI7000 series machines.  Given a
working assembler and reasonable understanding of the machine, mean time to
target for a new machine is about 2 days.  I also have an assembler I wrote
long ago specifically as a target for such "toy" C compilers, ASA (the
ASsembler Adaptable), which takes a mean of about 1 week to target for a new
machine.

Some of you might ask "why not use Gnu CC?"  However, Gnu CC is *BIG*.  The
time taken for a person to learn the internal structure of Gnu CC seems to be
on the order of a couple of months and even then the program is too large and
complex to be ported quickly...  especially to small machines.  The ideal is
to have a reasonable subset language compiler that is small, self-contained,
and can be subsetted or extended easily....  Gnu CC ain't it, there may be a
better choice soon, but for now, Small C is probably the best bet.

						-hankd@ee.ecn.purdue.edu

PS: An interesting side note is that one could fairly easily bootstrap GCC
    by making a version of GCC generate Small C code....  Efficient?  Heck
    no, but easy...  and it can be incrementally improved.