Kevin Lawton wrote:
> For the moment, forget about the physical page holding
> currently executing code, and any linear addresses which
> map to it. They are handled differently.
I'm not sure this is necessarily a good idea, as it means
that every time the execution flow crosses a page boundary,
it *must* trap (otherwise the monitor wouldn't notice when
the current page changes ...). Suppose you have an otherwise
harmless, but very speed-critical inner loop that just happens
to cross a page boundary ...
I'd prefer not having to treat the 'current' page specially.
Why can't we simply have *multiple* special mappings in the
I TLB cache? Sure, that cache will overflow, but whenever
that happens, we get a fault that we can then handle.
> Option (2) has the benefit of allowing both reads and writes to
> occur to vcode pages without generating an exception. The tradeoff
> is that we only have the option to dump an entire vcode page
> if the page is dirty.
>
> Option (1) incurrs a write exception, but we have the option of
> emulating the instruction (and write) so we can possible keep
> some or all of the vcode cache for that page intact.
>
> I'm not sure which of these is best yet. Any feedback welcome.
Hard to say without measuring. Maybe an adaptive strategy is best,
i.e. start out with option (1), but if too many faults happen in
sequence, fall over to option (2) ?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
