> > 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".
That's right.
Ali Saidi's comment is also correct, since CPSR does need to
become an "integer register" so it can be renamed.
> > 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.
To add $0.02. It is also worth considering the maintainability of
decoder.isa. For many instructions, you really will need four variants:
- Unconditional, writes to r0..r14
- Unconditional, writes to PC
- Conditional, writes to r0..r14
- Conditional, writes to PC
While I agree that the decoder is the right place to determine which
variant is being used, I also think that it would be best to implement
it without changing decoder.isa, e.g. by changing files in the
isa/formats/ directory, or by adding new features to base_dyn_inst.hh.
Otherwise decoder.isa could grow in size by up to 4 times - it is
already the biggest file in src/arch/arm/isa/ - and this will become a
big problem for anyone fixing bugs or adding new instructions.
--
Jack Whitham
j...@cs.york.ac.uk
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
