Building Haskell Platform natively for 64bit Windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Building Haskell Platform natively for 64bit Windows

John Sneer
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
  [hidden email]

--
http://www.fastmail.fm - Does exactly what it says on the tin


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Jason Dagit-3
On Wed, May 18, 2011 at 2:50 AM, John Sneer <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Simon Marlow-7
On 18/05/2011 19:22, Jason Dagit wrote:
> On Wed, May 18, 2011 at 2:50 AM, John Sneer<[hidden email]>  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 [hidden email] and we can help with
pointers to what needs to be done.

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Jason Dagit-3
On Mon, May 23, 2011 at 4:32 AM, Simon Marlow <[hidden email]> wrote:

> On 18/05/2011 19:22, Jason Dagit wrote:
>>
>> On Wed, May 18, 2011 at 2:50 AM, John Sneer<[hidden email]>
>>  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 [hidden email] 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Nicu Ionita
In reply to this post by Simon Marlow-7
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 Sneer<[hidden email]>  
>> 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 [hidden email] and we can help with
> pointers to what needs to be done.
>
> Cheers,
>     Simon
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Jason Dagit-3
On Mon, Jun 6, 2011 at 1:34 PM, Nicu Ionita <[hidden email]> 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 Sneer<[hidden email]>
>>>  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 [hidden email] and we can help with
>> pointers to what needs to be done.
>>
>> Cheers,
>>    Simon
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Andrew Coppin
In reply to this post by Nicu Ionita
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Nicu Ionita
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
> [hidden email]
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Jason Dagit-3
On Tue, Jun 7, 2011 at 11:32 AM, Nicu Ionita <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Scott Lawrence
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Rafael Gustavo da Cunha Pereira Pinto-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Rafael Gustavo da Cunha Pereira Pinto


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Rafael Gustavo da Cunha Pereira Pinto-2

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Rafael Gustavo da Cunha Pereira Pinto




--
Rafael Gustavo da Cunha Pereira Pinto


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Andrew Coppin
In reply to this post by Scott Lawrence
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Nicu Ionita
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
> [hidden email]
> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Andrew Coppin
>> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

austin seipp-3
On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin
<[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Andrew Coppin
On 09/06/2011 08:44 PM, austin seipp wrote:
> On Thu, Jun 9, 2011 at 1:53 PM, Andrew Coppin
> <[hidden email]>  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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Antoine Latter-2
On Thu, Jun 9, 2011 at 4:06 PM, Andrew Coppin
<[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Jason Dagit-3
In reply to this post by Andrew Coppin
On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin
<[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Building Haskell Platform natively for 64bit Windows

Andrew Coppin
On 10/06/2011 01:44 AM, Jason Dagit wrote:
> On Thu, Jun 9, 2011 at 2:06 PM, Andrew Coppin
> <[hidden email]>  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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12