x86_64: total success

[Simon Marlow]

On 14 October 2004 10:13, John Meacham wrote:

>> It's too late for 6.2.2, unless it's a 1-line fix.  I don't think it
>> is, because it won't be self-hosting without some more work in the
>> build system.
> 
> 
> ;diff package.conf.backup package.conf                               
> # /usr/lib/ghc-6.2.1  2:06AM john at momenergy 1 12c12
> <      extra_ghc_opts = [],
> ---
>>      extra_ghc_opts = ["-optc-m32", "-opta-m32", "-optl-m32"],
> 
> well, it did turn out to be a one-line fix :) but perhaps this isn't
> the 
> proper way to do it, it does seem to have solved the problem for me
> though.

That's not really a "fix".  It's a patch for the i386 distribution to
make it work on on x86_64 platform, but it doesn't let you build GHC on
that platform, for example.  For that, some (probably small) changes to
the build system would be required.  I imagine you would do something
like:

  ./configure --build=x86_64-unknown-linux --host=i386-unknown-linux

and the build system picks up the difference between $BuildArch and
$HostArch and adds the -m32 flags.  Something like that.

>> The interesting bit will be doing the native code generator, but you
>> should start from the new NCG in 6.4 if you're interested in working
>> on that.  Adding SSE support would be great.
> 
> Yes, I am looking at that code now.
> 
> Would it even be possible to have the same ghc binary have multiple
> target architectures? it seems that some stuff ends up hardcoded in
> various places after the ./configure of ghc.

Certainly compiling multiple native code generators into the compiler is
possible in principle, but would require some work.  That's certainly
not the end of the story though: GHC expects certain constants to be
"constant", including the size of a word on the target architectre.
Abstracting this would be rather difficult.

However, building a cross-compiler is probably more feasible.  Some work
involved definitely, but feasible.

Cheers,
	Simon