nathan binkert wrote: >> The ExecContext is only for instructions when they execute (although I'm >> not 100% sure that's all it could be used for). I thought of this >> approach, but it doesn't work because the thing that puts together the >> fetch request would have to know the actual PC. If it gets the filtered >> one like you're proposing, then the PAL bit will be masked out and the >> TLB will never see it. From experience, this makes the ALPHA_FS >> regressions just sit there and miss in the ITLB over and over. If there >> was some other way to communicate PAL-ness to the TLB, then yes I think >> that scheme would likely work. >> > What I'm saying is that we need a PC object that has the real PC (and > whatever else is necessary) inside of it, and ISA dependent code can > use one accessor to get the unfiltered PC and independent code can use > the filter version, but what we pass around is an object, not the > word. >
I think that would work, but I wanted to take the opportunity to streamline the request object a little instead of bulk it up. > >> I'm not sure I follow. The PCState object for, say, Alpha is two Addrs, >> the PC and the NPC. For ARM it's the PC, NPC, microPC, nextMicroPC, >> flags, and nextFlags, for SPARC its the PC, NPC, microPC, and >> nextMicroPC. I don't see how that can be broken up generically and not >> just undo the fact that there's a PCState object. I also don't see how >> that would address any of the problems above. >> > > So, the Alpha PC object would contain just an Addr, and there would be > two PC objects (PC and NPC) in the PCState object. For arm, the PC > object would have (PC and microPC, and flags) and there would again be > two (PC and NPC). If you're worried about copying unnecessary > information around, this would reduce the amount. (Though, perhaps > this is premature optimization). > That's better from the perspective that it's not as Alpha specific, but still no other ISA cares about the PC in that way, we'd be carrying around several (as many as 4, I think) extra uint64_ts, and only one bit actually matters. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
