On Thu, May 14, 2009 at 5:46 PM, Korey Sewell <[email protected]> wrote:
> Two things: > 1) I see that there is an instruction flag in the Request Objects > called "INST_FETCH" but I didnt see anywhere in the code where this is > being utilized... Are there plans to use this information for maybe > like cache replacement policies or ??? It's not used much, but it is used some... use cscope to look for isInstFetch(). In particular, Ruby uses it (though I'm not sure in what way). > 2) I just updated the inorder code to fetch instructions at cache > block granularity (64 bytes) instead of instruction granularity (8 > bytes). The O3CPU already does this. I was wondering if the SimpleCPUs > wouldnt also really benefit from this considering if you can avoid > making calls to the memory system for maybe 5 out of every 8 > instructions thats a nice little performance boost. > > The setupFetchRequest code in base.cc forms a request for the size of > the instruction instead of the cache block: > " req->setVirt(0, fetchPC, sizeof(MachInst), Request::INST_FETCH, > threadPC);" > > Does anyone have any thoughts on this on why this may or may not be a > good thing? > The case where you care most about raw performance with SimpleCPU is when you're doing fast-forwarding with AtomicSimpleCPU and no caches, so in that case fetching instructions at cache block granularity doesn't make a whole lot of sense (since there is no cache block granularity then, strictly speaking). If we really wanted to go fast in this case we'd come up with a new memory interface that didn't use packets at all and just went straight to PhysicalMemory, but we haven't felt the need to do that. Plus if all you care about is raw speed you should use some kind of dynamic recompilation system like qemu, or if your host has the same ISA, some kind of direct execution. One reason it might make sense when you do have an icache is that calling the icache on every fetch inflates your icache access statistics, but the downside is that it does violate the "simple" part of SimpleCPU. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
