This sounds great to me. One question: does this mean the Twin*_t can be isolated to SPARC-specific files (assuming that's the only ISA that uses them)? I'm interested partly just because it's ugly having those all over the place, but more generally as a proof case that it's possible to define ISA-specific types and have them supported cleanly now.
Steve On Mon, Jun 27, 2011 at 2:29 AM, Gabe Black <[email protected]> wrote: > Since I tend to do this stuff in spurts these days and going down the > wrong path could cost a lot of time, I think it's a good idea to make > sure everybody knows what the current plan is as far as this series of > patches and what the status is. Speak up now and make life easier for > everybody (ok, mostly me). > > Plan: > > The current plan is to have a set of helper function templates defined > in a header file which provide a convenience shim on top of the > readBytes and writeBytes functions on the exec contexts. I have an > atomic and timing version of read and write since they do somewhat > different things, and a function that extracts the result from a timing > mode read response. These correct endianness and update the trace data. > These are in a file called memhelpers.hh in arch/generic/ and are > included in arch specific headers for each ISA. All ISAs except x86 just > import them into their own namespace, but x86 does things a little > differently to handle run time variation in access size. > > Once that's in place, I can layer my previous changes on top of it that > remove the special case handling of floating point and integer operands > of particular sizes and signedness in favor of arbitrary types. It will > no longer be necessary to cast Mem operands to unsigned whatevers since > the helper templates will take care of all that. > > Status: > > I have the helper functions implemented and integrated into each ISA. I > realize now that I need to touch up the x86 header since it doesn't need > to include the generic one, so I'll do that before I send it to anybody. > > I found a bug in the store initiate acc template, and when I fix it it > changes the stats. There's a good chance it would affect X86_FS being > able to run on O3, so it's nice to get that out of the way. The > regressions are running right now. > > Once I have the fix and regressions ready and the helper function thing > touched up, then I'll need to rebase the other patches in this batch on > top of them. This should be pretty trivial since I think they may just > apply directly. Then I need to rebase my original set of patches which > generalized the operand type mechanism. This will be trickier since > there will be a lot of conflicts, but conceptually it will be simple. > > Then once all that is done, I'll pass it by Google again, then assuming > that's all ok send it up for review again, and then if everybody is > happy with everything get it in the tree. > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
