Searched hist:14218 (Results 1 - 2 of 2) sorted by relevance
/gem5/src/dev/ | ||
H A D | io_device.hh | 14218:c83b2bdfc7ee Tue Sep 03 00:41:00 EDT 2019 Gabe Black <gabeblack@google.com> dev: Templatize PioPort. When creating a base class which needs to be a SimObject, it's necessary to decide ahead of time whether to use PioDevice or BasicPioDevice in the hierarchy because they inherit from SimObject. If they were added into the hierarchy later, then the original class would inherit from SimObject, as would PioDevice. That would create a diamond inheritance structure which would require virtual inheritance, and that's a can of worms we'd rather not get into. A big part of the PioPort mechanism is the PioPort itself which holds a pointer to its parent device and delegates reads/writes to it. It does that with a PioDevice pointer, and PioDevice declares virtual functions for all the callbacks the port can call into. Instead of that, this change templatizes PioPort based on the class of the device that holds it. That will let you use a PioPort on *any* class, as long as it has the methods PioPort depends on. That removes the need to create an inheritance diamond to add a PioPort down the line since PioDevice is no longer strictly required. The PioDevice and BasicPioDevice classes are still around since they still provide some additional functionality and there are existing classes which depend on them. Change-Id: I753afc1e0fa54b91217d54c1f8743c150537e960 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20568 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com> |
H A D | io_device.cc | 14218:c83b2bdfc7ee Tue Sep 03 00:41:00 EDT 2019 Gabe Black <gabeblack@google.com> dev: Templatize PioPort. When creating a base class which needs to be a SimObject, it's necessary to decide ahead of time whether to use PioDevice or BasicPioDevice in the hierarchy because they inherit from SimObject. If they were added into the hierarchy later, then the original class would inherit from SimObject, as would PioDevice. That would create a diamond inheritance structure which would require virtual inheritance, and that's a can of worms we'd rather not get into. A big part of the PioPort mechanism is the PioPort itself which holds a pointer to its parent device and delegates reads/writes to it. It does that with a PioDevice pointer, and PioDevice declares virtual functions for all the callbacks the port can call into. Instead of that, this change templatizes PioPort based on the class of the device that holds it. That will let you use a PioPort on *any* class, as long as it has the methods PioPort depends on. That removes the need to create an inheritance diamond to add a PioPort down the line since PioDevice is no longer strictly required. The PioDevice and BasicPioDevice classes are still around since they still provide some additional functionality and there are existing classes which depend on them. Change-Id: I753afc1e0fa54b91217d54c1f8743c150537e960 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/20568 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Jason Lowe-Power <jason@lowepower.com> Tested-by: kokoro <noreply+kokoro@google.com> |
Completed in 34 milliseconds