Re: [Qucs-devel] Prototype Qucs Verilog-A dynamic loader

[Bastien R. <rou...@gm...>]

Le 7 févr. 2014 23:48, "Guilherme Brondani Torri" <gui...@gm...> a
écrit :
>
> On 03/02/14 19:17, Richard Crozier wrote:
>
> <snip>
>
>>
>>
>> Hi Guilherme (and everyone),
>
>
> Hello!
>
> I am back and I think I have good news on the dynamic-loader. I had some
time on the plane to read the code. With very minor adjustments I got it to
dynamically load, register and simulate a VA module. :)
> In short, it was just a matter returning adequate function pointers
of`mypotentiometer::create` and `mypotentiometer::definition` to be
consumed by `registerModule`. Please wait for the details, I am in the
process of cleaning it up to push the code to the repo.
>
>
>> I've thrown together an example of how I imagined dynamic verilog files
would work in qucsator through the addition of a single new component. It
is shown in the attached vadynamic.h/cpp. This is just a mock-up to
demonstrate the idea, it will not compile. I based it on your work on the
dynamic_loader branch.
>>
>> Basically it works by loading the pointer to the circuit object (using
your method). It then simply calls the same methods in the overridden class
methods as the parent circuit class. e.g.
>>
>>
> Richard, thanks for the example, but I believe the overriding is already
happening. The base is `circuit` and every derived module adapts base and
fills in the missing methods. I will check it further, but I guess
`circuit` methods are all virtual, no?
>
>> In reality for this to work, I think we will have to make many other
public circuit class methods virtual and override them in the vadynamic
class the same way. The idea would be that the circuit is then specified in
a netlist as:
>>
>> VERILOG: VERILOGXXX _net0 _net1 _netn Name="mypotentiometer"
LibFile="/full/path/to/the/shared/lib.so"
>>
>> Any thoughts on this?
>
>
> Yes, this was the first thing I thought about. How will Qucsator know
about new VA components?
>
> A few options I thought of:
>  * The first is one you gave already. Anotate the netlist to let the
simulator know the name of the module and where to find it.
>  * The second is to pass names of loaded modules as parameters to
Qucsator. Like "-load mypotentiometer" and maybe a search path. Assuming
the module and resulting lib have the same basename.
>  * Third, if Qusator doesn't find a netlisted component, try to find it
on the working dir (matching basenames) as a fall back.
>  * Other more elaborated/automated solutions, which find the source VA
file, triggers the compilation... need further thinking.
>
> For now I assume a dynamic module is available on the working directory.
>>
>>
>> p.s. What I meant about having to recompile was that you have to somehow
do the module registration etc. It is not straightforward (to me at least)
how to change things so that it can all be done at runtime rather than
compile time.
>>
>>
> There is no need to recompile to register. That is the beauty, you just
need to compile the VA > C++ > dynamic module.  As the module is loaded,
its registers itself in the factory of loaded modules. The factory then
produces the objects as the netlist demands, returned objects are then
registered into the Qucsator `module::modules` hash. It is just a matter of
loading the dynamic module, and `modules.put` add then the hash. The
`input::createCircuit` doesn't even know if the module was compiled or
loaded. I find it pretty awesome for a dozen lines of code.
>
> Hold on, let me push it then we can discuss it further.
>
> Another thing. What do you guys think if I remove the hash.{h,cpp} and
replace its functionality with a std::hash ?

I am all on but by memory std::hash is a GNU thing. Better to use std::map

Bastien
>
> Regards, Guilherme