Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 10/06/2011 01:44 AM, Jason Dagit wrote: On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) Really? I found this in the manual so I think either the docs need to be updated or you are mistaken: Apparently I am mistaken. It allows inline C-- (as of 6.12.1): http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/ffi.html#ffi-prim Of course, C-- is not nearly the same as Core. Sorry about that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
It's worth mentioning 'foreign prim' is still a bit different from inline code - while you can certainly write Cmm and have GHC link it into your program, it is not really inline. GHC has two different kinds of primitive operations: inline primops, and out of line primops. foreign primops are currently always out of line. Inline primops require actual GHC hacking, as they are short code sequences emitted directly by the code generator, that don't block or require allocation. As far as I know, GHC will naturally still generate a call to these out of line primops when you use them - in the form of a 'jmp' instruction, which is all that exists in Cmm (if someone out there knows more, like Johan perhaps who recently did memcpy inline primops, please correct me.) GHC will not necessarily have to spill STG registers (as it would in the case of a true foreign call,) but the instructions certainly won't be inline. Truthfully the use case for foreign prim is frighteningly small I think. It's been around for a while, but currently it's only client is integer-gmp, which was part of the motivation for the implementation anyway (to split GMP away from the GHC RTS, so it would be possibly to build full BSD3 haskell executables for commercial purposes, etc.) Outside of perhaps, an integer-openssl binding that instead used OpenSSL bignums, I can't think of many use cases personally. And a true 64bit GHC port to windows is of course, going to help the situation much more than any amount of hacking around the issue with 32bits and 8 registers will, while trying to retain some sense of efficiency. On Fri, Jun 10, 2011 at 12:16 PM, Andrew Coppin andrewcop...@btinternet.com wrote: On 10/06/2011 01:44 AM, Jason Dagit wrote: On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) Really? I found this in the manual so I think either the docs need to be updated or you are mistaken: Apparently I am mistaken. It allows inline C-- (as of 6.12.1): http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/ffi.html#ffi-prim Of course, C-- is not nearly the same as Core. Sorry about that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
It is 32 bits, I'm sure. Besides the 32-bit stack manipulation, it uses eax and ecx to hold two 32-bit parts of the 64-bit number. Best regards, Rafael On Thu, Jun 9, 2011 at 02:54, Scott Lawrence byt...@gmail.com wrote: On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
This really sucks. Not even LLVM is ported to 64-bit Windows. This is mainly because Windows uses 32-bit pointers for compatibility. http://archive.gamedev.net/reference/programming/features/20issues64bit/ Atc Rafael On Thu, Jun 9, 2011 at 08:04, Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com wrote: It is 32 bits, I'm sure. Besides the 32-bit stack manipulation, it uses eax and ecx to hold two 32-bit parts of the 64-bit number. Best regards, Rafael On Thu, Jun 9, 2011 at 02:54, Scott Lawrence byt...@gmail.com wrote: On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Rafael Gustavo da Cunha Pereira Pinto -- Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 09/06/2011 06:54 AM, Scott Lawrence wrote: On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) The general register naming scheme on x86 is: AL, AH: 8 bits AX: 16 bits EAX: 32 bits RAX: 64 bits There's a lot of code there, but from what I can see, it's all operating on 32-bit registers. So I'd say this is 32-bit code. On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would... (I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Am 09.06.2011 19:44, schrieb Andrew Coppin: On 09/06/2011 06:54 AM, Scott Lawrence wrote: On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) The general register naming scheme on x86 is: AL, AH: 8 bits AX: 16 bits EAX: 32 bits RAX: 64 bits There's a lot of code there, but from what I can see, it's all operating on 32-bit registers. So I'd say this is 32-bit code. On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would... (I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe For a chess engine this is for sure not true. I guess that this is one of very few domains where it really matters! The most (basic) operations with bitboards are anding, oring, xoring, shifting and (for magic bitboards) multiplying 64 bits values. When using 32 bits you need for some of these more then double time to achieve the same. I was wondering if there is a possibility to support 64 bit native codes without other stuff (calling conventions, win64 specific system calls etc). This could be perhaps a first step to full 64 bit support. But from the code of ghc I could not understand what this would mean. Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would... (I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.) For a chess engine this is for sure not true. I guess that this is one of very few domains where it really matters! The most (basic) operations with bitboards are anding, oring, xoring, shifting and (for magic bitboards) multiplying 64 bits values. When using 32 bits you need for some of these more then double time to achieve the same. I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower. Back in the old days of non-pipelined, uniscalar CPUs, it would certainly have been the case. Today's processors are far more complex than that. Things like cache misses tend to have a way, way bigger performance hit than anything arithmetic-related. I was wondering if there is a possibility to support 64 bit native codes without other stuff (calling conventions, win64 specific system calls etc). This could be perhaps a first step to full 64 bit support. But from the code of ghc I could not understand what this would mean. I'm wondering if you could write the operations you want is small C stub functions, and FFI to them and do it that way. I don't really know enough about this sort of thing to know whether that'll work... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin andrewcop...@btinternet.com wrote: I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower. Back in the old days of non-pipelined, uniscalar CPUs, it would certainly have been the case. Today's processors are far more complex than that. Things like cache misses tend to have a way, way bigger performance hit than anything arithmetic-related. The problem is you're probably going to need to spill things (somewhere) in order to operate on the upper 32bits of any given register in the non trivial case. x86 already is pathetic in its 8 GP registers. amd64 brings it up to 16. GHC already has to put a significant amount of stuff on the stack on x86 because of that, IIRC (I think only 3 STG registers are actually pinned, and the remaining 5 are for use by the register allocator.) I'm wondering if you could write the operations you want is small C stub functions, and FFI to them and do it that way. I don't really know enough about this sort of thing to know whether that'll work... It's highly unlikely that the cost of a foreign call (even an unsafe one) in terms of just CPU cycles will be cheaper than executing a few primitive arithmetic ops on the CPU. GHC will at least need to spill to the stack before and reload after every call. If the arithmetic ops were to somehow pipeline, that would be even worse in your favor, because the cycle count for your core operation would go *down* as a result of the pipelining, making the foreign call that much more expensive. Furthermore, GHC will invoke the C compiler on a FFI'd .c file to produce an object file. It's unlikely the linker will be able to inline copies of the function at call sites at link time, so if you use C, the function will likely exist as object-code far away from the call sites, and that will probably hurt your L1i cache locality a bit. -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 09/06/2011 08:44 PM, austin seipp wrote: On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin andrewcop...@btinternet.com wrote: I'm still left wondering if using 32-bit instructions to manipulate 64-bit values is actually that much slower. The problem is you're probably going to need to spill things (somewhere) in order to operate on the upper 32bits of any given register in the non trivial case. x86 already is pathetic in its 8 GP registers. amd64 brings it up to 16. Well, that's true enough. Given that AMD64 adds more registers, I'm surprised that this apparently makes such a small difference to wall-clock run-times. (But perhaps it makes a bigger difference for GHC. I don't know.) I'm wondering if you could write the operations you want is small C stub functions, and FFI to them and do it that way. I don't really know enough about this sort of thing to know whether that'll work... It's highly unlikely that the cost of a foreign call (even an unsafe one) in terms of just CPU cycles will be cheaper than executing a few primitive arithmetic ops on the CPU. Yeah, you're probably right there actually. Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Thu, Jun 9, 2011 at 4:06 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) Is this new in 7.2? Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin andrewcop...@btinternet.com wrote: Too bad GHC doesn't support inline assembly yet... (Or does it? I know it supports inline Core now.) Really? I found this in the manual so I think either the docs need to be updated or you are mistaken: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Tue, Jun 7, 2011 at 11:32 AM, Nicu Ionita nicu.ion...@acons.at wrote: Yes, I was a little bit unclear, I wanted to say: the generated code does not use the 64 bit instructions (i.e. 1 instruction for .., for example). Of course, it works, but I suppose, much slower then it could (3-4 times, for that part?) Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 06/09/2011 01:47 AM, Jason Dagit wrote: Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610 My assembly-fu is not strong enough to tell if it's using 64bit instructions. It would appear to be 32-bit. (pushl instead of pushq no instances of aligning to 8-byte boundaries) signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 06/06/2011 09:34 PM, Nicu Ionita wrote: Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Am 07.06.2011 19:37, schrieb Andrew Coppin: On 06/06/2011 09:34 PM, Nicu Ionita wrote: Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Yes, I was a little bit unclear, I wanted to say: the generated code does not use the 64 bit instructions (i.e. 1 instruction for .., for example). Of course, it works, but I suppose, much slower then it could (3-4 times, for that part?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Am 23.05.2011 13:32, schrieb Simon Marlow: On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. Nicu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Mon, Jun 6, 2011 at 1:34 PM, Nicu Ionita nicu.ion...@acons.at wrote: Am 23.05.2011 13:32, schrieb Simon Marlow: On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. Seems to work okay for me on windows: Prelude Data.Word Data.Bits (1 :: Word64) `shiftL` 62 4611686018427387904 Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Mon, May 23, 2011 at 4:32 AM, Simon Marlow marlo...@gmail.com wrote: On 18/05/2011 19:22, Jason Dagit wrote: On Wed, May 18, 2011 at 2:50 AM, John Sneerjohnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. There is no port of GHC to 64-bit Windows yet. Various people have expressed an interest in having one, but it is a significant chunk of work to implement (plus extra work to maintain and build distributions), so we don't have any plans to do it in the short term. You can track progress (or lack thereof) by adding your email to the CC on the ticket: http://hackage.haskell.org/trac/ghc/ticket/1884 Thanks! I'm trying to add myself to the ticket but I'm having some issues. I've had lots of account issues on the ghc trac over the years. I've created several usernames but never been able to login consistently with them so I normally use the guest account. To add myself to that ticket I think I need a non-guest account. Here is what seems to be happening: * I try to login with 'dagit' but I don't know the password * I try to reset the password but I can't seem to get the right username/email combo * I try to create a new account (the error message in the previous step is ambiguous enough that I thought maybe the 'dagit' account doesn't exist), but it says the account exists. * I'm asking for assistance in #ghc but no one has helped me yet On a side note, the captcha for account creation is VERY hard to read (I got it wrong 3 times in a row, and as far as I know I'm human). If you want to help out, join cvs-...@haskell.org and we can help with pointers to what needs to be done. I think I'm on that list already. I'm very happy to help in anyway that I can. Do you already have a build machine for testing a 64bit build? Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? I have no problem using 32bit version until I need more than 2GB of RAM. I went through some older threads, but description like: 1) install gcc 2) install ghc 3) build platform is something that didn't work well. Is there some more detailed description or recommended versions etc? If there is none then there is no need to respond. Thanks, regards J. -- John Sneer johnsn...@operamail.com -- http://www.fastmail.fm - Does exactly what it says on the tin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On Wed, May 18, 2011 at 2:50 AM, John Sneer johnsn...@operamail.com wrote: Hello all, I know it is not probably good question to this list, but anyway, could anyone point me to some more detailed how to where is described building of Haskell Platform natively to 64bit Windows? If you figure out how to do this, I would like to know as well. I could also benefit from 64bit Haskell on windows. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
