I was reading http://embeddedgurus.com/embedded-bridge/2010/03/different-bit-types-in-different-registers/, which said:
With read/write bits, firmware sets and clears bits when needed. It typically first reads the register, modifies the desired bit, then writes the modified value back out
and I have run into that consrtuct while maintaining some production code coded by old salt embedded guys here. I don’t understand why this is necessary.
When I want to set/clear a bit, I always just or/nand with a bitmask. To my mind, this solves any threadsafe problems, since I assume setting (either by assignment or oring with a mask) a register only takes one cycle. On the other hand, if you first read the register, then modify, then write, an interrupt happening between the read and write may result in writing an old value to the register.
So why read-modify-write? Is it still necessary?
This depends somewhat on the architecture of your particular embedded device. I’ll give three examples that cover the common cases. The basic gist of it, however, is that fundamentally the CPU core cannot operate directly on the I/O devices’ registers, except to read and write them in a byte- or even word-wise fashion.
1) 68HC08 series, an 8-bit self-contained microcontroller.
This includes a “bit set” and a “bit clear” instruction. These, if you read the manual carefully, actually internally perform a read-modify-write cycle by themselves. They do have the advantage of being atomic operations, since as single instructions they cannot be interrupted.
You will also notice that they take longer than individual read or write instructions, but less time than using three instructions for the job (see below).
2) ARM or PowerPC, conventional 32-bit RISC CPUs (often found in high-end microcontrollers too).
These do not include any instructions which can both access memory and perform a computation (the and/or) at once. If you write in C:
*register |= 0x40;it turns into the folowing assembly (for this PowerPC example, r8 contains the register address):
Because this is multiple instructions, it is NOT atomic, and it can be interrupted. Making it atomic or even SMP-safe is beyond the scope of this answer – there are special instructions and techniques for it.
3) IA32 (x86) and AMD64. Why you would use these for “embedded” is beyond me, but they are a half-way house between the other two examples.
I forget whether there is a single-instruction in-memory bit-set and bit-clear on x86. If not, then see the RISC section above, it just takes only two instructions instead of three because x86 can load and modify in one instruction.
Assuming there are such instructions, they also need to internally load and store the register as well as modifying it. Modern versions will explcitly break the instruction into the three RISC-like operations internally.
The oddity is that x86 (unlike the HC08) can be interrupted on the memory bus in mid-transaction by a bus master, not just by a conventional CPU interrupt. So you can manually add a LOCK prefix to an instruction that needs to do multiple memory cycles to complete, as in this case. You won’t get this from plain C though.