> On Feb. 5, 2015, 8:25 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/DMASequencer.hh, line 76 > > <http://reviews.gem5.org/r/2627/diff/1/?file=43428#file43428line76> > > > > Can we not get this through the sequencer rather? > > Jason Power wrote: > I can make this change, if you want. But I was following the same format > as is in the other Ruby ports (i.e. line 82 in RubyPort.hh). IMO, it's better > to have consistency across similar objects than minimizing the code.
Don't worry if it is too invasive. It merely seems unnecessary to pass the pointer around everywhere if it is already in the "bigger" objects. > On Feb. 5, 2015, 8:25 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/DMASequencer.cc, line 216 > > <http://reviews.gem5.org/r/2627/diff/1/?file=43429#file43429line216> > > > > Should this really be functional, or should it just be "access"? > > Jason Power wrote: > I can make this change. What is the difference between access() and > functionalAccess()? When should one be used and not the other? I might have > missed it, but I can't find any guide to this on the wiki or in the code. > > Also, do you want me to go back through and make this update in the > RubyPort as well? functional -> do not change any state (only read/write and update data), should only be used by send/recvFunctional imho normal -> anything from atomic or timing where we also need to deal with Swap, LLSC etc and the state (in addition to data) changes I think in all these cases we should use access() > On Feb. 5, 2015, 8:25 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/RubySystem.py, line 51 > > <http://reviews.gem5.org/r/2627/diff/1/?file=43431#file43431line51> > > > > I find the description rather misleading. > > > > In essence it is not the case of bypassing the interconnect, it is more > > a case of duplicating the memory, and ignoring the "normal" one. > > > > Thinking about it, why do we not just use the actual memory, but do so > > by faking it through system->getPhysMem().access(...) > > Jason Power wrote: > I've updated this description. I don't follow your last statement, though. Why do we need this additional backing store, and why do we not simply bypass the interconnect and use C++ magic, going through the system->getPhysMem(), but to the same backing store we would have used had we gone through the interconnect. Perhaps I am missing something... - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2627/#review5828 ----------------------------------------------------------- On Feb. 5, 2015, 3:38 p.m., Jason Power wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2627/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2015, 3:38 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10681:b2dc4aee1a0d > --------------------------- > Ruby: Update backing store option to propagate through to all RubyPorts > > Previously, the user would have to manually set access_backing_store=True > on all RubyPorts (Sequencers) in the config files. > Now, instead there is one global option that each RubyPort checks on > initialization. > > > Diffs > ----- > > configs/ruby/Ruby.py 7639c17357dc > src/mem/ruby/system/DMASequencer.hh 7639c17357dc > src/mem/ruby/system/DMASequencer.cc 7639c17357dc > src/mem/ruby/system/RubyPort.cc 7639c17357dc > src/mem/ruby/system/RubySystem.py 7639c17357dc > src/mem/ruby/system/Sequencer.py 7639c17357dc > src/mem/ruby/system/System.hh 7639c17357dc > src/mem/ruby/system/System.cc 7639c17357dc > > Diff: http://reviews.gem5.org/r/2627/diff/ > > > Testing > ------- > > > Thanks, > > Jason Power > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
