On Monday 27 October 2014 14:57:57 Joel Hestness via gem5-dev wrote: > There have been some statements about the backing store being > sequentially consistent or encouraging/reinforcing such a model. I may be > overlooking something, but I'm pretty sure that's not true. The consistency > model is enforced by the core load-store queues, which issue requests to > the RubyPorts. Since the RubyPort access_phys_mem causes memory accesses to > read/write the backing store at the end of the cache access rather than > when the cache is updated, the only thing that changes is the timing of the > memory access' atomic read or modify portion. However, the ordering of > accesses, as enforced by the LSQs, will remain largely unchanged. You can > still have race conditions in buggy simulated code if, for instance, > necessary fences are missing. I'm pretty sure this means that using the > Ruby backing store enforces the same consistency model as enforced by the > LSQs, and that model can be as strong or weak as desired.
I have a very remote view off all this, but what this boils down to is that with a flat backing store, there can be only a single global value per addressed byte. That means that different observers (functional readers in this case) will see the same value for the same address at a single point in time. This means that the memory is /atomic/, more precisely, multi-copy atomic. Before people start bashing weak memory models, please be aware that there are several cases in /strong/ memory models, where this condition does not hold: store to load forwarding, and transactional memory are the most common examples. Having /only/ a single flat backing store makes it very hard to model such effects properly. (This is from my experience with PTLsim / Marss86.) IMHO, functional reads should read the latest non-speculative write to a specific memory location in the system. That way, the local write that may not have been pushed to the flat backing store is accounted for. I'd think that the suggested treatment of functional writes is fine. -- Sincerely, Stephan Stephan Diestelhorst Staff Engineer, ARM R&D Systems -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
