汇编分支指令，bne-0b

Question

Taken from Google Protobuf PowerPC GCC, there are methods for 32 bit architecture, but none for 64 bit.

I see the 0: flag, and later a bne- 0b branch if not equal to a flag before current address.

What does the - do in the bne- statement?

Specifically, when I write a version of this for 64 bit, I get syntax errors if I use 0: and bne- 0b , but the 32 bit version works just fine.

Why does it accept a word as a flag, but not 0: ?

Below is the Protobuf 32 bit method.

inline Atomic32 NoBarrier_AtomicIncrement(volatile Atomic32 *ptr,
                                          Atomic32 increment) {
  Atomic32 temp;

  __asm__ __volatile__(
      "0:                                  \n\t" // flag
      "lwarx %[temp],0,%[ptr]              \n\t"
      "add %[temp],%[increment],%[temp]    \n\t"
      "stwcx. %[temp],0,%[ptr]             \n\t"
      "bne- 0b                             \n\t" // branch not equal <dash> flag before
      : [temp] "=&r"(temp)
      : [increment] "r"(increment), [ptr] "r"(ptr)
      : "cc", "memory");

  return temp;
}

Below is my attempt at a 64 bit version.

inline Atomic64 NoBarrier_AtomicIncrement(volatile Atomic64 *ptr,
                                          Atomic64 increment) {
  Atomic64 temp;

  __asm__ __volatile__(
      "0:                                  \n\t"
      "ldarx %[temp],0,%[ptr]              \n\t"
      "add %[temp],%[increment],%[temp]    \n\t"
      "stdcx. %[temp],0,%[ptr]             \n\t"
      "bne- 0b                             \n\t"
      : [temp] "=&r"(temp)
      : [increment] "r"(increment), [ptr] "r"(ptr)
      : "cc", "memory");

  return temp;
}

Note that Atomic32 is an int , and Atomic64 is a long .

Also, if I replace the 0: flag by a word, such as loopai64: , I don't get errors. However, when I run the compiler, it gets stuck in an infinite loop.

Answer 1

The 0: is a local label. However, directional branch, such as bne- 0b ( 0b means jump to first instance of label 0 that is above current location) are not supported on all architectures.

In the end, I solved the issue by using longer label names.