RE: x86_64: total success
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 [EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64: total success
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64: total success
Aha! a partial fix! now everything works as expected. I just needed to create a link from libgmp.so.3 - libgmp.so and now it all works! So the complete instructions for getting ghc working on a fedora 2 x86_64 system are ; yum install gmp.i386 readline.i386 ; ln -s /usr/lib/libgmp.so.3 /usr/lib/libgmp.so ; ln -s /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmp.so ; rpm -U ghc-*.i386*.rpm -- downloaded from ghc web site and just always pass -optc-m32 -opta-m32 -optl-m32 to ghc and everything just works. If we can get ghc to pass those options automatically by 6.2.2 that would be cool and a very easy fix. Now I can get started on a native port. Hopefully, the much reduced register pressure on x86_64 and ability to take advantage of sse for floating point will speed things up for the RTS. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: x86_64: total success
On 14 October 2004 07:06, John Meacham wrote: Aha! a partial fix! now everything works as expected. I just needed to create a link from libgmp.so.3 - libgmp.so and now it all works! The right way to get this link (at least on old RedHat systems) is to install the gmp-devel RPM. So the complete instructions for getting ghc working on a fedora 2 x86_64 system are ; yum install gmp.i386 readline.i386 ; ln -s /usr/lib/libgmp.so.3 /usr/lib/libgmp.so ; ln -s /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmp.so ; rpm -U ghc-*.i386*.rpm -- downloaded from ghc web site and just always pass -optc-m32 -opta-m32 -optl-m32 to ghc and everything just works. If we can get ghc to pass those options automatically by 6.2.2 that would be cool and a very easy fix. 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. However, someone could create a 6.2.2 distribution for x86_64 with the small local patch which adds -m32 to gcc's command line. Now I can get started on a native port. Hopefully, the much reduced register pressure on x86_64 and ability to take advantage of sse for floating point will speed things up for the RTS. There's already some work on this in the tree - I've picked a register mapping (see ghc/includes/MachRegs.h) and done much of the work to get registerised going on x86_64. I got stalled before because of a bug in gcc, but that's now fixed (in gcc 3.4), so you should be ok. 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. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: x86_64: total success
On Thu, Oct 14, 2004 at 09:52:49AM +0100, Simon Marlow wrote: On 14 October 2004 07:06, John Meacham wrote: Aha! a partial fix! now everything works as expected. I just needed to create a link from libgmp.so.3 - libgmp.so and now it all works! The right way to get this link (at least on old RedHat systems) is to install the gmp-devel RPM. The problem is that the way the multi-arch system works, I have 3 packages installed gmp.x86_64 gmp.i386 gmp-devel and the gmp-devel is shared between the other two and already came with the system so I couldn't install it again to create the links. So the complete instructions for getting ghc working on a fedora 2 x86_64 system are ; yum install gmp.i386 readline.i386 ; ln -s /usr/lib/libgmp.so.3 /usr/lib/libgmp.so ; ln -s /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmp.so ; rpm -U ghc-*.i386*.rpm -- downloaded from ghc web site and just always pass -optc-m32 -opta-m32 -optl-m32 to ghc and everything just works. If we can get ghc to pass those options automatically by 6.2.2 that would be cool and a very easy fix. 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 [EMAIL PROTECTED] 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. However, someone could create a 6.2.2 distribution for x86_64 with the small local patch which adds -m32 to gcc's command line. Now I can get started on a native port. Hopefully, the much reduced register pressure on x86_64 and ability to take advantage of sse for floating point will speed things up for the RTS. There's already some work on this in the tree - I've picked a register mapping (see ghc/includes/MachRegs.h) and done much of the work to get registerised going on x86_64. I got stalled before because of a bug in gcc, but that's now fixed (in gcc 3.4), so you should be ok. 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. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
