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

Reply via email to