The __breakpoint() intrinsic enables you to include an ARM or Thumb BKPT instruction in your C or C++ code. You cannot use this intrinsic in inline assembly. The syntax for this intrinsic is:

__breakpoint(value);

value is a compile-time constant integer, and must be included. The value must be an integer in the range:

For example:

func() {
    ...
    __breakpoint(0xF02C);
    ...
}

If __breakpoint() is used on architectures that do not support the BKPT instruction, a warning is generated. If a BKPT instruction is executed on an architecture that does not support it, the undefined instruction trap is taken.

The exact location of the BKPT instruction is not guaranteed unless you specify the minimum optimization level -O0. At all other optimization levels the compiler might move, but not remove, the BKPT instruction.

For more details of the BKPT instruction, see RealView Developer Kit v2.2 Assembler Guide.

Returns the value of the program counter (PC) at the point where __current_pc() is used. The implicit prototype for this intrinsic is:

int __current_pc(void)

Returns the value of the stack pointer (sp) at the point where __current_sp() is used. The implicit prototype for this intrinsic is:

int __current_sp(void)

Returns the value of the link register (lr) that is used to return from the current function. The implicit prototype for this intrinsic is:

int __return_address(void)

The __return_address() intrinsic does not affect the ability of the compiler to perform optimizations, such as inlining, tail calling, and code sharing. However, the returned value reflects the optimizations performed. For more details on the optimization options, see Defining optimization criteria.

Different optimizations are applied as follows:

The __nop() intrinsic is used to insert a single NOP instruction into the instruction stream generated by the compiler. This enables you to, for example, insert a small delay between reading and writing to a memory-mapped peripheral. The implicit prototype for this intrinsic is:

void __nop(void)

One NOP instruction is generated for each __nop() in the source. The compiler does not optimize-away the NOP instructions, except for normal unreachable-code elimination. __nop() also acts as a barrier for instruction scheduling in the compiler, that is instructions are not moved from one side of the NOP to the other as a result of optimization.

For example:

volatile int *hw_reg1;
volatile int *hw_reg2;
int update(int input)
{
    /* update the peripheral */
    *hw_reg1 = input;
    /* allow peripheral time to update its status */
    __nop();
    /* read new status */
    return *hw_reg2;
}

These functions enable you to control IRQ and FIQ interrupts (see Enabling and disabling interrupts).

The prototypes for these intrinsics are:

void __disable_irq(void);
void __enable_irq(void);
void __disable_fiq(void);
void __enable_fiq(void);

__{dis,en}able_{ir,fi}q can only be executed in privileged modes, that is, in non-user modes. In User mode these instructions do not change the interrupt flags in the CPSR.

The ARM compiler can perform a range of optimizations, including re-ordering instructions and merging some operations. In some cases, such as system level programming where memory is being accessed concurrently by multiple processes, it might be necessary to disable instruction re-ordering and force memory to be updated.

The following optimization barrier intrinsics do not generate code, however they can result in slightly increased code size and additional memory accesses:

void __schedule_barrier(void);
void __force_stored(void);
void __memory_changed(void):