I think part of the confusion is that ASI are supposed to be the same as ASIDs and they're not. ASID is a OS level concept to tag a specific thread of execution for virtually indexed caches, TLBs, etc since they can have conflicting virtual addresses and the ASID is what makes them unique. We've got some patches that use the ASID information to track blocks through the memory system and will be posting those soon.
ASIs are a SPARC concept where a single process (e.g. ASID) can access a number of different address spaces which permute how the addressing is actually done. For example, some ASIs in SPARC mean that all loads are supposed to reverse endianess, others mean that the translation is supposed to act like another process (for inter-process communication). I think ThreadId is supposed to be the SMT thread, and context id is supposed to be the execution context number. These seems to not be very well defined and could certainly use some cleanup. Ali On 04.10.2013 03:54, Andreas Sandberg wrote: > Hi Everyone, > > I started digging into the memory system to figure out how ASIs and > ASIDs are used. First of all, ASIDs are stored in a separate field in a > Request, while ASIs are a part of the flags field. To add even more > confusion, there is a separate context ID and thread ID field. What I've > found so far is that the concepts are used in, at least, three different > ways: > > * The O3 CPU sets the ASID field in instruction fetch and data fetch > requests to the thread ID. This is zero unless it is simulating an SMT. > > * The Simple CPUs set ASIDs to zero. > > * The in-order CPU has an array to map between TIDs and ASIDs. It's > hard-coded to a unit mapping, which means it behaves like the O3 CPU. > > * ARM sets the ASID field in the TLB. This is set to the value in the > asid field in CONTEXTIDR. I'm not sure if this is ever used as there is > no call to getAsid(). > > * SPARC has its own ASI field as a part of the flags field in Request. > This seems orthogonal to the ASID field. > > * There is a separate thread ID the Request struct. I'm not sure what > it's used for, but it doesn't seem to be related to ASIDs. Why isn't > this used to distinguish between SMT threads? > > Could anyone please clarify how things are used here and how they are > supposed to be used? I find it all terribly confusing. > > Why do we even have a separate notion of ASID and ASI? Why not use the > ASID field for anything to do with architected ASIDs and the thread ID > field to distinguish between threads in an SMT configuration? > > Are ASIDs ever used for anything? There isn't a single reference to the > Request::getAsid() method. > > //Andreas > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev [1] Links: ------ [1] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
