summaryrefslogtreecommitdiff
path: root/src/python/m5/internal
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>
2013-09-18swig: Fix issue with circular import in 2.0.9/2.0.10Andreas Hansson
This patch fixes an issue which prevented gem5 from running when built using swig 2.0.9 and 2.0.10. The generated event.py tried to import m5.internal which in turn relied on importing event. This patch seems to fix the problem, and so far has not caused any other issues.
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.
2011-10-30Python: Remove import for randomNilay Vaish
2010-09-22python: get rid of internal.enums package.Steve Reinhardt
Move generated enums into internal.params, which gets imported into object.params, restoring backward compatibility for scripts that expect to find them there.
2010-09-12swig: make all generated files go into the m5.internal packageNathan Binkert
This is necessary because versions of swig older than 1.3.39 fail to do the right thing and try to do relative imports for everything (even with the package= option to %module). Instead of putting params in the m5.internal.params package, put params in the m5.internal package and make all param modules start with param_. Same thing for m5.internal.enums. Also, stop importing all generated params into m5.objects. They are not necessary and now with everything using relative imports we wound up with pollution of the namespace (where builtin-range got overridden). --HG-- rename : src/python/m5/internal/enums/__init__.py => src/python/m5/internal/enums.py rename : src/python/m5/internal/params/__init__.py => src/python/m5/internal/params.py
2010-09-09scons: Stop building the big monolithic swigged params moduleNathan Binkert
kill params.i and create a separate .i for each object (param, enums, etc.)
2007-08-02python: Improve support for python calling back to C++ member functions.Nathan Binkert
Add support for declaring SimObjects to swig so their members can be wrapped. Make sim_object.i only contain declarations for SimObject. Create system.i to contain declarations for System. Update python code to properly call the C++ given the new changes. --HG-- extra : convert_revision : 82076ee69e8122d56e91b92d6767e356baae420a
2007-04-12Completely re-work how the scons framework incorporates swigNathan Binkert
and python code into m5 to allow swig an python code to easily added by any SConscript instead of just the one in src/python. This provides SwigSource and PySource for adding new files to m5 (similar to Source for C++). Also provides SimObject for including files that contain SimObject information and build the m5.objects __init__.py file. --HG-- extra : convert_revision : 38b50a0629846ef451ed02f96fe3633947df23eb