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! _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
