On Fri, Oct 8, 2010 at 7:33 PM, Bill Holder <hold...@us.ibm.com> wrote:
> I believe the reason for allowing some leeway has to do > with hardware design concepts for things like pipelining, > "reach ahead" and "out-of-order execution" - with the > hardware in essence "speculatively" performing certain > operations ahead of time or in parallel (to maximize > utilization and throughput), the potential exists for the > processor "thinking" something is going to be referenced, > and performing reference recording on the fetch from > storage, only to find out later that that path wasn't > really taken. To correct such apparent overindication of > reference would mean tracking "de-referencing" and having > to worry about (and serializing against) reference > recording actions from other processors. You could well > ask "why not defer reference recording until the path > decision is made?", but I would answer that doing so would > break the pipeline and constrain the design of the > processor / storage interface in ways that would defeat > the whole purpose. I would even say it's better from a paging perspective. If the code makes a U-turn just at the end of the page and causes the CPU to decode the next instruction already, it would be annoying if the OS would take that 2nd page away because nobody needs it anyway... assuming that such a case would also cause a page fault? Just don't bring your reference bits into court as evidence... ;-) | Rob
