It would help with M5's performance and probably the simple CPUs performance, but that would effectively behave like a cache and have all the same complications, specifically self modifying code. It would be nice to deal with that in a smart way since the predecoder also acts like a small cache for x86 and is currently flushed and restarted at the beginning of every instruction, even for 8 single byte instructions in the same 64 bit chunk of memory. There may actually be a subtle bug in x86, as a matter of fact, because the end of a segment might fall within the chunk of memory fetched for the predecoder. That's not likely to show up in practice because segmentation isn't used like that much, but it would still be wrong.
Gabe Korey Sewell 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 ??? > > 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? > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
