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.

1 files changed, 2 insertions, 2 deletions

diff --git a/src/mem/ruby/system/RubyPort.hh b/src/mem/ruby/system/RubyPort.hh
index 6df713a13..0d84ec216 100644
--- a/src/mem/ruby/system/RubyPort.hh
+++ b/src/mem/ruby/system/RubyPort.hh
@@ -137,7 +137,7 @@ class RubyPort : public MemObject
     int m_version;
     AbstractController* m_controller;
     MessageBuffer* m_mandatory_q_ptr;
-    PioPort* pio_port;
+    PioPort pio_port;
     bool m_usingRubyTester;
 
   private:
@@ -155,7 +155,7 @@ class RubyPort : public MemObject
     uint16_t m_port_id;
     uint64_t m_request_cnt;
 
-    PioPort* physMemPort;
+    PioPort physMemPort;
 
     /*! Vector of CPU Port attached to this Ruby port. */
     typedef std::vector<M5Port*>::iterator CpuPortIter;