Ruby: Remove the physMemPort and instead access memory directly

Information
Submitter:	Andreas Hansson
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Ruby: Remove the physMemPort and instead access memory directly

This patch removes the physMemPort from the RubySequencer and instead
uses the system pointer to access the physmem. The system already
keeps track of the physmem and the valid memory address ranges, and
with this patch we merely make use of that existing functionality. The
memory is modified so that it is possible to call the access functions
(atomic and functional) without going through the port, and the memory
is allowed to be unconnected, i.e. have no ports (since Ruby does not
attach it like the conventional memory system).

Testing Done

util/regress all passing (disregarding t1000 and eio)

Two things -
* Why not provide ruby port with the physmem pointer directly instead of going through the system pointer?
* Where is the system pointer being sent to ruby port?

Andreas Hansson March 20, 2012, 2:13 a.m. (March 20, 2012, 2:13 a.m.)

1) To be able to submit the next patch which introduces distributed memories and avoids the assumption of a single physmem :)

2) As part of the parameters, i.e. using the standard approach of system = Parameter.System(Parent.any...

Nilay Vaish March 20, 2012, 2:16 a.m. (March 20, 2012, 2:16 a.m.)

But don't we need to pass that system object when the sequencers are created
in configs/ruby/*.py files?

Andreas Hansson March 20, 2012, 2:18 a.m. (March 20, 2012, 2:18 a.m.)

No this is all taken care of by the proxy parameter on line 46 in src/mem/ruby/system/Sequencer.py. This is used in a lot of places to find the system.

Ship It!

Again, the comment is just a suggestion, not an issue that requires addressing.

src/mem/ruby/system/RubyPort.cc (Diff revision 1)

Just curious if it really matters that we call doAtomicAccess() rather than doFunctionalAccess() here?  Not a big deal, but if doFunctionalAccess() is adequate, it might be nice to use a single interface.

Andreas Hansson March 21, 2012, 6:36 p.m. (March 21, 2012, 6:36 p.m.)

I'd have to ask a Ruby expert. Nilay? In essence, the difference between the doAtomic vs doFunctional is in 1) updating the statistics of the memory, 2) tracking LLSC, and 3) supporting swap requests.

I can obviously try and just change it, but I'd like to understand what Ruby assumes about the physmem in this case.

Steve Reinhardt March 22, 2012, 1:49 a.m. (March 22, 2012, 1:49 a.m.)

Yea, this comment/question was really directed at a Ruby person and not at you.  No reason to hold up committing.

Nilay Vaish March 22, 2012, 2:01 a.m. (March 22, 2012, 2:01 a.m.)
```
We can use doFunctionalAccess() in place of doAtomicAccess().
```

Andreas Hansson March 22, 2012, 2:55 a.m. (March 22, 2012, 2:55 a.m.)

The implication of changing this is that the stats also have to be updated accordingly (physmem stats will all be 0). Still desirable?

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Status: Closed (submitted)