GHC Alpha port?

Simon Marlow
Tue, 10 Jul 2001 10:24:30 +0100

Hi Ken,

> On 2001-07-05T10:34:27+0100, Simon Marlow wrote:
> > This isn't right: you shouldn't set GhcHcOpts in the first=20
> build.  In
> > the URL you gave, this line was commented out.  That's certainly the
> > reason for the core dumps.
> Ah!  Careless me.  Thank you.
> > In GHC 5.00.2, there's an easier way.  For the c1 & c2=20
> builds, you can
> > just set
> > 	GhcUnregisterised =3D YES
> > in, and you can set $long to empty.
> This seems to have worked.  By the way, the "old way" (as specified in
> the MacOS port readme) does not work with ghc 5 -- I got a seg fault
> when running ghc-inplace during the second stage.

Hmm, I should really add a section to the building guide on porting and
unregisterised compilation.

> > When you get around to bootstrapping on the Alpha, I'll=20
> probably need to
> > help you some more, because bootstrapping from .hc files is=20
> quite tricky
> > on 5.00.
> I'm there!

Great, you're in uncharted territory now :-)  (no-one has bootstrapped
from unregisterised .hc files with 5.00 yet...)

> The first obstacle I encountered is that PackedString.raw_s seems to
> be mangled incorrectly.

Ok, for unregisterised building we need to disable the mangler.  You
should be able to just compile the .hc files directly using gcc, but
you'll need to make sure that -DNO_REGS and -DUSE_MINIINTERPRETER are
added to gcc's command line.

The relevant makefile code is in fptools/mk/ - I'm sure
you'll be able to modify it to do the right thing.  When you've got it
working we'll think about how to set up the bootstrapping system so
mangling is optional.

(if you're wondering why this is harder than it used to be with 4.08,
it's because we used to have the "driver" written in Perl, and the
driver knew all about compiling .hc files.  Now the driver is in Haskell
and part of the compiler itself, we have to manage without it during
bootstrapping, hence the new makefile)