On Tue, Apr 29, 2014 at 2:28 AM, Julius Baxter <[email protected]> wrote: > > 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. >
I don't think this is generally visible to debuggers on other CPUs, so I also doubt it's an issue. Does anyone else have any insight on this? > 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? AFAIK, you don't need to export the atomic access state, what you need to do is expose the snoop addresses to the atomic access logic. In the implementation I've done, snooping isn't done at all (i.e., it's only for single core), however as seen in the Stefan Wallentowitz's message in the other thread, he has added this logic: https://github.com/wallento/mor1kx/commit/2372e0b69eb1091f377a1ea32072758f219ce294 > 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? > No, in terms of load/store instructions, they act exactly the same as l.lwz and l.sw. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
