<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 10, 2016 at 3:49 PM, James Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Yeah, I found that info in the ARM ARM, however, it provides no information about forward progress guarantees. There's no subset of instructions, maximal length of loop, or other such info about what sorts of LL/SC loops can be guaranteed not to live-lock. You can infer from <a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/254392.html" target="_blank">erratum</a> and <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka8404.html" target="_blank">FAQs</a> that at least some of the ARM implementations likely do have some kind of cache control delay within which your loop should fit, but that's about all I can find.<div><br></div><div><div>The lack of documented rules is perhaps only a theoretical concern, as if you follow all of the rules collected from other architectures, it's a pretty sure bet you'll be as safe as possible on ARM and PPC too. The only question is if it's safe to be more lax, and e.g. allowing different branch sequences, or not. (And of course that'd only be interesting if there were an actual performance advantage to doing so).</div><div><br></div><div>But, it is certainly unfortunate that there appears to be no actual specification which a user can rely on, as MIPS has.</div></div></div></blockquote><div><br></div><div>True, we should probably get that clarified. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>BTW, on another note, the "no taken branches" restriction from Alpha is explained like this:</div><div><div>"Branch instructions between the LDx_L/STx_C pair may be mispredicted, introducing load and store instructions that evict the locked cache block. To prevent that from happening, there is a bit in the instruction fetcher that is set for a LDx_L reference and cleared on any other memory reference. When this bit is set, the branch predictor predicts all branches to fall through."</div><div><br></div><div>That seems like an interesting detail. I now wonder if other architectures have a similar issue with a mis-predicted branch in the LL/SC loop, and how they deal with it.</div></div></div></div></blockquote><div><br></div><div>I'm not sure we care about Alpha, the memory model sure doesn't ;-)</div></div></div></div>