To clarify, I meant to say to " I will then switch back and forth between the workload/CPU pairs* in a big loop" Thanks, Steve On Wed, Aug 17, 2011 at 1:08 PM, Stevenson Jian <[email protected]>wrote:
> 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
