On Tue, Jul 13, 2010 at 11:20 AM, Gabe Black <[email protected]> wrote: > I can't say it was -the- reason, but one reason is that the TLBs as is > don't actually send the packets for the CPU, so they can't split > anything into multiple transactions easily. I'm intrigued by the idea of > putting the TLB behind a port or port like interface, maybe even > exporting the TLB outside of the CPU's guts and putting it inline with > external accesses.
I see from your subsequent email that you've already thought of some drawbacks to this... I agree it's nice in the common case, but has the problem that it constrains the pipeline design perhaps more than you really want to. We're probably better off finding a way to embed two physical addresses in a Request. > There are three problems with that, though. First, > the TLB would likely need some alternative way to pass a fault back to > the CPU. Maybe the request would have a fault pointer field? Adding a field to contain a fault code seems pretty simple. > Second, the > TLB is the thing that recognizes when an access is to memory mapped > control state within the CPU. It would need a way to communicate with > the CPU to get/set those values. Or better yet just to communicate back to the CPU that it needs to access its internal state. Is it possible to remap this memory-mapped state to virtual addresses? If not, we could even move that check out of the TLB and into the CPU (not saying that's the best thing, just that it would be a possibility). > Third, the control state that actually > -runs- the TLB is maintained by the CPU, namely what mode it's in, etc. I think you're on to something with the discussion below... > 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. When I discovered that your x86 implementation has 200+ miscregs I began to think that there was a problem here :-). I agree that finding a way to spread it out makes sense. Just putting the indirection in readMiscRegs/writeMiscRegs would be one way to do it, I guess, but it would be nice to clean things up further to avoid this giant linear index space (like you were alluding to in a previous email). > 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. The predecoder is already stateful, right? I'm not so convinced about the decoder; you still need a way to externalize the state that influences the decode process to allow the decode cache to work. But it seems like you could easily build a stateful decoder if you wanted by calling the stateless decode function via an object that contains the additional state. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
