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
