gnucap-devel
[Top][All Lists]
Advanced

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

[Gnucap-devel] Re: [Help-gnucap] New gnucap development snapshot 2007-11


From: al davis
Subject: [Gnucap-devel] Re: [Help-gnucap] New gnucap development snapshot 2007-11-21
Date: Fri, 23 Nov 2007 00:05:30 -0500
User-agent: KMail/1.9.7

(I am forwarding this to the developer list.)

On Thursday 22 November 2007, a r wrote:
> A few notes on building.
>
> I have extracted all tarballs into a single directory.
>
> Gnucap build process fails on man directory due to missing
> TeX installation. -> build continues after removing man
> directory from the main Makefile: #SUBDIRS = doc examples man
> modelgen src
>       SUBDIRS = doc examples modelgen src
>       (pre-built pdf file would be useful, nevertheless)

There is a pre-built pdf file.  There is something wrong with 
the Makefile.  It should not build the pdf unless you ask for 
it.  This is a known bug.  

Try "./configure.old" then "make".   ...  The "old" version 
doesn't have that bug.  The disadvantage is that "make install" 
is not supported with the "old" version, but you can manually 
install just by copying the file.

> Following files point to non-existing locations:
> models-spice3f5/Gnucap
> models-ngspice17/Gnucap
> models-bsim/Gnucap
>   -> should point to ../gnucap-2007-11-21/src

I am not sure how to handle this.  After installation, it should 
probably eventually point somewhere like /usr/include/gnucap, 
because it is likely that plugins will be added later to a 
system that is already installed.

The only required tarball is the main package 
gnucap-2007-11-21.tar.gz.  All others are optional.  Most users 
don't need them.


> models-bsim/Include/io_trace.h
>   -> should point to ../gnucap-2007-11-21/src/io_trace.h

Thanks for the bug report.

> models-ngspice17 includes multiple executable files, some of
> them in DOS format.

Thanks for the bug report.  Some files that were not supposed to 
be there were accidentally included.  ..  bug in script that 
builds the tarballs.

> tools tarball is not documented, what I am supposed to do
> with it?

There is documentation in the .cc files.  The "a.out" file 
should not be there.

There is one important piece of information missing ....  how to 
compile it.  The answer is (on Linux, 32-bit Intel or AMD) ..
"g++ -fPIC -shared  xxxxxxx" ... where xxxxxxx is the name of 
the plugin you want to compile.  It generates "a.out" which is 
the plugin.

The .cc files are plugins that change the precision used in 
calculations.  Actually, they change the rounding method, by 
sending control codes to the math processor.

"extended-math" switches to 80-bit math, but stores in 64-bit.  
Numbers kept in registers are 80-bit.  It only works on 32-bit 
Intel and AMD processors.

"ieee-math" forces all math to be limited to 64-bits, even 
intermediate results.  It only works on 32-bit Intel and AMD 
processors.

The published IEEE standard specifies that intermediate 
calculations should be rounded to 64-bit.  So, "ieee-math" 
makes the math standard compliant.  "extended-math" is not 
standard compliant.

I believe that Linux (most variants) default to 80-bit and the 
*BSD variants mostly default to 64-bit, leading to occasional 
trivial differences in results.  The plugins let you control 
it.  They don't work on AMD-64, which forces 64-bit according 
to the IEEE standard.

For most users, it doesn't matter.  Whatever it does is ok.  
Forcing "ieee-math" makes regressions match better when 
comparing on different processors or different operating 
systems.  


> Is there any chance of fixing these issues in future
> releases? It is getting a bit annoying to change Makefiles
> every time I want to try a new version.

Yes it will be fixed in future releases.

There will Makefile and build procedure changes, probably more 
than once.  The build procedure and file layout will be 
completely redone.

Setting up the links for the header files in plugins will 
eventually be done by the "configure" script, which will be 
completely redone.


Versions with numbers like "0.35" are considered to be "stable" 
and are fairly well tested.  Versions with dates are 
development snapshots, pre-release.  They contain experimental 
and incomplete code that may not work the way it is supposed 
to,  Sometimes the best way to find out if an idea is good is 
to try it and see how people respond to it. 

The layout and Makefiles will change again, probably more than 
once, as the program evolves.  If this annoys you, you should 
stick to the "stable" version 0.35 for now.

Thank you for the report!  Your report of the problems is very 
helpful to me.





reply via email to

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