x86_64: total success
simonmar at microsoft.com
Fri Oct 15 04:18:26 EDT 2004
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
> proper way to do it, it does seem to have solved the problem for me
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
./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.
More information about the Glasgow-haskell-users