[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Please fill me in....
Date: Fri, 22 Dec 89 09:19 PST
From: Mr. Spock <Spock@SAMSON.CADR.DIALNET.SYMBOLICS.COM>
When you say circuit simulation do you mean something similar to SPICE
(i.e. lots of floating-point arithmetic and simultaneous equation
solving). If so, did the Sun-4's you use have a floating-point
co-processor?
I'm not really familiar with the program, but I suspect it isn't very
FP-intensive. It operates at the digital component level, so probably
doesn't deal with fractional voltage levels.
No. In order to run Lisp effectively, you need a decent amount of
memory (16Mb, I guess) and a local paging disk. This would bring the
total cost of the workstation up to $15-20K.
Hmmm... That's very enticing. How's the development environment? I was
very frustrated with our 3/260 environment.
Our development environment here is based on GNU Emacs, for which we've
written a number of extensions that interface with Lucid. We run Lucid in
a subprocess of Emacs, and have C-Sh-A, C-Sh-M, C-Sh-C, and Meta-dot that
work by sending forms to the Lisp process and reading back the results. I
believe Franz has something similar that works using multiple Lisp threads
and interprocess communication (we wrote our tools before Lucid had
multiple threads). It's not as good an environment as Genera, but many of
our developers never used much more of Genera's features, anyway (we
developed the tools shortly after Genera 7.0 came out, so they hadn't
gotten spoiled by Dynamic Windows).
The Lucid debugger is pretty reasonable. I think it's comparable to the
Symbolics debugger from Release 6.1 (no variable monitors, no trap on
call/exit, no single step). Again, our developers never got used to the
fancy Symbolics debugger features before they started using Lucid, so they
don't miss them in Lucid.
barmar