[PTLsim-devel] Memory consistency

Stephan Diestelhorst
Mon Oct 22 14:41:33 EDT 2007


Hi again,
  as I'm still debugging odd behavios within my multi-core model, I 
was actually wondering about the memory consistency model provided 
with PTLsims default smtcore (ooocore) with ENABLED_SMT defined.

Real x86 hardware supports AFAIK Total-Store-Ordering as the basic 
memory model. (Let's skip nc, wc and odd things) I was wondering, how 
that was enforced with SMT. Inuitively, this would not be necessary, 
as the SMT should just multiplex front-end and back-end structures 
and essentially maintains a shared core.

However, the LSQ is not shared among ThreadContexts and 
load-store-aliasing is hence checked separatly for each ThreadContext 
in issueload.

This however leads to the following problem, with two threads:
Initially, A=B=0
Thread 0: store A:= 1; store B:=1;
Thread 1: load B; load A;

For some reason, the actual uops might be interleaved as such within 
the issue-q:
store A:=1; store B:=1; load B; load A;

Then, load A may issue first, as it checks _Thread 1's_ LSQ and 
doesn't find any aliasing store and load B might be waiting for some 
input operand. Given that we may end up with the following order of 
accesses to PTLsim's memory:

load A; store A:=1; store B:=1; load B;

Which results in the illegal result A=0 and B=1.

Please note that we don't need any fence to ensure ordering here. The 
underlying consistency model should enforce the mentioned guarantess.

Please note that this comes from a fairly uneducated view of PTLsim. 
I'm happy to learn about anything I'm missing here!

Many thanks,
  Stephan

-- 
Stephan Diestelhorst, AMD Operating System Research Center
stephan.diestelhorst at amd.com, Tel.   (AMD: 8-4903)

AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, 
Deutschland
Registergericht Dresden: HRA 4896

vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, 
Delaware, USA)
Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy




More information about the PTLsim-devel mailing list