|
From: Eliot M. <mo...@cs...> - 2013-06-28 23:07:15
|
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 |