On Mon, Apr 28, 2014 at 7:49 PM, Stefan Kristiansson <[email protected]> wrote: > On Mon, Apr 21, 2014 at 11:28 PM, Stefan Kristiansson > <[email protected]> wrote: >> Update on this, I've added 'Atomicity' chapter and the l.lwa and l.swa >> instructions to the arch spec, with the things that we discussed in >> this thread. >> The updated arch spec can be found here for review: >> https://www.dropbox.com/s/yqyfelu2yrutzwt/openrisc-arch-1.1-rev0.pdf >> or as .odt: >> https://www.dropbox.com/s/bzez95ix1cl0g7g/openrisc-arch-1.1-rev0.odt >> > Update again. > > I've added the suggested changes about a clarification that it's the > physical address that is stored as the "atomic_address". > I've uploaded the changes to the dropbox links above, but below is > instruction descriptions in plain text: > > "l.lwa rD,I(rA) > Description: > The offset is sign-extended and added to the contents of > general-purpose register rA. The > sum represents an effective address. The single word in memory > addressed by EA is > loaded into the low-order 32 bits of general-purpose register rD. > High-order bits of > general-purpose register rD are replaced with zero. > Two internal registers are set, one 1-bit flag register that will be > referred to as > atomic_reserve and a 32/64-bit address register that will be referred > to as atomic_address. > The atomic_address register will be set to EA (translated to its > physical counterpart in > case the MMU is enabled)." > > "l.swa I(rA),rB > Description: > The offset is sign-extended and added to the contents of > general-purpose register rA. The > sum represents an effective address. The low-order 32 bits of > general-purpose register rB > are conditionally stored to memory location addressed by EA. The > 'atomic' condition > relies on that an atomic reserve to EA is still intact (i.e. that the > atomic_reserve internal > register mentioned in the l.lwa instruction is still set and the > internal atomic_address > register matches EA). When the MMU is enabled, the physical translation of EA > is > compared to the internal atomic_address."
Looks good Stefan. I like the idea of not bothering with a true SPR to store this state, because you're checking it anyway when l.b[n]f'ing after the l.swa. It's also a bit of state which you don't need to save during an exception. My only concern is that it's not visible to a debugger, but I'm not sure it really matters. In terms of implementation, have you found the additional infrastructure required (I presume exposure of the atomic access state per processor to some snoop logic near the shared memory) to complicate matters? Do these accesses appear like peripheral accesses (that is, to volatile memory areas like anything with address bit 31 set, typically) to the caches, so that they are never cached? Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
