On 11 August 2015 at 10:22, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Tue, 2015-08-11 at 08:54 +0100, Alex Bennée wrote: >> >> > How do you handle the memory model ? IE , ARM and PPC are OO while x86 >> > is (mostly) in order, so emulating ARM/PPC on x86 is fine but emulating >> > x86 on ARM or PPC will lead to problems unless you generate memory >> > barriers with every load/store .. >> >> This is the next chunk of work. We have Alvise's LL/SC patches which >> allow us to do proper emulation of ARMs Load/store exclusive behaviour >> and any weak order target will have to use such constructs. > > God no ! You don't want to use ll/sc for dealing with weak ordering, you > want to use barriers... ll/sc will allow you to deal with front-end > things such as atomic inc/dec etc...
Agreed. ll/sc is atomicity, not ordering. (Conversely, barriers and load-acquire/store-release are ordering, not atomicity...) >> Currently the plan is to introduce a barrier TCG op which will translate >> to the strongest backend barrier available. > > I would advocate at least two barriers, full barrier and write barrier, > so at least when emulating ARM or PPC on x86, we don't actually send > fences on every load/stores. Is it possible in some of these combinations to use the load-acquire and store-release instructions rather than explicit barriers? (ARMv8 has those, which I think should be slightly less heavyweight than explicit barriers everywhere, if the semantics line up.) thanks -- PMM
