On Tue, Feb 17, 2009 at 9:50 PM, Gabriel Michael Black < [email protected]> wrote:
> I think you forgot to actually send this to Kevin as well... Actually I thought I was sending it to m5-dev... let's get this conversation back on the list. > The main place translateDataReadReq, translateDataWriteReq, and > translateInstReq are used as far as I known actually is by instructions so > they can try out accesses without actually sending any data around. It was > needed by some of x86's microops at least, but other things in other ISAs > may use it too. I thought the main usage was in the CPU models' read() and write() functions. Do x86 microops actually access the translations directly or do they just need to test them (e.g., they're no-ops except for the potential side effect of faulting)? > The reason I was thinking it shouldn't be part of the thread context is > that it would probably be cumbersome to work a decoupled lookup into that > function in the situations a thread context is used, and realistically > things using a thread context won't care if there's a TLB miss in SPARC, > say. That's a good point. > I -believe- that the read and write functions are only in the exec context > and things that use a thread context have to go through something else like > a port. I think you're probably right. > I would imagine translation would be similar, and I think we have a few > widgets in place that do functional style translations in SE and FS. In these "functional" cases you probably usually want the translation as part of a memory access, which means you should be using something like TranslatingPort; even if you want the physical address directly you probably want vtophys(). In neither case would you want to translate a Request object directly. However, TranslatingPort may want that functionality internally. > I think the reason the translate* functions ended up in any of the thread > contexts was just that I didn't really understand the distinction when I > added it, and it worked out since the function was always atomic. There may > be no consumer of translate* as a member of the thread contexts. It would be interesting to verify that. > > > Gabe > > > Quoting Steve Reinhardt <[email protected]>: > > On Tue, Feb 17, 2009 at 1:59 AM, Gabe Black <[email protected]> >> wrote: >> >> I started working on what we talked about earlier, and one thing I >>> realized is that the functions like translateDataReadReq probably should >>> no longer be part of the thread contexts while they should be part of >>> the exec contexts. This came up specifically when looking at the >>> simple_thread class which is a thread context, correct? >>> >>> >> It is a little confusing, but it's starting to come back to me... Kevin, >> feel free to jump in if I'm missing something. I recall Kevin and I >> hashing >> this out in my office several years ago. >> >> Again, reading the wiki documentation is the best place to start. >> >> I think the best way to think about it is that ThreadContext is intended >> to >> be an "architectural" view of the thread's state, suitable for >> manipulation >> by relatively high-level things like syscall emulation functions. In >> contrast, ExecContext is a lower level, more specialized interface that >> provides only what is needed for implementing instruction semantics , and >> does so in such a fashion as to enable things the ThreadContext doesn't >> need >> like register renaming. >> >> However you can get confused if you read too much into the "high level" >> and >> "low level" descriptions there. In O3 that holds somewhat, in that (I >> believe) the pipeline has to be flushed whenever you access registers via >> the ThreadContext interface so you don't have to deal with renaming. >> However, sometimes it's more upside down; so you end up with the situation >> in SimpleCPU where the CPU model doesn't really do anything beyond >> implementing the basic ISA semantics, so the easiest way to provide the >> "low-level" ExecContext interface is to map it fairly directly to the >> "high-level" ThreadContext interface, in this case embodied pretty >> directly >> in the SimpleThread object. >> >> And then you end up with things like translateDataReadReq(), which (I >> think) >> aren't part of the ExecContext interface at all, since instructions never >> directly access translations; all the ExecContext provides are read() and >> write() functions. However translation is part of the ThreadContext >> (partly >> for lack of a better place to put it, I think, but it is needed for e.g. >> syscall emulation)... and so you end up implementing the "low-level" >> ExecContext read() and write() functions in terms of this function in the >> "high-level" ThreadContext. This may not be the greatest example... I'm >> willing to be convinced that there's a better place for >> translateDataReadReq() and friends, but it's not in the ExecContext. >> >> Steve >> >> > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
