Thanks for the response. I plan to work on the simple_atomic cpu first. To perform timesharing on the simple atomic cpu, according to http://gem5.org/Multiprogrammed_workloads, I will "simply create a system with multiple CPUs and assign a different workload object to each CPU's workload parameter" where each workload is a different benchmark. I will then switch back and forth between the workloads in a big loop. Would you mind describing the _asid a little bit more? The comment simply states "The address space ID." To clarify, is the address space ID going to be unique to every workload? For example, will the space ID of a previous workload every be reassigned to the new workload? Thanks. Steve On Wed, Aug 17, 2011 at 12:35 PM, Steve Reinhardt <[email protected]> wrote:
> How are you doing time-sharing in SE mode? > > You could probably use the _asid field to distinguish virtual addresses > from different processes. > > Steve > > > On Wed, Aug 17, 2011 at 9:11 AM, Stevenson Jian > <[email protected]>wrote: > >> Thanks, just a followup on what I am trying to do. I am trying to identify >> some properties of individual instructions in regards to cache access. >> However, I am doing it in a time-sharing context where the same applications >> will be switch in and out of the CPU. Therefore, virtual address of the >> instructions making the load/store will not suffice. Using the physical >> address is one way of identifying the instructions uniquely. Is there >> another way to go about doing it in M5? If not, could someone point to where >> I should look to go about translating the virtual PC to physical instruction >> address? I am using SE. >> Thanks, >> Steve >> >> >> On Wed, Aug 17, 2011 at 10:55 AM, Stevenson Jian <[email protected] >> > wrote: >> >>> Oh I see, _paddr and _vaddr are for instruction fetches, while _pc is for >>> regular loads and stores. Can someone confirm for me whether for a packet >>> accessing the cache, packet->request->getPC() returns a physical address or >>> virtual address of the instruction that is making the load/store? How would >>> I verify which one it is? If it returns a virtual address, how do I >>> translate the virtual address to a physical address in m5? >>> Thanks, >>> Steve >>> >>> >>> On Wed, Aug 17, 2011 at 12:43 AM, Steve Reinhardt <[email protected]>wrote: >>> >>>> For loads and stores, the pc is obviously not related to the vaddr or >>>> paddr. >>>> >>>> For instruction fetches, you're probably best off just ignoring the pc; >>>> the only reason it's there is because the same packet structure is shared >>>> between fetches and loads/stores. >>>> >>>> Steve >>>> >>>> >>>> On Tue, Aug 16, 2011 at 9:43 PM, Stevenson Jian < >>>> [email protected]> wrote: >>>> >>>>> Hi, >>>>> Looking at src/mem/request.hh, I see that there are the following 3 >>>>> methods: getPC(), getPaddr(), and getVaddr(); The description of each are >>>>> given in the following: >>>>> _pc: program counter of initiating access; for tracing/debugging >>>>> _paddr: The physical address of the request. >>>>> _vaddr: The virtual address of the request. >>>>> >>>>> So what exactly is _pc? If _pc holds the virtual address to the >>>>> instruction sending out the request to access the cache, then it should be >>>>> equal to _vaddr. If _pc holds the physical address to the instruction >>>>> sending out the request to access the cache, then it should be equal to >>>>> _paddr. I am confused why there are 3 of them, pc, paddr, and vaddr, since >>>>> one of them has to be a repeat... >>>>> Thanks, >>>>> Steve >>>>> >>>>> On Tue, Aug 16, 2011 at 8:14 PM, <[email protected]> wrote: >>>>> >>>>>> If I remember it correctly, the addresses exposed to cache modules are >>>>>> all physical addresses. >>>>>> >>>>>> Leonard >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On , Stevenson Jian <[email protected]> wrote: >>>>>> > Hi,I would like to trace the physical address of the instruction >>>>>> that is accessing the cache. I see that there is in the packet going from >>>>>> the CPU to the cache there is the PacketPtr->getPC() method. I assume >>>>>> that >>>>>> this is the virtual address of the instruction reading the cache. >>>>>> However, >>>>>> what would be the best way to go about getting the physical address of >>>>>> the >>>>>> instruction accessing the cache? >>>>>> > >>>>>> > Thanks a lot of your help, >>>>>> > Steve >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> gem5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
