<br><br><div class="gmail_quote">2008/11/9 P Zoltan <span dir="ltr"><<a href="mailto:zoltan.padrah@gmail.com">zoltan.padrah@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, 08 Nov 2008 19:25:41 +0100, Alan Grimes <<a href="mailto:agrimes@speakeasy.net">agrimes@speakeasy.net</a>><br>
wrote:<br>
<div class="Ih2E3d"><br>
> That doesn't apply because in our use case, what we are trying to<br>
> encode, as data are programs, which necessarily need to be interpreted,<br>
> no shame in that.<br>
><br>
> It is absolutely necessary that the user be able to design components.<br>
> So compiled C++ is out of the question.<br>
><br>
<br>
</div>  That's clear.<br>
<br>
  But I still don't understand why do we need _programs_ describing new<br>
components? Where and when should those program run? (I don't really know<br>
the internal workings of the simulator) Wouldn't be enough to describe the<br>
equations of the part?<br>
<div class="Ih2E3d"></div></blockquote><div><br>There will always be the one new component you can't describe without new formulas or new algorithm.<br>Globally, every analogue component is composed of several pins and some formulas that link current and voltage of every pin.<br>
<br>Andn you know, linear algebra theory says the vector space of functions has infinite dimention. That means it's not possible to have a list of every possible model of function.<br>That's why I suggest to keep them outside of the simulator's core.<br>
I think an advanced user (understand, C/C++ coder) should be able to add his own computation formulas to the simulator.<br><br>About digital circuits:<br>As a circuit become complex, it's execution time grows. Designing a whole processor with only logical gates will lead to a huge execution time.<br>
Being able to write some components in C/VHDL/whatever, really help.<br><br>I'm speaking about digital circuits, but it must be the same for analogue circuit.<br>For example when your component is a specialization of another which is a composition of two specialized components. You may really save computation time by rewriting formulas for this component.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">>> I'm not against the use of XML, but I think that only simple components<br>

>> should be written in XML. Others may be written in C/C++, compiled as<br>
>> .so and loaded at launch time (or later...).<br>
><br>
<br>
</div>  What about different CPU architectures? And 32bit vs 64bit? Plus see user<br>
created component argument earlier. I consider binarty, compiled component<br>
a bad idea, because: they would need to be recompiled for each platform<br>
and because a 'normal' user won't have a c++ compiler installed on his<br>
system.<br>
<font color="#888888"></font></blockquote><div><br>You're right. That's why I refactored (?) my idea to put only computation in .so.<br>I think adding components should be the last and easiest thing to do, but everything should be ready for that.<br>
<br></div></div><br>Celelibi<br>