Re: [gem5-dev] [m5-dev] src/dest detection in the ISA descriptions

2011-05-28 Thread Gabriel Michael Black
ping Quoting Gabe Black : Ping... On 05/05/11 10:38, Steve Reinhardt wrote: On Wed, May 4, 2011 at 2:25 PM, Gabe Black wrote: Did that make sense? I see how that could work... I think I was more puzzled by how you would figure out that for (int i = 0; i < 7; i++) Dest.bytes[

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-05-15 Thread Gabe Black
Ping... On 05/05/11 10:38, Steve Reinhardt wrote: > On Wed, May 4, 2011 at 2:25 PM, Gabe Black wrote: > >> Did that make sense? > > I see how that could work... I think I was more puzzled by how you would > figure out that > > for (int i = 0; i < 7; i++) > Dest.bytes[i] = Source1.byte

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-05-05 Thread Steve Reinhardt
On Wed, May 4, 2011 at 2:25 PM, Gabe Black wrote: > Did that make sense? I see how that could work... I think I was more puzzled by how you would figure out that for (int i = 0; i < 7; i++) Dest.bytes[i] = Source1.bytes[i] + Source2.bytes[i]; overwrote all of Dest, but for (i

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-05-04 Thread Gabe Black
On 04/27/11 22:14, Gabe Black wrote: > My idea is to be able to inherit from the standard op types like > IntRegOperand and allow them to install more than one index and/or > change how they're declared, read, and written. So say for example you > had a 128 bit wide SIMD instruction

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-27 Thread Gabe Black
My idea is to be able to inherit from the standard op types like IntRegOperand and allow them to install more than one index and/or change how they're declared, read, and written. So say for example you had a 128 bit wide SIMD instruction operating on four floating point r

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-27 Thread Steve Reinhardt
On Wed, Apr 27, 2011 at 10:14 AM, Gabe Black wrote: > On 04/27/11 08:02, Steve Reinhardt wrote: > > On Wed, Apr 27, 2011 at 1:21 AM, Gabe Black > wrote: > > > >>> Perhaps the heuristics could simply be extended to deal with > >>> structure field accesses... if the thing after the symbol is a "."

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-27 Thread Gabe Black
On 04/27/11 08:02, Steve Reinhardt wrote: > On Wed, Apr 27, 2011 at 1:21 AM, Gabe Black wrote: > >> The XML thing is an interesting possibility, and it avoids having to >> make a whole new thing that understands C++. It would still mean we'd >> have to make a whole new thing that understands XML (

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-27 Thread Steve Reinhardt
On Wed, Apr 27, 2011 at 1:21 AM, Gabe Black wrote: > The XML thing is an interesting possibility, and it avoids having to > make a whole new thing that understands C++. It would still mean we'd > have to make a whole new thing that understands XML (which is much > easier), but then there's the ch

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-27 Thread Gabe Black
>> Before I mentioned using @, and I have a patch that makes that change in >> the parser and in all the ISA descs. It was less painful than you may >> assume. >> > I haven't looked at your patches yet... is the main point of switching from > . to @ to allow structure field accesses? Basically. I

Re: [m5-dev] src/dest detection in the ISA descriptions

2011-04-26 Thread Steve Reinhardt
On Tue, Apr 26, 2011 at 9:45 PM, Gabriel Michael Black < gbl...@eecs.umich.edu> wrote: > People not working with the ISA parser can stop here. > Here I am :-). > Before I mentioned using @, and I have a patch that makes that change in > the parser and in all the ISA descs. It was less painful t

[m5-dev] src/dest detection in the ISA descriptions

2011-04-26 Thread Gabriel Michael Black
People not working with the ISA parser can stop here. I have my changes out for review which remove the special handling of the twin data types which are used for twin loads and stores in SPARC, and generally demote integers and floating point values to simply be opaque types. That's not qu