On 10/12/12 12:46, Yuras Shumovich wrote:
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) =
On 08/12/12 23:12, Yuras Shumovich wrote:
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
It's not at all clear that we want to do this. Perhaps you'll be able
to put the question to rest and close the
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) = ccall lockClosure(mvar ptr);
}
On 09.12.2012, at 00:12, Yuras Shumovich shumovi...@gmail.com wrote:
It looks wrong for me: the highest part of %rax remains uninitialized.
When 32 bits are assigned to any of the standard registers, the upper 32 bits
are implicitly set to zero. Intel is weird.
Axel
When 32 bits are assigned to any of the standard registers, the upper 32
bits are implicitly set to zero. Intel is weird.
Didn't AMD invent the 64-bit extensions?
-- Kim-Ee
On Sun, Dec 9, 2012 at 3:07 PM, Axel Simon axel.si...@in.tum.de wrote:
On 09.12.2012, at 00:12, Yuras Shumovich
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
First I tried just to replace ccall lockClosure(mvar ptr) with
GET_INFO(mvar) in stg_takeMVarzh and stg_putMVarzh and got 60% speedup
(see the test case at the
