Steve Reinhardt wrote:
>
>
> On Mon, Jun 29, 2009 at 7:07 PM, Gabriel Michael Black 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Quoting Steve Reinhardt <[email protected] <mailto:[email protected]>>:
>
>     > On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black <
>     > [email protected] <mailto:[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.
>
>
> Yea, I thought we'd agreed to push as much as possible into the decoder.

Yep. Sounds good to me.

>  
>
>     Have you thought of any way to get the isa_parser to cooperate as far
>     as the operand reading/writing code?
>
>
> Not really... haven't put much time into it.  I know the issue is that 
> the simplistic regex method of identifying sources and dests will not 
> handle conditional updates; is there a way we can override that in 
> these cases?
>
> Steve
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>   

That I think we can handle that part similarly to other ISAs, although 
we may run into surprises. I was talking about reading and writing 
registers that may be R15 without ending up with a cross product sprawl 
of instruction variations.

Gabe
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to