Re: porting a compiler to a new architecture

mathai@ecf.toronto.edu wrote:
: Hi,
: I'm designing a RISC CPU for fun, and wanted to know how difficult it
: would be to port a compiler like gcc to generate code (non-optimized is
: fine) for my machine? I'm ignorant of compilers, but can learn .. I'd just
: like to assess how difficult it would be.


Well, not for fun, and not lately, but I did do this
(re-targeted gcc, circa 1.18..1.40, to a RISC I worked on). I
contemplated just emailing, and will understand if the moderator
bounces this, but I thought I'd share my experience, if only to
stimulate more current feedback on the task.


: [One RISC is pretty much like another for a straightforward code generator,
: so I'd think you should be able to get a limping version of lcc in a week
: or two. -John]


Lcc was not an option for me, as at the time it was only
available to academics and people with more money than me. Today, it
seems a good choice, but that's on pretty cursory examination. I
started with PCC (Steve Johnson's original Portable C compiler), but
ANSI C was "just around the corner", and gcc was aiming for it, while
PCC was never going to go there. In partial exception to our
moderator's comment, one RISC may be pretty much like another, but the
devil is in the details, which in my case were unsigned displacements
in reg[disp] instructions, and scaling of those displacments to match
operand size. While it was not impossible, it was danged difficult to
coerce gcc to handle these. Doing so took up at least half of the
"part-time" month of work it took to get gcc "limping along". I never
did get delay-slot filling ("experimental" on the gcc of the time)
working, nor was I ever able to get out the last vestiges of silliness
about effective-address calculation. So, one month to "mostly works",
another (ever-decreasing partial-time) to "code is generally correct,
albeit often sub-optimal".


Today, when gcc _really_ seems to believe it's a C++ compiler
and just "slumming" as a C compiler, I'd expect it to be a little more
difficult. OTOH, I have heard that both the factions have improved the
extent to which it "believes" the #defines that alledegly control such
things as stack direction and alignment. YMMV. Oh, and if your
machine is not a "power of two" word-size (preferably exactly 32) with
addresses in the form of indices into a sea of eight-bit bytes, "run
away", now!, at least from gcc. AFAIK, lcc is from the lovely folks
who also brought us the "Machine Independant Linker". I'd expect it to
be a bit more tolerant of variation, but as I said, it was not an
option at the time, and I no longer have a burning need to re-target a
C compiler, so I haven't looked at it in detail.


BTW: I was to some extent "set up" for some of the problems I
had with gcc by having previously written a code- generator for an
Algol60 compiler, and by studying two other C compilers (PCC and the
Decus PDP-11 C compiler). When I specified the architecture of "my"
CPU, I asked myself questions of the form "How would one generate code
for this construct?", in the context of _general_ compiler
characteristics. Had I started out with "How would I make _GCC_
generate code for this construct?", I might have changed some things
:-) (Yet another example of how mis-named "hardware" and "software"
are. "Hardware" is the stuff that changes all the time, because
"Software" isn't changeable any more)


Mike
| albaugh@agames.com, speaking only for myself

Return to the comp.compilers page.
Search the comp.compilers archives again.