On Tue, Apr 29, 2014 at 9:56 AM, Stefan Wallentowitz <[email protected]> wrote: > Hi Stefan, > > nice work. I have some remarks for discussion: > > * The parts where you describe atomic_reserve and atomic_address might > be implementation-specific. I think LL/SC can also be implemented as > part of the cache (with "linked" cache line flags). Similarly, there > could be more than one atomic_reserve and atomic_address registers to > support several LL/SC operations (which I would prefer for a future > mor1kx implementation). Maybe we can think about a more generic > description like atomic_reserve[EA] and a note that states, that the > number of concurrent atomic_reserve is limited or so. I will also think > about and check other architecture specs. >
Good point, I was afraid that my description was a bit to implementation specific, but I thought that there wasn't much options how to implement it. I think your more generic 'atomic_reserve[EA]' might be a better option. I haven't seen any references to several ll/sc being active at the same time in any other arch specs, but I might not have looked carefully enough. Do you have an example? > * Maybe we should add a note that refers to implementation descriptions > regarding further conditions under that an swa might fail (like when > implemented as part of the cache) > hmm, so what would those conditions be? > * Finally, I want to bring up the memory model in this context. I think > the architecture manual lacks proper mentioning of the assumed > consistency. mor1kx implements sequential consistency I suppose and so > might some programs. I think it may be better to go with a more relaxed > consistency model, like total store order in Sparc. Independent of > whether it is changed, the memory model description may be added in this > revision, as the l.lwa and l.swa would be synchronization points in a > relaxed consistency model (as l.msync is then). > Yes, I agree that it needs to be defined better. Perhaps that is slightly out of the scope of what I'm doing here though, maybe you are up to defining something more concrete in the future? However, the note that l.swa/l.wa acts as memory barriers could be added, because that's what we want, right? Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
