[Atomics] code stubs for atomic operations

src/arm/simulator-arm.cc

Index: src/arm/simulator-arm.cc
diff --git a/src/arm/simulator-arm.cc b/src/arm/simulator-arm.cc
index 06c1bb9724e23ded9b413e6ff11b45b0b1d12ad4..fe3e69eef907a46b7bc55b717330e9aa853c2a45 100644
--- a/src/arm/simulator-arm.cc
+++ b/src/arm/simulator-arm.cc
@@ -3903,6 +3903,9 @@ void Simulator::DecodeSpecialCondition(Instruction* instr) {
     case 0xB:
       if ((instr->Bits(22, 20) == 5) && (instr->Bits(15, 12) == 0xf)) {
         // pld: ignore instruction.
+      } else if (instr->SpecialValue() == 0xA && instr->Bits(22, 20) == 7) {
+        // dsb, dmb, isb: ignore instruction for now.
+        // TODO(binji): implement

[Jarin, 2016/01/28 08:11:12]

How about having a global variable for the fences? Then we would atomically
increment it by 0 here. This should give us strong-enough guarantees for the
barriers, I think.

[binji, 2016/01/28 16:20:00]

Maybe... looking at http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html, the
sequence for ARM we'll generate is:

  LoadSeqCst: ldr; dmb
  StoreSeqCst: dmb; str; dmb

it looks like we could translate dmb -> mfence:

  LoadSeqCst: mov; mfence
  StoreSeqCst: mfence; mov; mfence

This would then match the x86 SeqCst alternate implementation in that doc (with
extra fences):

  LoadSeqCst: mov
  StoreSeqCst: mov; mfence

But I'm not sure the atomic increment (probably xadd 0...?) would have the same
guarantees. What do you think?

[Jarin, 2016/02/01 07:42:43]

Atomic (i.e., locked) increment on x86s has a built-in fence. I believe this
should work on x86. I am a bit less sure about the other architectures (e.g.,
simulating arm on ppc), but I think we should still be ok.

       } else {
         UNIMPLEMENTED();
       }