On 06/22/11 14:29, Steve Reinhardt wrote: > On Wed, Jun 22, 2011 at 2:24 PM, nathan binkert <[email protected]> wrote: > >>> My guess (and assumption) is that the *res update in AtomicSimpleCPU is >> just >>> due to a different code factorization, or could be moved into >> writeBytes(), >>> to make all the templates identical. Then they could be factored out of >> the >>> CPU models. If I'm wrong, then you're right, but I'm not convinced I'm >>> wrong... >> I'm not objecting to this. I this really what this patch is all about >> though? >> > Eliminating redundant code is not the point of this patch, just a happy side > effect. > > The real goal is to avoid either: > 1. having to add a new template instantiation to each CPU model every time > an ISA wants to use a different type for memory values or > 2. having some weird restrictions about which types can be used to access > memory and which types can't, and requiring ISA descriptions to have > explicit casts from the latter to the former > > I think you're saying that we could achieve #1 by putting the template > definitions in a header and letting them get instantiated automatically. > Not sure why we're not doing that to begin with... historical, I guess. > That's a fine solution also if it really works. > > That said, there is a lot of redundancy that would be nice to factor out, > and this would also make the ExecContext interface narrower, which is a good > thing. > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
I'm going to hijack the thread a bit and talk about two possible templating schemes. One would be what we already had where we just move the templates into header files. That has two main advantages. First, the CPUs could implement them differently if they really wanted/needed to. That's not a great reason since I can't think of any reason that would be useful, and also type based decisions are more an ISA level thing than a CPU level thing. CPUs should deal in bytes of memory primarily and not interpret them. The second benefit is that the trace stuff is handled by the CPU where it's traditionally been done before and not partially co-opted by the instructions. The instructions do some tracing work too by recording their result, so that's not a huge deal either. A downside is that the exec context is wider like Steve was saying, which means more stuff everywhere it appears, more complication, etc. Another scheme would be to have the templates but make them part of the instructions. This has the benefit that they really become helper functions instead of an interface layer on top of readBytes and writeBytes, and the instructions could define them however they want if they need something different. All the ISAs and (indirectly) all the CPUs would inherit one implementation in one place. These functions would also have access to the trace data structure implicitly, something that would have to be passed into a function external to the StaticInsts and the CPU. The one real downside to this is that the tracing moves out of the CPU and might get a little weirder to implement in some cases which aren't immediately obvious to me. Of these two I would probably prefer the second. We should decide what we really want before I take another pass at this. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
