Modifying GHC to accept external Styx code

Simon Peyton-Jones
Tue, 4 Feb 2003 08:44:37 -0000

Aha!  So what you really want is a code generator! =20

I suggest you take a look at C--. =20
(Check out the papers especially.)  It's designed for exactly what Stix
is designed for, only much, much better.  There's a prototype
implementation from Fermin Reig, and Norman Ramsey is working hard on
another.   (I'm ccing him.)

Hmm.  Maybe someone can write a C-- front end for GHC's code generator!


| -----Original Message-----
| From: Mark Alexander Wotton [mailto:mwotton@cse.unsw.EDU.AU]
| Sent: 03 February 2003 22:19
| To: Simon Peyton-Jones
| Cc:
| Subject: RE: Modifying GHC to accept external Styx code
| On Mon, 3 Feb 2003, Simon Peyton-Jones wrote:
| >
| > | I want to use GHC as a backend for my experimental compiler.
| > | I'm trying to modify it to accept styx code from my compiler, and
| > | having some trouble working out where I need to make changes. In
| > truth,
| > | GHC is more haskell code than I've ever seen before in one place,
| > I'm
| > | a bit lost: can anyone suggest which modules I should become
| > with
| > | and which I should leave alone?
| >
| > You don't say what 'styx code' is.  My advice:  either translate
styx to
| > Haskell, or to External Core.  (Probably the latter.)  GHC can read
| > of these in without modification.
| >
| > External Core is a typed lambda calculus.
| Yes, I know External Core: I'm using it as my input language. (GHC is
| frontend as well.) The optimisation algorithms I want to implement
| a lower-level language than Core, which is why I want to use Styx, the
| native generation intermediate language. Abstract C is also an option,
| if I've got to hack GHC to get either of them going, I'd rather do it
| Styx.
| Mark
| --
| no-one takes up music to play their own instrument
| 	-- Randy Hiatt, Chalkhills list