[Gnucap-devel] param-WIP branch

[al davis]

Looking to see what can be folded back to main branch ....

Testing tells me  it is not ready yet.  New code is not 
exercised.  Obsolete_callback still used.  No problem, it's 
"WIP".

The reason obsolete_callback exists is that there can be 
expressions of commons, with possibilities that don't fit the 
parameter=value model, so these files were much more difficult 
than the others.

The code here also introduces use of the "boost" external 
library, and does the parsing in a different way than everywhere 
else.  This leads to the question: should it be changed to this 
way everywhere?  Is this an improvement?

First, the "boost" library ...   I looked at it several years 
ago and decided against it primarily because it added another 
dependency, which would become a RUN TIME dependency as other 
plans are carried out.  In some cases, a particular function 
might be useful enough.  These can be copied to l_* files and 
code included, such as in the file "l_stlextra.h".

In general, I have found external library dependencies to be a 
nuisance when I encounter them in other projects, but often they 
are justified.  In this case, the additional functionality is 
minor.  More importantly, the planned route to FULL Verilog-AMS 
support and behavioral modeling is through an external model 
compiler, actually several, a combination of ADMS, Icarus, and 
modelgen derivatives, with just-in-time compiling of plugins.  
This need already adds a run-time dependency on a C++ compiler, 
which I see no way around.  Adding too many more can get out of 
hand.

The new code here also introduces an array of parameters, which 
probably is an improvement.  Spice and Qucs do it this way.  
Since Spice does it this way, Gnucap has code to support it in 
spice_wrapper.cc.  It might be a good idea to change to this 
across the board.  There is also good reason to encapsulate this 
so the search method can be a faster method, likely done through 
the STL "map".  As it stands now, with very small circuits using 
complex foundry models, read-in time can dominate the total run 
time.  So, I think it IS probably a good idea to make a change 
here, but more work is needed.

I like this "WIP branch" approach.  It's a way to present ideas 
that may or may not be what we want so everyone can try them, 
without making them permanent.  Let's have more of them!