Open felix-salfelder opened 9 years ago
Qucs is not liking this patch:
Making all in verilog
./analogfunction.xml
./qucsVersion.xml
./qucsMODULEcore.xml
./qucsMODULEdefs.xml
/Users/guitorri/local/adms/devel/bin/admsXml EKV26MOS.va -e ./analogfunction.xml -e ./qucsVersion.xml -e ./qucsMODULEcore.xml -e ./qucsMODULEdefs.xml -o EKV26MOS
[info...] admsXml-2.3.5 (1c034a0) Nov 7 2016 22:58:48
[info...] EKV26MOS.EKV26MOS.analogfunction.h created
[info...] EKV26MOS.EKV26MOS.analogfunction.cpp created
[info...] EKV26MOS.core.cpp and EKV26MOS.core.h: files created
[info...] EKV26MOS.defs.h: file created
[info...] elapsed time: 1 (second)
[info...] admst iterations: 439996 (412285 freed)
/bin/sh ../../../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src/math -I../../../src/components -I../../../src/components/devices -I. -O2 -std=gnu++11 -MT EKV26MOS.lo -MD -MP -MF .deps/EKV26MOS.Tpo -c -o EKV26MOS.lo EKV26MOS.cpp
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src/math -I../../../src/components -I../../../src/components/devices -I. -O2 -std=gnu++11 -MT EKV26MOS.lo -MD -MP -MF .deps/EKV26MOS.Tpo -c EKV26MOS.cpp -fno-common -DPIC -o .libs/EKV26MOS.o
In file included from EKV26MOS.cpp:12:
./EKV26MOS.EKV26MOS.core.cpp:1866:16: error: use of undeclared identifier 'd00_ddt0'
double m00_ddt(d00_ddt0,qg)
^
./EKV26MOS.EKV26MOS.core.cpp:1866:28: error: expected ';' at end of declaration
double m00_ddt(d00_ddt0,qg)
^
;
I need to have a look at the XML files to see what is the side effect of putting the {d,i}dt
operators aside.
the problem here is that "currently" idt and ddt are not in the global list, so qucs templates can to a for stuff in globallist
, and get just the non-operators.
what qucs templates (and all the others) would have to do is use for stuff in globallist[type!=operator]
instead.
gnucap-adms ships its own implicit rules. that is obviously working (for me), still against the whole idea of sharing rules between targets..
tl;dr; i am not so sure if this is worth the trouble. yet. maybe leave it open, for now.
operators are simply not builtin functions. they should be accessible individually, as they may need different code to be generated.