Running GHC on the IBM Cell

[Simon Marlow]

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