Part of the problem is that those programs should work in the first place. I compiled mcf and it crashed, and I wasn't able to compile twolf and one other benchmark which I'm forgetting right now. We could verify that it still crashes in the same way, and I guess that would help determine if something changed that wasn't supposed to..
Gabe Quoting nathan binkert <[email protected]>: > Regarding regressions, can someone just compile a few programs and > create regressions out of them? > > Nate > > > On Tue, Jun 30, 2009 at 3:24 PM, Gabriel Michael > Black<[email protected]> wrote: >> This is fine, except it doesn't really address the op_rd and op_wb >> issue, ie. having different code to read and write the register >> arguments in the execute method. I'd like to have that fixed as soon >> since it's holding up some other register file work I'm doing. It's >> not critical that that gets done by any particular time, but I'd >> rather not have it bit rot on the vine. >> >> That aside, I have a number of changes which move around and >> simplify/reduce the isa description for ARM. If there are going to be >> any big changes it would be a good idea for me to check in what I've >> got so we don't have to try to merge things later. >> >> The reason I haven't checked those in right now is that I wanted to >> wait until there was better testing for ARM so that I didn't silently >> break something we wouldn't discover until later. The hello world >> regression I added helps, but it misses a lot. The binary you sent, >> Jack, actually did a good job of finding some other bugs I had >> introduced, I think partially because it uses uclib instead of glib. I >> can check those in without the additional checking if that's what >> people think is best. >> >> Gabe >> >> Quoting Jack Whitham <[email protected]>: >> >>> On Tue, Jun 30, 2009 at 09:17:37AM -0700, Steve Reinhardt wrote: >>>> Does this make sense? Does anyone want to volunteer to take a crack at >>>> this? How well do you know Python, Jack? ;-) >>> >>> This is something I could do. >>> >>> At the moment, my priority is to get O3 working for ARM. (This is for >>> some research; I really want an O3 CPU that runs fully predicated code.) >>> But I am keen to do this the "right" way so my modifications can be >>> part of M5. >>> >>>> 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. >>> >>> Ok, this sounds like a reasonable way to do it. That could inspect both >>> rD and the condition field and change behaviour appropriately. I'll get >>> back to you if I have questions about this (or hit a problem). >>> >>> >>> -- >>> Jack Whitham >>> [email protected] >>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
