>. 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.
If you dont mind, can you briefly elaborate on pros/cons of using a
packet-interface instead
> 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.
For applications with self modifying code, I see your point there.
I'll have to put a "todo/revis
On Thu, May 14, 2009 at 5:46 PM, 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 replac
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
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 fet
