MEM: Move port creation to the memory object(s) construction

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

Description

MEM: Move port creation to the memory object(s) construction

This patch moves all port creation from the getPort method to be
consistently done in the MemObject's constructor. This is possible
thanks to the Swig interface passing the length of the vector ports.
Previously there was a mix of: 1) creating the ports as members (at
object construction time) and using getPort for the name resolution,
or 2) dynamically creating the ports in the getPort call. This is now
uniform. Furthermore, objects that would not be complete without a
port have these ports as members rather than having pointers to
dynamically allocated ports.

This patch also enables an elaboration-time enumeration of all the
ports in the system which can be used to determine the masterId.

Testing Done

util/regress all passing (disregarding t1000 and eio)

Issue Summary

Description	From	Last Updated	Status
Does it make more sense to just maintain two separate vectors, one for masters and one for slaves? It'd require ...	Steve Reinhardt	Feb. 22, 2012, 4:43 p.m.	Dropped

Ship It!

Ship It!

Looks fine, comments below are minor/optional.

src/cpu/testers/directedtest/RubyDirectedTester.cc (Diff revision 1)

Is this cast really necessary?  Looks like ports.size() should be a size_t.  I'm curious what error/warning we get if we leave it out...

Andreas Hansson Feb. 22, 2012, 4:43 p.m. (Feb. 22, 2012, 4:43 p.m.)

size_t is unsigned, int signed, hence with the warning enabled:

warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

I'd rather keep the code as clean as possible and avoid issues with clang, future versions of gcc etc (with the current flags I can remove the cast and gcc 4.5 is still happy).

Steve Reinhardt Feb. 22, 2012, 11:03 p.m. (Feb. 22, 2012, 11:03 p.m.)
```
Ah right, I have seen this one before... thanks for reminding me.
```

src/mem/bus.cc (Diff revision 1)

Does it make more sense to just maintain two separate vectors, one for masters and one for slaves?  It'd require more extensive changes to the rest of the bus code, but it might actually clean it up a bit... maybe you're already doing this in some future patch I haven't seen yet.

Show all issues

Andreas Hansson Feb. 22, 2012, 4:43 p.m. (Feb. 22, 2012, 4:43 p.m.)

Great minds think alike :).

This master/slave split is indeed happening with the introduction of the master and slave port in the C++ classes. Once this happens there will be a slavePorts and masterPorts vector. I'd suggest to save it until that later patch (two or three patches away from being posted to the board).

Steve Reinhardt Feb. 22, 2012, 11:03 p.m. (Feb. 22, 2012, 11:03 p.m.)
```
Great, I'll look forward to that.
```

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Status: Closed (submitted)