I'm going to commit my changes and presume that anything that breaks will end up being fixed with whatever else may be broken now. I don't think these changes are likely that broken so it should be ok.
Gabe Gabriel Michael Black wrote: > 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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
