summaryrefslogtreecommitdiff
path: root/src/python/swig/drain.i
AgeCommit message (Collapse)Author
2017-05-02python: Use PyBind11 instead of SWIG for Python wrappersAndreas Sandberg
Use the PyBind11 wrapping infrastructure instead of SWIG to generate wrappers for functionality that needs to be exported to Python. This has several benefits: * PyBind11 can be redistributed with gem5, which means that we have full control of the version used. This avoid a large number of hard-to-debug SWIG issues we have seen in the past. * PyBind11 doesn't rely on a custom C++ parser, instead it relies on wrappers being explicitly declared in C++. The leads to slightly more boiler-plate code in manually created wrappers, but doesn't doesn't increase the overall code size. A big benefit is that this avoids strange compilation errors when SWIG doesn't understand modern language features. * Unlike SWIG, there is no risk that the wrapper code incorporates incorrect type casts (this has happened on numerous occasions in the past) since these will result in compile-time errors. As a part of this change, the mechanism to define exported methods has been redesigned slightly. New methods can be exported either by declaring them in the SimObject declaration and decorating them with the cxxMethod decorator or by adding an instance of PyBindMethod/PyBindProperty to the cxx_exports class variable. The decorator has the added benefit of making it possible to add a docstring and naming the method's parameters. The new wrappers have the following known issues: * Global events can't be memory managed correctly. This was the case in SWIG as well. Change-Id: I88c5a95b6cf6c32fa9e1ad31dfc08b2e8199a763 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Andrew Bardsley <andrew.bardsley@arm.com> Reviewed-on: https://gem5-review.googlesource.com/2231 Reviewed-by: Tony Gutierrez <anthony.gutierrez@amd.com> Reviewed-by: Pierre-Yves PĂ©neau <pierre-yves.peneau@lirmm.fr> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2017-01-27python: Move native wrappers to the _m5 namespaceAndreas Sandberg
Swig wrappers for native objects currently share the _m5.internal name space with Python code. This is undesirable if we ever want to switch from Swig to some other framework for native binding (e.g., PyBind11 or Boost::Python). This changeset moves all of such wrappers to the _m5 namespace, which is now reserved for native code. Change-Id: I2d2bc12dbc05b57b7c5a75f072e08124413d77f3 Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
2015-07-07sim: Decouple draining from the SimObject hierarchyAndreas Sandberg
Draining is currently done by traversing the SimObject graph and calling drain()/drainResume() on the SimObjects. This is not ideal when non-SimObjects (e.g., ports) need draining since this means that SimObjects owning those objects need to be aware of this. This changeset moves the responsibility for finding objects that need draining from SimObjects and the Python-side of the simulator to the DrainManager. The DrainManager now maintains a set of all objects that need draining. To reduce the overhead in classes owning non-SimObjects that need draining, objects inheriting from Drainable now automatically register with the DrainManager. If such an object is destroyed, it is automatically unregistered. This means that drain() and drainResume() should never be called directly on a Drainable object. While implementing the new functionality, the DrainManager has now been made thread safe. In practice, this means that it takes a lock whenever it manipulates the set of Drainable objects since SimObjects in different threads may create Drainable objects dynamically. Similarly, the drain counter is now an atomic_uint, which ensures that it is manipulated correctly when objects signal that they are done draining. A nice side effect of these changes is that it makes the drain state changes stricter, which the simulation scripts can exploit to avoid redundant drains.
2012-11-02sim: Move the draining interface into a separate base classAndreas Sandberg
This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.