Quoting Ali Saidi <[email protected]>:
On Tue, 13 Jul 2010 11:20:26 -0700, Gabe Black <[email protected]>
wrote:
This also brings up another idea I've been rolling around for a while.
Why is all the control state local to the miscregfile/it's decendant the
ISA object? Why don't we put control state that matters to the TLB, or
at least a copy of it, in the TLB itself and then communicate it back
and forth as necessary? That would be easier to code (or at least I'm
guessing) since you'd just have the state right there, faster since it
avoids calling out for it, and would more conceptually match real
hardware where all the control state isn't put in one huge blob
someplace. The same thing could be done for other structures like the
interrupt controller, and maybe the decoder and/or predecoder. Speaking
of the decoder, it would be nice to make that a little stateful as well.
As it is in, say, ARM, the decoder has to rediscover what mode it's in
over and over. I'm guessing it would be better to explicitly switch it's
state (or it entirely) when changing modes instead, although that might
add a fair amount of complexity. Perhaps the decoder should be an object
instead of a bare function? I'm less sure how that would work. It could,
hypothetically, allow us to return the two PC bits commandeered to
signal the mode.
At least for ARM, I intended to have the TLB cache the various translation
state (CPSR, SCTLR) and
invalidate the cache on CPSR, SCTLR writes to that it wouldn't have to
access those misc registers every cycle. I think part of the issue is that
those registers are accessed by a variety of things so it isn't necessarily
better for it to live in the TLB. I don't know that there is anything
preventing the misc register accesses from calling another function on the
tlb to update registers when they're written. Couldn't the same thing be
used for these other suggestions? Assuming that we make the decoder an
object (which I don't think should be too hard), in the case of changing
the state of the cpu couldn't the misc register write call
tc->decoder->changeState(foo);
Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
That's a reasonable approach, especially for CPSR which (for people
that don't know ARM) has a bunch of execution level control state like
which endianness to use for loads/stores. On the other hand, though,
there's control state that only applies to translation like what ASI
to use, segmentation limits and attributes in x86 which aren't
directly accessible most of the time except with hardware
virtualization extensions, etc. Then it makes sense to stick it in the
TLB and make the ISA object ask for it when it needs it. Fortunately
all these things are ISA specific objects, I think, and can be
designed to work together.
Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
