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