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

Reply via email to