Hi Andreas, Sorry for the extreme delay... this has been hovering near the top of my to-do list for a while now, but unfortunately has not made it to the top, in part because it looks like it will not be a quick task. I will bump the priority and see if I can get it done this week.
Apologies, Steve On Mon, Jul 30, 2012 at 1:42 AM, Andreas Hansson <[email protected]>wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1301/#review3180 > ----------------------------------------------------------- > > > Any additional comments before I push this? > > - Andreas Hansson > > > On July 25, 2012, 12:18 a.m., Andreas Hansson wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/1301/ > > ----------------------------------------------------------- > > > > (Updated July 25, 2012, 12:18 a.m.) > > > > > > Review request for Default. > > > > > > Description > > ------- > > > > Changeset 9131:ae59c0189c96 > > --------------------------- > > Port: Separate the port and the interface protocol > > > > This patch splits the port and its interface into a very basic stack. > > The port itself dictates how things are connected and governs the > > physical topology of the system. On top of this, the port interfaces > > (implemented by handlers) are responsible for the transport functions, > > e.g. send/recv for functional, atomic and timing, and also for > > functions like querying of address ranges and block size. > > > > Why are we doing this? This patch enables us to gradually introduce > > the 4-phase ports as an alternative interface to the classic send/recv > > interface. In theory, it would also enable Ruby to rely on the normal > > ports for structurally assembling the system, and then use a custom > > Ruby interface. If we want different protocols at different locations > > in the system it is thus possible. > > > > So what does this patch actually change? Brace yourself, as it > > is quite extensive. First and foremost each port now has two template > > parameters, one for the exposed interface of the port itself (i.e. the > > sending and receiving functionality) and one for the interface > > required from the peer port (the receiving end of the port's own > > sending interface). For example, for a conventional master port, this > > would now be IfaceMasterPort<MasterInterface, SlaveInterface>, where > > the parameters can be left out as they are the default values. This > > corresponds to a port on which we can use the MasterInterface, and > > bind to a peer port with a SlaveInterface. > > > > For convenience, the name MasterPort and SlavePort are type defined to > > be a master and slave with the classic MasterInterface and > > SlaveInterface, as exemplified above. This is sufficient in most > > typical cases, where no additional functionality is required from the > > sending interface. In the case of e.g. a DMA port, additional sending > > functions like dmaAction require the port to expose a DMA-specific > > interface, which extends the MasterInterface. This is now implemented > > in a DmaHandler (the name could be discussed with options including > > Handler, Interface, Iface, IF), which inherits from the > > MasterInterface, and besides implementing e.g. recvTimingResp also > > adds the desired DMA functions. By declaring a > > IfaceMasterPort<DmaHandler> we get a master port with the desired DMA > > interface (which still binds to a SlaveInterface). > > > > The implementation of the interfaces is, as already mentioned, done in > > a handler. Where there previously used to be e.g. a WalkerPort, there > > is now a WalkerHandler and a MasterPort that uses the handler. We > > could consider naming the Handlers Interface or Iface instead as > > already mentioned. The name handler was chosen as they actually > > implement the interface functions. > > > > To enable any arbitrary specialisation of the interfaces, the > > protcol-agnostic base ports have bind functions that call a virtual > > bind function on the interface base class. It is then up to the > > specific implementation to overload this function and verify the > > compatibility. Thus, the ports pass the binding responsibility to the > > interface, and the master interface tries to cast the slave interface > > to the right class. > > > > The separation of the port and the interface is done in a similar > > manner to TLM-2.0, with the interface of the port being accessible by > > overloading the pointer operator. Although this might seem like C++ > > abuse, it makes for a far-less verbose way of accessing the interface > > compared to e.g. a member function. As a result of this change, where > > it used to say port.send, it will now say port->send, and similarly a > > port->send becomes (*port)->send. > > > > As can be seen e.g. in the CPU, the separation of the port and the > > interface also enable the BaseCPU to declare the instPort and > > dataPort, and then leave it up to the specific CPU model to provide > > the interface handlers. Thus, the atomic, timing, inorder and O3 CPU > > can all implement their own independent handlers, and merely pass them > > on to the BaseCPU. A similar approach is used in the cache where a > > handler is created in the subclass and passed to the base cache > > parent that holds the ports themselves. > > > > An additional benefit of this separation is that the module itself can > > implement the interface. This is done in the SimpleMemory, where the > > port handler was a trivial class that only added a level of > > indirection (port.recvAtomic calls memory.recvAtomic). Instead of > > having this handler, the port is now assigned the SimpleMemory itself > > as the handler, and the SimpleMemory is both a MemObject and a > > SlaveInterface. > > > > > > Diffs > > ----- > > > > src/arch/arm/table_walker.hh b57966a6c512 > > src/arch/arm/table_walker.cc b57966a6c512 > > src/arch/x86/interrupts.hh b57966a6c512 > > src/arch/x86/interrupts.cc b57966a6c512 > > src/arch/x86/pagetable_walker.hh b57966a6c512 > > src/arch/x86/pagetable_walker.cc b57966a6c512 > > src/cpu/base.hh b57966a6c512 > > src/cpu/base.cc b57966a6c512 > > src/cpu/base_dyn_inst.hh b57966a6c512 > > src/cpu/checker/cpu.hh b57966a6c512 > > src/cpu/checker/cpu.cc b57966a6c512 > > src/cpu/checker/cpu_impl.hh b57966a6c512 > > src/cpu/inorder/cpu.hh b57966a6c512 > > src/cpu/inorder/cpu.cc b57966a6c512 > > src/cpu/inorder/resources/cache_unit.cc b57966a6c512 > > src/cpu/o3/cpu.hh b57966a6c512 > > src/cpu/o3/cpu.cc b57966a6c512 > > src/cpu/o3/fetch_impl.hh b57966a6c512 > > src/cpu/o3/lsq_impl.hh b57966a6c512 > > src/cpu/o3/lsq_unit.hh b57966a6c512 > > src/cpu/o3/lsq_unit_impl.hh b57966a6c512 > > src/cpu/simple/atomic.hh b57966a6c512 > > src/cpu/simple/atomic.cc b57966a6c512 > > src/cpu/simple/base.hh b57966a6c512 > > src/cpu/simple/base.cc b57966a6c512 > > src/cpu/simple/timing.hh b57966a6c512 > > src/cpu/simple/timing.cc b57966a6c512 > > src/cpu/testers/directedtest/InvalidateGenerator.cc b57966a6c512 > > src/cpu/testers/directedtest/RubyDirectedTester.hh b57966a6c512 > > src/cpu/testers/directedtest/RubyDirectedTester.cc b57966a6c512 > > src/cpu/testers/directedtest/SeriesRequestGenerator.cc b57966a6c512 > > src/cpu/testers/memtest/memtest.hh b57966a6c512 > > src/cpu/testers/memtest/memtest.cc b57966a6c512 > > src/cpu/testers/networktest/networktest.hh b57966a6c512 > > src/cpu/testers/networktest/networktest.cc b57966a6c512 > > src/cpu/testers/rubytest/Check.cc b57966a6c512 > > src/cpu/testers/rubytest/RubyTester.hh b57966a6c512 > > src/cpu/testers/rubytest/RubyTester.cc b57966a6c512 > > src/dev/arm/pl111.cc b57966a6c512 > > src/dev/copy_engine.hh b57966a6c512 > > src/dev/copy_engine.cc b57966a6c512 > > src/dev/dma_device.hh b57966a6c512 > > src/dev/dma_device.cc b57966a6c512 > > src/dev/i8254xGBe.cc b57966a6c512 > > src/dev/io_device.hh b57966a6c512 > > src/dev/io_device.cc b57966a6c512 > > src/dev/pcidev.hh b57966a6c512 > > src/dev/pcidev.cc b57966a6c512 > > src/dev/sinic.cc b57966a6c512 > > src/dev/x86/i82094aa.cc b57966a6c512 > > src/dev/x86/intdev.hh b57966a6c512 > > src/dev/x86/intdev.cc b57966a6c512 > > src/kern/tru64/tru64_events.cc b57966a6c512 > > src/mem/SConscript b57966a6c512 > > src/mem/bridge.hh b57966a6c512 > > src/mem/bridge.cc b57966a6c512 > > src/mem/bus.cc b57966a6c512 > > src/mem/cache/base.hh b57966a6c512 > > src/mem/cache/base.cc b57966a6c512 > > src/mem/cache/cache.hh b57966a6c512 > > src/mem/cache/cache_impl.hh b57966a6c512 > > src/mem/coherent_bus.hh b57966a6c512 > > src/mem/coherent_bus.cc b57966a6c512 > > src/mem/comm_monitor.hh b57966a6c512 > > src/mem/comm_monitor.cc b57966a6c512 > > src/mem/fs_translating_port_proxy.hh b57966a6c512 > > src/mem/fs_translating_port_proxy.cc b57966a6c512 > > src/mem/mport.hh b57966a6c512 > > src/mem/mport.cc b57966a6c512 > > src/mem/noncoherent_bus.hh b57966a6c512 > > src/mem/noncoherent_bus.cc b57966a6c512 > > src/mem/packet_queue.hh b57966a6c512 > > src/mem/packet_queue.cc b57966a6c512 > > src/mem/port.hh b57966a6c512 > > src/mem/port.cc b57966a6c512 > > src/mem/port_interface.hh PRE-CREATION > > src/mem/port_interface.cc PRE-CREATION > > src/mem/port_proxy.hh b57966a6c512 > > src/mem/port_proxy.cc b57966a6c512 > > src/mem/qport.hh b57966a6c512 > > src/mem/ruby/system/RubyPort.hh b57966a6c512 > > src/mem/ruby/system/RubyPort.cc b57966a6c512 > > src/mem/se_translating_port_proxy.hh b57966a6c512 > > src/mem/se_translating_port_proxy.cc b57966a6c512 > > src/mem/simple_mem.hh b57966a6c512 > > src/mem/simple_mem.cc b57966a6c512 > > src/mem/tport.hh b57966a6c512 > > src/mem/tport.cc b57966a6c512 > > src/sim/system.hh b57966a6c512 > > src/sim/system.cc b57966a6c512 > > > > Diff: http://reviews.gem5.org/r/1301/diff/ > > > > > > Testing > > ------- > > > > util/regress all passing (disregarding t1000 and eio) > > > > > > Thanks, > > > > Andreas Hansson > > > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
