I haven't tried this, but I think you might be able to solve this using
the cxx_class attribute. If I understand correctly, you are basically
just trying to describe the Python side of a templatized SimObject. We
have similar issues when exporting a SimObject that lives in a custom
namespace (e.g., the ArmPMU). The cxx_class attribute was created to
handle that corner case. Can't you use that for templates as well?
Cheers,
Andreas
On 23/02/2019 00:42, Gabe Black wrote:
> Yeah, this sounds like it's basically the same thing. Jason, the example
> you gave won't work for the following reason. When gem5 auto generates the
> header which defines the create() function, it doesn't include the header
> which defines the return type of create. I'm not 100% sure why, but likely
> because it would create an include loop in some cases. It instead tries to
> declare the class using the namespaces and class name that have been
> specified. So your example MySimObject would be declared as
>
> class MySimObject<float>;
>
> which is wrong because MySimObject is a template, not a regular class. It
> should be
>
> template <type T>
> class MySimObject;
>
> and then returned as a MySimObject<float> *
>
> This gets more complicated when the type your using as a template parameter
> also needs to be declared. For instance if you wanted to return
> MySimObject<OtherType> where OtherType was a class.
>
> class OtherType;
>
> template <type T>
> class MySimObject;
>
> MySimObject<OtherType> *MySimObjectOtherTypeParams::create();
>
> This gets even more complicated if, for instance, there are typedefs
> involved. You can't blindly declare something as a class if it's actually a
> typedef, because g++ (rightly) doesn't think those are the same and will
> complain.
>
> The situation I'm dealing with/dealt with is that there's a systemc class
> which is templated on an integer width value. I want to wrap that in a
> SimObject so that it can be used in a python config script. This all works
> just fine for "normal" systemc sc_object classes, but because it's a
> template (the systemc part is incidental in this case) it runs into this
> problem. I got around this by subclassing it to be a "normal" class, and
> then just assuming that there won't be any cases where it matters that it's
> not actually the template class directly.
>
> class Normal : public Template<64>
> {
> public:
> using Template<64>::Template;
> };
>
> This works well enough since I'm not planning to have to deal with this
> templated class in the long term, at least as far as I can tell right now,
> and as I imagine you can see from these examples this is quite a rabbit
> hole which can get really complicated if you try to handle all the
> different situations that come up.
>
> Gabe
>
> On Fri, Feb 22, 2019 at 12:24 AM Daniel Carvalho <[email protected]>
> wrote:
>
>> Hi all,
>> I am not sure the MySimObject will be allowed by the Python code. If I
>> recall correctly, when I tried there was something about the Params being
>> programmatically forward declared somewhere, and it didn't exist without
>> the template arguments.
>>
>> Some time ago I have embedded templates to Python
>> https://gem5-review.googlesource.com/c/public/gem5/+/11629. The usage is
>> explained in the commit message, but this is a basic approach which does
>> not cover all aspects of templates. It worked for what I wanted to do, but
>> since it was not desired mainstream, I let it go.
>>
>> Regards,Daniel
>>
>> Em sexta-feira, 22 de fevereiro de 2019 03:05:39 GMT+1, Jason
>> Lowe-Power <[email protected]> escreveu:
>>
>> Hey Gabe,
>>
>> Could you describe in a little more detail why you want to templatize a
>> SimObject. Since python doesn't have support for templates, I don't really
>> like the idea of supporting this.
>>
>> One option is to have the Python side of the SimObject be the
>> "specialization" and then you'd just have to implement the
>> SimObjectParams::create() function to return the specialized template for
>> each of the types you want to support from Python. Does that make sense?
>> Maybe this is what you meant by "subclassing"
>>
>> For instance:
>>
>> *my_simobject.hh:*
>> template <type T>
>> MySimObject public SimObject
>> {
>> ...
>> };
>>
>> *my_simobject.cc:*
>> MySimObjectIntParams::create() {
>> return MySimObject<int>(this);
>> }
>>
>> MySimObjectFloatParams::create() {
>> return MySimObject<float>(this);
>> }
>>
>> *MySimObject.py:*
>> class MySimObjectGeneric(SimObject): # I'm not sure if this is exactly
>> right...
>> ...
>> <all of the params>
>>
>> class MySimObjectInt(MySimObjectGeneric):
>> <header file, etc.>
>>
>>
>> class MySimObjectFloat(MySimObjectGeneric):
>> <header file, etc.>
>>
>>
>> I would say that if the above doesn't work now, we should update things so
>> it does work. However, I don't think we should do any of this
>> *automatically* for templated SimObjects.
>>
>> Cheers,
>> Jason
>>
>> On Fri, Feb 15, 2019 at 5:55 PM Gabe Black <[email protected]> wrote:
>>
>>> Hi folks. I'm trying to create a SimObject out of a templated class (the
>>> python Param type uses a specialization of it), and the pybind11
>> generated
>>> code doesn't compile because the predeclaration of the class type isn't
>>> syntactically correct since it's a template. I can work around this
>> problem
>>> by, for instance, subclassing it and then using that subclass (at least I
>>> think I can, I haven't tried it yet), but it would be nice if the system
>>> could handle it.
>>>
>>> It's not obvious how to fix it since it's not obvious from the fully
>>> specified type how it should be prototyped, so it's not a quick fix. Has
>>> anyone attempted to get this to work, and/or have a solution?
>>>
>>> Thanks!
>>> Gabe
>>> _______________________________________________
>>> gem5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
