Dear All,
I am in the process of writing a EDA software in Lisp (for personal
pleasure only, I might add).
I plan to write an event simulator in this tool box also.
I have some questions regarding the implementation of the waveform display
tool.
I develop on Linux with Common Lisp (clisp) for quick iteration.
I also have CMUCL Python. At work I also have Harlequin Lisp for HP-UX 11.
Q1: How should I implement the waveform display tool ?
Choice 1: As a C++ program which reads in the dumped out data from the Lisp
simulator.
This has the disadvantage that all data must be dumped and that the waveform
cannot "march" interactively as the simulations are taking place. But the
GUI part should be simpler I guess.
Choice 2: I stick with Lisp for the GUI also and write a bare bones waveform
display tool with some GUI toolkit. I have used Garnet but only for toy
applications. Would it be useful for this task.
Choice 3: Make the waveform display tool in C++ but interface it to the Lisp
simulation process by sockets. I dont know anything about socket programming
with Lisp : any pointers ??
I look forward to hearing your comments,
TIA
Sandeep Koranne.
Q2: Where can I find information on making a ninary executable with clisp
and cmucl ?
From: Pierre R. Mai
Subject: Re: Q: Waveform display tool with Lisp event simulator
Date:
Message-ID: <877l666be2.fsf@orion.bln.pmsf.de>
"Sandeep Koranne" <···············@nospam.philips.com> writes:
> Q1: How should I implement the waveform display tool ?
> Choice 1: As a C++ program which reads in the dumped out data from the Lisp
> simulator.
> This has the disadvantage that all data must be dumped and that the waveform
> cannot "march" interactively as the simulations are taking place. But the
> GUI part should be simpler I guess.
As long as the data to be dumped is incrimental in fashion (i.e. data
dumped at later stages is not necessary to display data dumped at
earlier stages), the frontend can visualize the data in an interactive
fashion, with the execption that fast-forward to later stages may take
time, since this data has not been computed by the backend yet...
We used this approach in an older simulation framework, where the
backend (C++) would simulate at full speed and dump out progress logs
to files, and the frontend tools (Tcl) could visualize their parts
of the simulation state online, i.e. during simulation runs, or
offline, i.e. after simulation runs.
You could also use Unix filesystem sockets, in case the dumped data is
only used for interactive display and not useful afterwards.
The nice part about such a loose coupling is that it can be
implemented fairly easily and in a platform independend way.
OTOH schemes like this are fairly restrictive, in that they usually
don't provide for control of the backend process from the frontend
process.
> Q2: Where can I find information on making a ninary executable with clisp
> and cmucl ?
With cmucl, just dump an image that contains your application (named myapp)
and package the image (myapp.core), the lisp binary (renamed to
myapp.bin) and a shell script (myapp) that invokes the lisp binary:
#!/bin/sh
BASEPATH=`dirname $0`
CMUCLLIB=$BASEPATH
export CMUCLLIB
# Possibly put -noinit in there
exec $BASEPATH/myapp.bin -core $BASEPATH/myapp.core -eval '(myapp:start)'
Your start function might want to silence the GC, the herald, etc:
(setq *load-verbose* nil
*compile-verbose* nil
*compile-print* nil
*compile-progress* nil
*require-verbose* nil
*gc-verbose* nil
*herald-items* nil))
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thanx for the suggestions.
I am going for an all out Lisp solution in Garnet for the menus etc, and am
thinking of dropping the marching waveform function, so just dump out the
full file with the selected signal names.
The simulation lenght in my case will not be too long (at least thats what I
am designing for).
Regarding the dumping of the image : I want to know how to remove the
compiler and the extra frills that are in the lisp image by default and make
a small fast loading file.
Is that possible with CMUCL ?
TIA
Sandeep
From: Peter Vaneynde
Subject: Re: Q: Waveform display tool with Lisp event simulator
Date:
Message-ID: <6xem0dvb2d.fsf@lant.be>
"Sandeep Koranne" <···············@nospam.philips.com> writes:
> Regarding the dumping of the image : I want to know how to remove the
> compiler and the extra frills that are in the lisp image by default and make
> a small fast loading file.
> Is that possible with CMUCL ?
During a rebuild a file x86/lisp/kernel.core is produced. This is
AFAIK the minimal lisp image you can run. It does not contain a
compiler for example. You could then try to load the minimum number
of fasl's. See the makefile of my debian package, there is a call
there to load up the new lisp based on the kernel.core image.
Note that in order to work with CLOS you need a compiler.
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
* "Sandeep" == Sandeep Koranne <···············@nospam.philips.com> writes:
[...]
Sandeep> Q1: How should I implement the waveform display tool ?
Sandeep> Choice 1: As a C++ program which reads in the dumped out
Sandeep> data from the Lisp simulator. This has the disadvantage
Sandeep> that all data must be dumped and that the waveform cannot
Sandeep> "march" interactively as the simulations are taking
Sandeep> place. But the GUI part should be simpler I guess.
Sandeep> Choice 2: I stick with Lisp for the GUI also and write a
Sandeep> bare bones waveform display tool with some GUI toolkit. I
Sandeep> have used Garnet but only for toy applications. Would it be
Sandeep> useful for this task.
Sandeep> Choice 3: Make the waveform display tool in C++ but
Sandeep> interface it to the Lisp simulation process by sockets. I
Sandeep> dont know anything about socket programming with Lisp : any
Sandeep> pointers ??
The first choice would allow you to write Lisp part of your program in
a portable fashion. Out of the remaining two, if you are more familiar
with C++ GUI and socket programming than with Lisp GUIs, my suggestion
would be sockets. In Lisp, they are not cardinally differ from sockets
in another languages, but are implementation-dependent(*), so the best
reference would be documentation of the Lisp environment of your
choice.
There is also Choice 4: FFI.
Sandeep> Q2: Where can I find information on making a ninary
Sandeep> executable with clisp and cmucl ?
They don't produce "standalone" executables; one must run environment
and then load the code. However, with Linux this can be done
automagically: you can set custom handlers for different type of
executables. See documentation on "Misc filesystems support" kernel
module.
Regards,
Eugene.
P.S. I beleive PORT package from CLOCC provides some sockets
portability layer, but so far am haven't tried it.