I'll attempt to paint a clearer picture of the situation here (sorry if I
confused earlier):
Typically, a M5 CPU Model wants to do the TLB translation and the Memory
Access on the same cycle. This is triggered by an instruction calling
"execute" (SimpleCPU models) or "initiateAcc" (O3CPU).
In the execute (or initiateAcc) functions of an instruction, there is a call
to read or write which as Steve mentions below interfaces with the CPU
model. Typically, the function will look something like this:
"
Fault Ldl_l::execute(AtomicSimpleCPU *xc,
Trace::InstRecord *traceData) const
{
...
if (fault == NoFault) {
fault = xc->read(EA, (uint32_t&)Mem, memAccessFlags);
Ra = Mem; ;
}
...
}
"
The key thing to note is that the in that read() call the instruction is
giving the size of the access and the flags for that access as arguments.
Those arguments are member variables to the instruction object.
Because the instruction gave the CPU models those local variables, the
AtomicSimpleCPU::read() function has all the info it needs to create the
memory request object and then use that request to make the translation and
finally do the data access.
Now, the problem here is what if you want to do the translation without
doing the read access? You are going to need the size of the access and also
the flags for that access.
So how do we do that and at the same time keep the basic framework that
Steve outlines below?
#1. My current solution was to create accessors for the size() and flags
inside the instruction. That way, the CPU model can just query for that info
upon needing to create a request for that object to do a translation or to
do a data access. However, as Steve notes this kind of goes out of bounds of
how M5 traditionally interfaces with the CPU.
#2. Another solution might be to create a "translate" function for an
instruction and interface similar to how the read function works. The
translate function would need to calculate the effective address based on
the instruction's operands and then it could call back to the CPU model. The
thing that I wouldnt be a fan of is that it would potentially mark the 2nd
place where we are unneccessarily computing the EA (1st is the initiateAcc).
Something like:
"
Fault Ldl_l::translate(AtomicSimpleCPU *xc,
Trace::InstRecord *traceData) const
{
...
if (fault == NoFault) {
fault = xc->translate(EA, (uint32_t&)Mem, memAccessFlags);
}
...
}
"
#3. Anyone else?
So I hope that sums up the problem and what I was trying to do to fix it.
There problem is a better way to do it then #1, but I'm just not sure there
so anybody's thoughts would be welcomed. Once we come to consensus, then
I'll commit the patches.
On Fri, Apr 10, 2009 at 9:34 PM, Steve Reinhardt <[email protected]> wrote:
> I haven't looked at Korey's code in that much detail yet, but in general
> the execution-phase operations have had this kind of structure:
>
> 1. CPU model calls StaticInst method with pointer to execution context
> (e.g., DynInst)
> 2. StaticInst method does what it needs to do, calling back into the
> execution context (and implicitly into the CPU model) in the process
> 3. Method returns fault code and not much else
>
> Unless there are compelling reasons why that doesn't work, I'd like to keep
> that high-level model. Having the CPU model call into the StaticInst to
> read out bits of state (like flags and access size) and then using that info
> to build a request is a different model.
>
> However it's also true (I think) that the ISA descriptions don't see
> Request or Packet structures at all either; they just talk to the CPU model
> in terms of read() and write() (and some other possibly unused functions
> like setEA()). I think that's also a nice level of separation between the
> ISA descriptions and the implementation details that I'd like to keep.
>
> I'll have to look at Korey's code more closely; the isolated patches
> haven't really given me a good picture of what's really going on.
>
> Steve
>
>
> On Fri, Apr 10, 2009 at 6:04 PM, Gabe Black <[email protected]> wrote:
>
>> It could work like this:
>>
>> 1. Instruction calls read with flags.
>> 2. Build a request with the flags and the right size, translate it, and
>> stick it in the dynInst.
>> 3. Actually do the read with the translated request.
>>
>> Or if you want to break it up more:
>>
>> 1. Instruction calls read with flags.
>> 2. Build a request with the flags and the right size, and stick it in
>> the dynInst.
>> 3. Pull out the request, translate it, and stick it back in the dynInst.
>> 4. Actually do the read with the translated request.
>>
>> Korey Sewell wrote:
>> > Well,
>> > I dont think pretending to do the access would work for the TLB
>> > necessarily.
>> >
>> > I can see that the actual size of the access is irrelevant for the TLB
>> > translation (right?). Maybe we can work around that.
>> >
>> > But what about the type of access? That comes from the memory access
>> > flags and the only object that knows those flags is the actual
>> > instruction object. So that seems to be the big problem there.
>> >
>> > On Fri, Apr 10, 2009 at 5:23 PM, nathan binkert <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > > That's a legitimate problem. Would it work to pretend to do the
>> > access
>> > > and save the request object for later?
>> >
>> > I think we should strive to do this.
>> >
>> > Nate
>> > _______________________________________________
>> > m5-dev mailing list
>> > [email protected] <mailto:[email protected]>
>> > http://m5sim.org/mailman/listinfo/m5-dev
>> >
>> >
>> >
>> >
>> > --
>> > ----------
>> > Korey L Sewell
>> > Graduate Student - PhD Candidate
>> > Computer Science & Engineering
>> > University of Michigan
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
--
----------
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science & Engineering
University of Michigan
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
