I tested my patch on an old 32 bit laptop over night and it didn't work.
I think it's best to revert Simon's patch and let him fix it when he gets
chance.
On 3 May 2014 12:59, William Kenyon g...@abacathoo.org wrote:
I think this should fix the problem.
It certainly doesn't break anything on a
Ticket #9055 has a patch that uses the MACHREGS_NO_REGS macro
coming from compiler/codeGen/Platform/NoRegs.hs.
I think globalRegMaybe should depend on the target platform of the code to be
generated
and not on the host platform. Using the NO_REGS macro does the latter. I am
thinking
of
Hi,
I found myself needing atomic operations on basic, mutable numeric values.
I wrote a short design doc that I'd like feedback on:
https://ghc.haskell.org/trac/ghc/wiki/AtomicPrimops
I will try to implement these for 7.10.
-- Johan
___
ghc-devs
Are all of these links collected on the GHC wiki somewhere? If not,
would you mind adding them?
I, for one, appreciate a curated list of references like this!
On Sat, May 3, 2014 at 5:33 AM, Arash Rouhani
rar...@student.chalmers.se wrote:
(Sorry Florian, I forgot to reply to list!)
Hi
On Sun, 4 May 2014 09:34:16 +0100
William Kenyon g...@abacathoo.org wrote:
I tested my patch on an old 32 bit laptop over night and it didn't work.
I think it's best to revert Simon's patch and let him fix it when he gets
chance.
On 3 May 2014 12:59, William Kenyon g...@abacathoo.org wrote:
On Sun, May 4, 2014 at 5:45 PM, Sergei Trofimovich sly...@gmail.com wrote:
Does it make sense to have 64-bit alloc_limit on 32-bit box?
I think so. You allocate 2^32 bytes pretty quickly.
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
good idea! I've been thinking I should clean up my branches :) I updated
the wiki to reflect the state of the branches I know about. In short
`wip/ext-solver` + `master` subsumes all of: `type-nats`,
`type-nats-simple`, and `decision-procedure`.
Cheers,
Iavor
On Wed, Apr 30, 2014 at
According to google,
2^32 bytes = 4GB,
I think that is more memory than a 32 bit machine can handle anyway?
Maybe alloc_limit should be 32 bits on a 32 bit machine, and 64 bit on a 64
bit machine?
On 4 May 2014 16:06, Johan Tibell johan.tib...@gmail.com wrote:
On Sun, May 4, 2014 at 5:45
I thought the limit was the total amount allocated, not the amount live.
On Sun, May 4, 2014 at 7:50 PM, William Kenyon g...@abacathoo.org wrote:
According to google,
2^32 bytes = 4GB,
I think that is more memory than a 32 bit machine can handle anyway?
Maybe alloc_limit should be 32
Hi Andrew,
Thanks for the encouragement! :)
I went ahead and updated the wiki and incorporated my links. I also gave
some more guidelines for each link. [1]
Cheers,
Arash
[1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm
On 2014-05-04 16:53, Andrew Farmer wrote:
Are all of
On 04/05/14 16:45, Sergei Trofimovich wrote:
On Sun, 4 May 2014 09:34:16 +0100
William Kenyon g...@abacathoo.org wrote:
I tested my patch on an old 32 bit laptop over night and it didn't work.
I think it's best to revert Simon's patch and let him fix it when he gets
chance.
On 3 May 2014
This would be fantastic and I'd be happy to work with you to expose the
extra ops through the atomic-primops pkg.
This would continue our trend of supporting gcc intrinsic style atomics
(full fence, no configurabilit of the memory model a la lllvm).
These word sized ops are most important, but
ryan, any thoughts on the (valid!) concern John Lato raises?
I know you mentioned fighting ghc optimizations when writing concurrent
code a while ago, and i believe I asked if you could document the issues
some time so we can all think about how to make the sitch easier, could you
share your
Hi John Carter,
Deferring for a moment issues with CAS on lazy/pointer values, which
pertain to Carter's question, I want to understand the ordering concern WRT
only the IntArray primops that Johan listed. First, to my knowledge GHC
doesn't do any reordering of effectful memory operations (e.g.
For Johan's primops to work, each primop must represent a full memory
fence that is respected both by the architecture, and by *both* compilers
(GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM.
We need to verify that LLVM understands not to float regular loads and
One last comment -- none of the above is to suggest that I don't think we
should eventually have a memory model (a la Java or C++11). But I (and
Johan) don't think the addition of the primops Johan listed should wait on
it. Further, I don't think these primops make the state of affairs any
what sailed in ghc 7.2?
On Mon, May 5, 2014 at 12:46 AM, Ryan Newton rrnew...@gmail.com wrote:
One last comment -- none of the above is to suggest that I don't think we
should eventually have a memory model (a la Java or C++11). But I (and
Johan) don't think the addition of the primops
Oh, just the first CAS primop -- the initial decision to include these
kinds of ops.
Sent from my phone.
On May 5, 2014 12:59 AM, Carter Schonwald carter.schonw...@gmail.com
wrote:
what sailed in ghc 7.2?
On Mon, May 5, 2014 at 12:46 AM, Ryan Newton rrnew...@gmail.com wrote:
One last
18 matches
Mail list logo
