Suter, Jaap wrote:
I'm trying to get GHC to run on the Cell processor.
Cool :)
That is, just on the
PPU PowerPC side. The SPUs will continue to run C programs, managed and
driven by a Haskell manager on the PPU. I'm mostly interested in GHC for
its concurrency features (STM in particular).
Not knowing much about GHC yet, here's what I would expect in the ideal
situation.
1. The RTS is largely cross-platform already. I might have to make some
minor tweaks, but for the most part it should compile out of the box.
2. I setup GHC to compile my .hs files to .hc files; the C intermediates.
>
3. These are hopefully cross-platform as well, instead of being tied to
my GHC distribution's platform.
4. I compile the RTS and .hc files and link them all together.
5. Done.
This raises a few questions...
* Are the .hc files cross-platform? Or does a GHC compiled for PowerPC
generate different intermediate C code than a GHC compiled for X86?
Ideally the platform specifics are hidden inside the RTS and two
different GHC builds will output identical .hc files.
The .hc files are not cross-platform, you need to generate them for your target
platform using a working GHC on another machine first. The porting instructions
describe how to do this.
* How cross-platform is the RTS?
As long as your platform is POSIX compatible, you're probably in reasonable
shape. If you're not using gcc, then things might get more difficult, but I
believe the RTS has compiled with non-gcc compilers in the past so it shouldn't
be too hard.
I downloaded the source tarball and dropped it on top of my XP
installation of GHC. I then generated a simple Hello World haskell .hc
intermediate and tried to compile that and the RTS. Unfortunately I ran
into problems because things like HAVE_WINDOWS_H and HAVE_SIGNALS_H were
defined.
I started manually editing the code to tweak the configuration but ran
into more problems (signal_set_t doesn't exist on my platform, but can't
be conditionally compiled. static arrays of unknown size (StgWordArray)
make my compiler unhappy. Etcetera).
At this point I figured I would stop and ask for some help first, before
I invest a lot of energy in a dead-end path. There must be a simpler way.
I read parts of the "porting GHC to your platform" documentation, but I
believe it addresses a different problem. I don't want to recompile GHC
itself. I want to run my existing GHC on my XP machine and output
intermediate .hc files. I then feed these plus a cross-platform RTS to
my Cell compiler to get a workable program.
Ok. So what you want to do is similar to what the porting instructions
describe, in that you want to generate a cross-compiler on your host system that
can generate .hc files for your target, but you want to continue using this
cross-compiler to compile target binaries rather than use it to compile a native
GHC.
It seems plausible, though it's not something we typically do, so it might be a
bit of an adventure. For example, you'll have to invoke the C compiler and
linker by hand on the target machine, and those command lines can be pretty long
and complicated.
First thing to do is follow the porting instructions up until the point wher you
have a compiled set of libraries and RTS on the target machine. You can omit
compiling GHC itself. From that point, you ought to be able to take .hc files
for your program to the target machine, compile them against the .h files in
your GHC build, and link them against the libraries and RTS.
I suppose I need to regenerate the ghautoconf for my particular platform
(rather than hand-tweaking the existing one). Unfortunately I'm not much
of a Linux or Gnu toolset expert. I see a bunch of config.* and
configure.* file in the root folder. I suppose I should read up on those
a little more. I'll do my homework first.
In the meanwhile, if anybody has any quick and simple advice to make
this process smoother that would be greatly appreciated.
Kind regards,
Jaap Suter - http://www.jaapsuter.com
Some more random questions...
* ghautoconf.h and HsBaseConfig.h have similar #defines (like
HAVE_WINDOWS_H). Is there a reason for that? I always need to update
them in two places now.
* After downloading the source tarball and unzipping over my XP GHC
installation, I got both an 'include' and an 'includes' directory. This
is somewhat confusing.
I wouldn't recommend unzipping the source tree over the installed tree, they
aren't designed to coexist.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
