|
From: Julian S. <js...@ac...> - 2013-06-20 09:27:24
|
Transactional memory support in hardware is about to hit mainstream
cpus, with the arrival of Intel's Haswell family. It also exists or
is about to exist (I don't know which) in the s390 and POWER architectures.
So we need to have a Plan for dealing with it. I looked at the Intel
(Haswell) instructions a bit, but don't know about the s390 or POWER
ones.
IIRC, the Intel scheme requires two instructions:
XBEGIN fail-addr
XEND
XBEGIN starts a transaction and registers fail-addr as the fallback
address. If the transaction fails for whatever reason (there are many
reasons why it might fail) then the processor rolls back register/memory
state to how it was at the XBEGIN, and executes code at fail-addr
instead.
XEND finishes the transaction.
Transactions can be nested.
We can't hope to emulate the conflict checking done by the real CPU
in any sane (performance or complexity) way. So I see two remaining
options:
(1) translate "XBEGIN fail-addr" as "goto fail-addr"; that is: push
simulated execution directly onto the failure path. This is simple
but will have poor performance, if (as is likely) the failure path
uses normal locking and is not tuned for speed.
(2) translate "XBEGIN fail-addr" by handing it through to the real CPU,
in the same kind of way we handle CPUID, RDTSC, etc. Of course we will
have to put our own failure-handler address so we don't lose control
of execution if the transaction is aborted, but that's not difficult.
---
(1) is simple but likely to work. (2) is probably preferable but I don't
know if there will be hidden problems in it.
This also assumes that the s390 and POWER instructions can be mapped to
this same structure: TRANSACTION-START(fail-addr) and TRANSACTION-END.
That's probably the first thing that we should investigate.
J
|