Re: [Valgrind-developers] Transactional memory implementation input

[Eliot M. <mo...@cs...>]

Two quick comments:

1. *Some* PPC txns are expected to complete if tried repeatedly, and thus will not have a failure path.

2. At least on x86 and maybe on PPC some status bits indicating failure and its cause need to be set appropriately when going to the failure path.

Regards - Eliot Moss
Sent via BlackBerry

-----Original Message-----
From: "Carl E. Love" <ce...@li...>
Date: Fri, 28 Jun 2013 15:37:52 
To: Julian Seward<js...@ac...>
Cc: <val...@li...>
Subject: Re: [Valgrind-developers] Transactional memory implementation input

On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote:
> Hi Carl,
> 
> > would work or not work in Valgrind for the power instructions.  Anyway,
> > any input on the specifics of how I push the simulated execution
> > directly to the failure path would be helpful.  Thanks.
> 
> I don't know the specifics of the Power instructions, so I can't answer
> that directly.  But I can tell you what the idea was for the Intel
> instructions -- maybe that would help.
> 
> (IIRC) the Intel instructions are
> 
>    XBEGIN %reg         -- begin a transaction.
>                        -- %reg holds the failure-path address
> 
>    XEND     -- finish the most recently XBEGIN'd transaction
> 
> So the idea is very simple: translate XBEGIN %reg as if it was
> simply a jump to (the code address in) %reg.  Does that help?

So basically you will unconditionally take the failure path which
presumably is the code to handle the transaction in a non-transactional
way, i.e. to obtain the necessary lock do the operations and then
release the lock.

>From what I understand of the power implementation (I have some
questions for the IBM compiler people) is that the instruction following
the tbegin will be a branch instruction with the address of the failure
path.  So I guess we could do something similar.  However I have some
concerns.  One concern is, what guarantee do we have that the outcome of
the failure path would be functionally equivalent to the transactional
path?  Specifically, did the programmer do the same operations under the
appropriate data lock to guarantee the code sequence is executed
atomically and thus generated the same result?.  Seems like we are at
the mercy of whatever the programmer chooses to do in the case of a
failure.  I need to chat with our compiler people about that question.
I guess in theory the programmer could chose throw up his hands and just
call exit(1) if the transaction failed.  In that case, Valgrind would
never be able to reproduce a successful run of the program on real
hardware where there was no TM issues during the run.  Maybe I am still
missing a lot here.  Like I said, I am just starting to dive into this
and understand all the issues and ramifications.

> 
> J
> 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers