[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] New gnucap development snapshot

From: al davis
Subject: [Gnucap-devel] New gnucap development snapshot
Date: Tue, 21 Nov 2006 18:13:07 -0500
User-agent: KMail/1.9.5

There is a new development snapshot of gnucap available.

There's a package at:

There is a significant change to the way models and devices are 
dispatched, which really makes the link order critical.  I am 
planning to break out the models, devices, and user callable 
functions, and this is a step on the way.  

Apparent functionality is the same as 0.35, but the underlying 
changes are essential to support for Verilog-A user compiled 

It is now possible to add something just by linking it.  No 
changes to other code are necessary, at all.

The next step is to make it so they can be attached by the user 
at run time.  This will make "gnucap-modelgen" meaningful as a 
user program. Until now, it is a necessary part of the build 
process but is not necessary in a binary installation.   As a 
user, you will be able to take a Verilog-A model, compile it, 
and use it immediately without hacking the core at all, or even 
recompiling the core.

An undesirable side effect is the link order is critical. The 
gnu linker actually initializes in the reverse of the order 
listed.  The file linked last is initialized first.  The 
dispatcher objects need to be initialized first, before 
anything is put in it.  When static objects use inheritance, 
the base class must be initialized before anything can be 
derived from it.  Considering this reverse order 
initialization, this means "globals-last" must be listed last, 
the "e_" files must be listed in reverse order of their 
derivation.  The "d_" primitives must be initialized before the 
ones made by the model compler.  The diode must initiaized 
before the bjt or mosfet, etc....  

If the link order is wrong, it will still link, but when you run 
it, it will give the message "incorrect link order" and fail to 
start.  Please let me know where this happens.

This is handled correctly, I think, by the old build system 
(./configure.old; make).  It is handled by some really ugly 
hacks with the autoconf based build system (./configure; make), 
which will be redone soon.  It should work both ways, but 
development is done primarily with the old system.

I am asking for feedback, particularly on non-Linux and non-GNU 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]