{"id":102790,"date":"2019-08-19T07:00:00","date_gmt":"2019-08-19T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102790"},"modified":"2019-09-13T21:48:38","modified_gmt":"2019-09-14T04:48:38","slug":"20190819-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190819-00\/?p=102790","title":{"rendered":"The SuperH-3, part 11: Atomic operations"},"content":{"rendered":"

The SH-3 has a very limited number of read-modify-write operations<\/a>. To recap:<\/p>\n

    AND.B #imm, @(r0, GBR)  ; @(r0 + gbr) &= 8-bit immediate\r\n    OR.B  #imm, @(r0, GBR)  ; @(r0 + gbr) |= 8-bit immediate\r\n    XOR.B #imm, @(r0, GBR)  ; @(r0 + gbr) ^= 8-bit immediate\r\n    TAS.B @Rn               ; T = (@Rn == 0), @Rn |= 0x80\r\n<\/pre>\n
These instructions are “atomic” in the sense that they occur within a single instruction and are hence non-interruptible. Technically, only the last one is truly atomic in the sense that the processor holds the data bus locked for the duration of the instruction.<\/p>\n
Let’s not quibble about such details. Let’s just say we’re looking for non-interruptible instructions.<\/p>\n
The SH-3 does not support symmetric multiprocessing, so we don’t have to worry about competing accesses from other main processors (although there may be competing accesses from coprocessors or hardware devices). But how are we going to build atomic increment, decrement, and exchange out of these guys?<\/p>\n
Let’s be honest. We can’t.<\/p>\n
We’ll have to fake it.<\/p>\n
Windows CE takes a different approach from  how Windows 98 created atomic operations on a processor that didn’t support them<\/a>.<\/p>\n
On Windows CE, the kernel is in cahoots with the implementations of the interlocked operations. If it discovers that it interrupted a special uninterruptible sequence, it resets the program counter back to the start of the uninterruptible sequence before allowing user mode to resume.\u00b9 In this way, the kernel manufactures multi-instruction uninterruptible sequences.<\/p>\n
These sequences have to be carefully written so that they are restartable. This means that they cannot mutate any input parameters, and there are no memory updates until the final instruction in the sequence.<\/p>\n
For example, we could try to implement our fake Interlocked\u00adIncrement<\/code> like this:<\/p>\n
; on entry:\r\n;   r4 = address to increment\r\n; on exit:\r\n;   r0 = incremented value\r\n\r\nInterlockedIncrement:\r\n    mov.l   @r4, r0     ; load current value    ; (1)\r\n    add     #1, r0      ; increment it          ; (2)\r\n    mov.l   r0, @r4     ; store updated value   ; (3)\r\n    rts                 ; return                ; (4)\r\n<\/pre>\n
We load the current value from memory, add 1, store it back, and return. If this sequence is interrupt at any point, the kernel moves the program counter back to the first instruction and restarts the entire operation.<\/p>\n
Let’s walk through the possible interrupts.<\/p>\n