|lcc intel backend? email@example.com (1993-10-07)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-11)|
|Re: lcc intel backend? email@example.com (1993-10-12)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-12)|
|Re: lcc intel backend? email@example.com (1993-10-15)|
|Re: lcc intel backend? firstname.lastname@example.org (1993-10-18)|
|Re: lcc intel backend? email@example.com (1993-10-19)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Date:||Tue, 19 Oct 1993 09:39:50 GMT|
email@example.com (Piercarlo Grandi) writes:
|> Well, lcc *does not have a code generator*, for the x86 or any
|> architecture; it is purely a front end. Several back ends can be bolted
|> onto the front end. TWIG is the oldest. Several people are working or have
|> worked on other backend; frontends that spring to mind are BURG, IBURG,
|> and CHOP.
BURG and IBURG are not backends, just tree parser generators that can be
used to produce the instruction selection part of a back-end. One
back-end generator that works with lcc is Marion. However, I don't know if
it's available. Also, it's aimed at RISCs.
Two of our students did a globally-optimizing back-end for lcc. They had
some problems with lcc's intermediate representation. It is well
documented, but not made for global optimization and global register
allocation. Instead, lcc makes it easy to produce decent code with a
simple code generator.
M. Anton Ertl, firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.