Как такие атрибуты, как clk_domain объекта System, передаются между Python и C ++ в gem5?

gem5 активно использует генерацию кода.

Каждый класс SimObject Python автоматически генерирует класс параметров C ++ в каталоге сборки, который передается как конструктор объекта C ++. Более подробно это описано по адресу: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-python-c-interaction, а также упоминался по адресу: Просмотр параметров предсказателя ветвления в gem5

Но в основном, если вы используете grep для сгенерированных файлов C ++ в каталоге сборки (игнорируйте символические ссылки, которые устанавливает чтобы вернуться к основному дереву исходных текстов), вы сможете все понять.

Я не полностью изучил / не понял, как, в частности, используется ClockedObject, но следующее должно, по крайней мере, прояснить часть магического взаимодействия Python / C ++

Конкретный случай ClockedObject.clk_domain, значение по умолчанию для параметра - hte magic Parent.clk_domain, которое связывает его с его родительским (в дереве SimObject) clk_domain по умолчанию, если другое значение не задано:

class ClockedObject(SimObject):
    type = 'ClockedObject'
    abstract = True
    cxx_header = "sim/clocked_object.hh"

    # The clock domain this clocked object belongs to, inheriting the
    # parent's clock domain by default
    clk_domain = Param.ClockDomain(Parent.clk_domain, "Clock domain")

    # Power model for this ClockedObject
    power_model = VectorParam.PowerModel([], "Power models")

    power_state = Param.PowerState(PowerState(), "Power state")

Автоматически созданный класс из этого build/ARM/params/ClockedObject.hh:

struct ClockedObjectParams
    : public SimObjectParams
{
    ClockDomain * clk_domain;
    std::vector< PowerModel * > power_model;
    PowerState * power_state;
};

и соответствующие привязки pybind11 связывают этот объект с python на C ++:

static void
module_init(py::module &m_internal)
{
    py::module m = m_internal.def_submodule("param_ClockedObject");
    py::class_<ClockedObjectParams, SimObjectParams, std::unique_ptr<ClockedObjectParams, py::nodelete>>(m, "ClockedObjectParams")
        .def_readwrite("clk_domain", &ClockedObjectParams::clk_domain)
        .def_readwrite("power_model", &ClockedObjectParams::power_model)
        .def_readwrite("power_state", &ClockedObjectParams::power_state)
        ;

    py::class_<ClockedObject, SimObject, std::unique_ptr<ClockedObject, py::nodelete>>(m, "ClockedObject")
        ;

}

static EmbeddedPyBind embed_obj("ClockedObject", module_init, "SimObject");

а затем, когда создается объект C ++ ClockedObject (это также из Python через привязки после того, как полное дерево SimObject было построено), он получает ClockedObjectParams в качестве входных данных в src / sim / clock_domain.hh, который содержит:

class ClockDomain : public SimObject
{

  public:

    typedef ClockDomainParams Params;
    ClockDomain(const Params *p, VoltageDomain *voltage_domain);

Если посмотреть на fs.py, clk_domain на самом деле SrcClockDomain, инициализированный как:

    # Create a source clock for the system and set the clock period
    test_sys.clk_domain = SrcClockDomain(clock =  options.sys_clock,
            voltage_domain = test_sys.voltage_domain)

но все аналогично, есть Python SrcClockDomain, который наследуется от ClockDomain и соответствующих классов C ++.

Наблюдается в gem5 3ca404da175a66e0b958165ad75eb5f54cb5e772.