On Tue, Jun 30, 2009 at 2:14 AM, Jack Whitham <jack-m5...@cs.york.ac.uk>wrote:
> > 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. > I agree... I think the "smarter single class" approach is better too. What would be really nice is if we could avoid modifying src/cpu/static_inst.hh as well, and instead find a way to have the constructor for each StaticInst-derived class set the flags fields (IsControl, IsCondControl, and any others) based on whether r15 is a dest for this particular instance and whether the condition is "always" or not. This would require some hacking on isa_parser.py since right now all you can do is pass in the name of a flag to get set to 'true'. Maybe we could extend the flag processing so that you can pass in a tuple where the first element is the string name of a flag and the second element is the name of a function that returns a bool that gets called to initialize the flag, then set this up to be a non-virtual member function that can look at the dest regs and see if any of them are r15, etc. This would work as it stands since it just so happens that the register arrays get set up in the constructor before the flags get initialized, but it would be good to put a comment in InstObjParams.__init__ if that becomes a functional requirement. Does this make sense? Does anyone want to volunteer to take a crack at this? How well do you know Python, Jack? ;-) Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
