gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] missing info in the models tarballs.


From: al davis
Subject: Re: [Gnucap-devel] missing info in the models tarballs.
Date: Tue, 27 Feb 2007 00:02:13 -0500
User-agent: KMail/1.9.5

On Monday 26 February 2007 03:22, David Fang wrote:
>       Sorry for delay, been a long day/night here. 

I noticed the time stamp on your email..... :-)

>       Ok.  Don't forget, you can move all the autotool scripts
> into a subdir using AC_CONFIG_AUX_DIR([subdir]) in
> configure.ac.  Less clutter.

Thanks.  I will try that.

> I think I'm seeing what you mean by plug-in now, that it's
> not just typical shared libraries built on top of shared
> libraries.  You want users to be able to build-modules in
> their local working directories without going through
> installations, hence the 'need' for a practical
> link-management like libtool for users.  Is this what you
> have in mind?

Yes.

Also, the mechanism will be used to compile behavioral models, 
mostly written in Verilog-AMS or VHDL-AMS.

> Since you intend for model-writers to plug-in/link against
> gnucap, you could try to simplify things by propagating
> linker flags (the same used in building gnucap) to a
> configuration file.  The flags contain more than the usual
> paths, but also some flags deduced by libtool, if you're
> making some libtool-like assistance to model-compilation. 
> (Is this what you had in mind about 'libtool-light'?)  It
> could be a piece of boilerplate Makefile that can be included
> by plugins' Makefiles.
> e.g. "include /usr/local/lib/gnucap/mk/modelgen.mk"
> (/lib instead of /share, because it will be
> architecture-dependent) This way, no additional configuration
> is necessary for the plug-in build, just re-using the results
> of the core's configuration.

Yes,

Most plugins, models, etc will be single files.  If you want to 
load several as a group, it is permissible to link them into a 
single file.

I also want it to be possible to build a custom static linked 
version, just by listing the modules they want in a Makefile.  
This is why the link order issue came up.  I could solve the 
whole link order problem by requiring all that can be plugins 
to really be plugins.

> Requiring a C++ compiler is not a big deal.  Can you
> summarize why the .model files were a headache?  (The mail
> archive I'm reading through lumps all messages with the same
> subject "new gnucap development snapshot" into the same
> thread, which mixes things up incoherently...)

Dan McMahill did the autoconf work.  (Thank you Dan,  It helped 
a lot!!)

Basically what happens is ...

First, the program "gnucap-modelgen" must be built, because it 
is needed to compile the .model files.

The ".model" files are compiled by "gnucap-modelgen" to create 
a ".cc" and a ".h" file. (or an equivalent combined file).

This .cc file is compiled.

The problem is with automatic dependency tracking.  With a 
standard Makefile, a simple pair of rules seems to take care of 
it:
#------------------------------------------------------------------------
%.cc : %.model gnucap-modelgen
        ./gnucap-modelgen -cc $<
#------------------------------------------------------------------------
%.h : %.model gnucap-modelgen
        ./gnucap-modelgen -h $<
#-----------------------------------------------------------------------------

Even with the same rules, the autoconf version seems to not 
track the dependency properly.  The idea is that changing 
a .model, and Make does the right thing.  It is further 
complicated because the modeling language supports inheritance, 
so generated .h files are used in other .cc files in addition 
to their own.

The autoconf version builds in a different order ..  It does all 
the modelgen work before any c++ work.  The old system defers 
running modelgen until the resulting .cc and .h are needed.  
This in itself is not a problem, but is an indicator that 
something isn't right.  For now, there is a workaround that 
builds them all when you touch any of them.  This is safe, but 
causes unneeded recompiles.

Neither Dan nor I could figure out a better way that worked.


> > You are thinking of relatively few big plugins that involve
> > significant development effort.  I expect that the majority
> > will be hack jobs, used once and never distributed.  As I
> > said, compiled models and test benches.
>
> Well, not necessarily big so much as written with the intent
> of installation and re-use.  For throw-away work, the above
> suggestion of providing an installed boilerplate Makefile
> might suffice.

That is the intent.  Actually, even for distributed plugins that 
are single files, I expect to distribute only that single file.  
For plugins that are multiple files, I expect its 
own "Makefile" will be only a list files.  The options, 
everything gnucap specific, comes from the installed 
boilerplate Makefile.

Again, I expect that most of them will be written in a modeling 
language.  The provider of a model wants it to work with all 
simulators.  It is likely that they acutally used something 
like Spectre or some other commercial simulator.  Also, some 
will develop on gnucap with the intent that Spectre users can 
use the model.

> If you provide the invariant components of the Makefile,
> you're nearly done.  Boilerplate and locally determined parts
> can be provided by the installation of gnucap.  Everything is
> preconfigured except for listing local files, which the user
> provide.  No additional configuration necessary.  Do you
> intend to provide an installed makefile?

Yes.  That is the intent.

> Should the quick-hack model code take on a life of its own,
> it's only an incremental amount of work to package it up,
> just depending on a gnucap core installation for
> configuration information.

As I said, probably most of them will be Verilog-AMS or 
VHDL-AMS, industry standard languages.

> I don't think you need to worry about rpm/deb matters, those
> tools have wrappers scripts and conventions to work with any
> typical autotoolized (or mimicked)  project.  I've never had
> to worry about them, and my colleagues have built rpms and
> debs from my distributions just fine.

That is the main reason for using autoconf.  It has features 
they depend on.  People have been building packages before 
gnucap used autoconf, but they needed to do more manual 
configuration.

> Now, for portability issues, admittedly autoconf's core tests
> don't cover much about C++, and the autoconf-macro archive is
> slightly better.  This doesn't sound like a solution, but
> write solutions only for the problems that arise: don't worry
> every known issue out there.  If you discover a C++-ism that
> needs a configure test, I'm more than willing to submit a
> macro test for it, as are other developers on the list --
> I've been doing this for some time, following the evolution
> of C++ support from g++ 2.95 to 4.2.

Dan just made one to track the link order issue.  (Dan: how 
about posting it?)

Mostly I try not to use features that are subject to that kind 
of problem, but occasionally they come up.

The biggest one still unresolved, that has been there for years, 
is in template instantiation. (often confused with 
specialization).  Older versions of ACS/gnucap had an 
option "COMPILE_TEMPLATES", "MANUAL_TEMPLATES",
"LINK_TEMPLATES" .  As of now, only "COMPILE_TEMPLATES"
is supported, but 5 years ago Borland worked only with
"COMPILE_TEMPLATES".  Gnu and MS (strange pair here)
worked only with "MANUAL_TEMPLATES".  Sun worked
only with "LINK_TEMPLATES".

(Now you will ask what those words mean....)

It would be nice if there was a test to see if LINK_TEMPLATES
is supported, because it significantly speeds up compiling 
and reduces generated code size.  Actually, I don't know
if it is worth the test just for this.  There still may be a 
problem with Sun's compiler.

2.95 was the first clean version of g++, that supported STL 
properly.  Most of the problems went away with that release.

> So if you provide a "gnucap-config" script and/or
> pre-configured boilerplate Makefile, installed in an
> architecture-dependent path, then you should be most of the
> way there to the way you want plugins to be built.  Is this
> what you're likely to try?

It should be configured by autoconf at build time.

> Ok, it's time for me to pass-out.
> Zzzzzzzz... [murmurs of coding in sleep]

Like I say ... I did notice the time stamps on much of your 
email.  :-)

Grad school ... I remember it well....  Be sure to allocate time 
for recreation, physical activity.  For me it was bicycling and 
cross country skiing. There is some really great bicycling 
around Ithaca. I was in Rochester, but did lots of bicycling in 
the finger lakes area.  A ride around Cayuga Lake should be 
very enjoyable.





reply via email to

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