I expect so. I don't remember if I tried it, but I think at least the special handling in the ISA parser was taken care of.
Gabe On 06/28/11 10:12, Steve Reinhardt wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
