On Sat, Dec 23, 2000 at 05:46:23PM -0500, Kevin Lawton wrote:
> [EMAIL PROTECTED] wrote:
>
> > Yes, a page fault is still time consuming. However, once a page of
> > code has been translated, the code that calls that page no longer
> > needs to fault for any future invocations.
> >
> > In other words, the scheme I outlined would result in a number of
> > faults proportional to the size of the code, where as the current
> > scheme results in a number of faults proportional to the running time
> > of the code.
> >
> > Since, for the majority of programs, the majority of running time is
> > spent in a few critical loops and functions, I think there would be a
> > large benefit to a translate once, run natively "many times" scheme.
>
>
> This doesn't work either. How do you differentiate what is code
> in a page, data, or junk due to code alignment?
You don't.
Each time there is a fault into a page, the code is translated from
that offset on (I'm assuming this is what plex currently does). The
rest of the page (anything before the position faulted at, or anything
after a static jmp instruction) would be filled with the one byte INT
3 instruction. Thus, any future jumps to that page into a translated
area would run seamlessly, but any jumps into an untranslated area
would cause a fault. These future faults could cause plex to
translate some of those portions not already translated.
Data in a page shouldn't be a problem - we already need to mask read
accesses to a translated page. The same would apply with this scheme.
"Junk" in the page, would stay mapped as INT3 instructions, but it
wouldn't matter since it can't be read.
-Kevin
