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@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
At some point in the past, someone wrote:
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.
On Fri, Oct 15, 2004 at 09:18:26AM +0100, Simon Marlow wrote:
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.
A patch such as this would be very helpful for me, as I just want to use ghci/etc. on x86-64 and don't really care much about e.g. the very highest-quality codegen. I hacked around this in various ways to get the stock binary i386 distribution to run on x86-64, but would prefer to use something less hackish than shell script wrappers for gcc(1) and as(1) that pass the 32-bit forcing arguments... Also, the Debian ghc package on sparc64 (32-bit) seems to need some kind of update; ghc proper is fine, but ghci cores. Maybe I should file a bug. Alpha looks clean, though. I've not tried on ia64, ppc64, or mips64 yet. Running on my sparc64 box would be nice b/c it has more cpus, RAM, and registers. =) $ ssh analyticity Last login: Fri Oct 15 02:36:58 2004 from meromorphy Linux analyticity 2.6.9-rc2-mm3 #2 SMP Fri Sep 24 18:40:06 PDT 2004 sparc64 GNU/Linux $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. zsh: 1282 segmentation fault ghci -- wli
participants (2)
-
Simon Marlow -
William Lee Irwin III