Quoting Steve Reinhardt <[email protected]>: > On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black < > [email protected]> wrote: > >> That is true, but I think what he's talking about is when the CPSR >> doesn't actually matter at all since the condition is "always". I >> don't know what the best way to do that would be, but one possibility >> would be to decode each instruction as two variants, one that's >> conditional and one that isn't. At this point we'd have four variants >> of a number of instructions (conditional X branch), but since >> unconditional is probably the most common form and we'd save the >> condition check in those versions it's likely worth it from a >> performance perspective too. >> > > I've only been half-following this thread, but I believe Gabe is right: you > need StaticInst objects that claim to be different things > (branch/non-branch, conditional/unconditional, dependent/independent of > flags, etc.) based on the details of the encoding. Whether you do this by > decoding to different classes (like most ISAs with normal branches do) or > just having more-complex-than-usual methods on a single class (as I think > Jack has already suggested) is just a tradeoff of decoder complexity vs. > runtime performance, as far as I can tell. > > Steve >
In this case it's also a question of where the decision is made. If it's in the decoder then it's isolated to that ISA, and if not it's in the CPU(s) for all ISAs. That wouldn't be horrible, but it would be really nice to avoid. Have you thought of any way to get the isa_parser to cooperate as far as the operand reading/writing code? Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
