Searched hist:14218 (Results 1 - 2 of 2) sorted by relevance

/gem5/src/dev/
H A Dio_device.hh14218: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 Dio_device.cc14218: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