Re: [m5-dev] hwrei
I looked into this just now, and it should be pretty much trivially easy to do things like I described below. Gabe Quoting Gabriel Michael Black [EMAIL PROTECTED]: Actually, the stat is pretty ISA specific as well. I'll have to remember to look at how things are structured, but it might make sense to stick the kernel stat object onto the system or cpu objects and get at it through some path in the thread context. If those stats are per system then I think there's a function that'll get you most of the way there. If it's per cpu I'm not sure if you can get at the cpu you're on rather than just cpu 2 for instance. Either way it shouldn't take too much to let the ISA specific functions outside of the cpu modify the kernel stats through an ISA agnostic interface like a thread context or something. Gabe On Mon, 21 Jul 2008, Steve Reinhardt wrote: On Mon, Jul 21, 2008 at 2:31 PM, nathan binkert [EMAIL PROTECTED] wrote: \ I'm not sure about simPalCheck, but I suspect the reasons were similar. It was hard to get around having to do things in the CPU if the kernelStats needed to be incremented. I never really used the kernelStats much, but I think Nate was fairly interested in it. I created kernelStats to generalize things a little bit. That said, if one of these stats causes a call that's annoying, move it into the ISA, or if really necessary, get rid of it. Few stats are really necessary, though many are helpful for debugging. Another option would be to create a method on the CPU just to increment the stat (which is ISA independent), and then call that from the Alpha-specific hwrei and simPalCheck methods which you can then move into the Alpha-specific part of the code. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] hwrei
Actually, the stat is pretty ISA specific as well. I'll have to remember to look at how things are structured, but it might make sense to stick the kernel stat object onto the system or cpu objects and get at it through some path in the thread context. If those stats are per system then I think there's a function that'll get you most of the way there. If it's per cpu I'm not sure if you can get at the cpu you're on rather than just cpu 2 for instance. Either way it shouldn't take too much to let the ISA specific functions outside of the cpu modify the kernel stats through an ISA agnostic interface like a thread context or something. Gabe On Mon, 21 Jul 2008, Steve Reinhardt wrote: On Mon, Jul 21, 2008 at 2:31 PM, nathan binkert [EMAIL PROTECTED] wrote: \ I'm not sure about simPalCheck, but I suspect the reasons were similar. It was hard to get around having to do things in the CPU if the kernelStats needed to be incremented. I never really used the kernelStats much, but I think Nate was fairly interested in it. I created kernelStats to generalize things a little bit. That said, if one of these stats causes a call that's annoying, move it into the ISA, or if really necessary, get rid of it. Few stats are really necessary, though many are helpful for debugging. Another option would be to create a method on the CPU just to increment the stat (which is ISA independent), and then call that from the Alpha-specific hwrei and simPalCheck methods which you can then move into the Alpha-specific part of the code. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] hwrei
Anybody? I probably won't have a lot of M5 time until maybe Thursday, but I'd like to have a discussion going by then about these two functions if it's warranted. I'll assume if nobody says anything by then I should do whatever I want to push those out of the CPU. Gabe On Thu, 10 Jul 2008, Gabe Black wrote: Along these lines, simPalCheck probably should get moved at the least into a function which takes a thread context and lives in arch/alpha. I could imagine how it -might- need to be specialized per CPU, but I can't convince myself that's the case. Gabe Gabe Black wrote: One area where I had to use #if THE_ISA == was with the hwrei function in the dynamic instruction class and in the CPU. Looking at the code, it seems like there's nothing special going on and that should all be put into an instruction. I don't really know the semantics of the instruction or why things were done this way in the first place though, so I thought I'd ask if there's any reason it should stay as it is. The one possible reason I can see is that there's a stat that gets incremented for that instruction which might be hard to do otherwise, but I have to imagine it's not critically important. It also seems like something the ISA should manage and that shouldn't be hard coded into the CPU. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] hwrei
Hi Gabe, Regarding hwrei, I believe that you're correct, it would be difficult to increment the stat outside of the CPU. If I remember correctly that was the main reason I left the function in the CPU. I'm not sure about simPalCheck, but I suspect the reasons were similar. It was hard to get around having to do things in the CPU if the kernelStats needed to be incremented. I never really used the kernelStats much, but I think Nate was fairly interested in it. Kevin Quoting Gabriel Michael Black [EMAIL PROTECTED]: Anybody? I probably won't have a lot of M5 time until maybe Thursday, but I'd like to have a discussion going by then about these two functions if it's warranted. I'll assume if nobody says anything by then I should do whatever I want to push those out of the CPU. Gabe On Thu, 10 Jul 2008, Gabe Black wrote: Along these lines, simPalCheck probably should get moved at the least into a function which takes a thread context and lives in arch/alpha. I could imagine how it -might- need to be specialized per CPU, but I can't convince myself that's the case. Gabe Gabe Black wrote: One area where I had to use #if THE_ISA == was with the hwrei function in the dynamic instruction class and in the CPU. Looking at the code, it seems like there's nothing special going on and that should all be put into an instruction. I don't really know the semantics of the instruction or why things were done this way in the first place though, so I thought I'd ask if there's any reason it should stay as it is. The one possible reason I can see is that there's a stat that gets incremented for that instruction which might be hard to do otherwise, but I have to imagine it's not critically important. It also seems like something the ISA should manage and that shouldn't be hard coded into the CPU. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] hwrei
Along these lines, simPalCheck probably should get moved at the least into a function which takes a thread context and lives in arch/alpha. I could imagine how it -might- need to be specialized per CPU, but I can't convince myself that's the case. Gabe Gabe Black wrote: One area where I had to use #if THE_ISA == was with the hwrei function in the dynamic instruction class and in the CPU. Looking at the code, it seems like there's nothing special going on and that should all be put into an instruction. I don't really know the semantics of the instruction or why things were done this way in the first place though, so I thought I'd ask if there's any reason it should stay as it is. The one possible reason I can see is that there's a stat that gets incremented for that instruction which might be hard to do otherwise, but I have to imagine it's not critically important. It also seems like something the ISA should manage and that shouldn't be hard coded into the CPU. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
