In article <·····················@watdragon.waterloo.edu> ·······@watdragon.waterloo.edu (Steve Woods) writes:
>
>We currently have KCL running on a VAX, but we would like to have
>it run on a MIPS machine. Has anyone done this?
>
>Also - is it possible to get KCL to generate *stand-alone* C code
>that could be ported and run on a MIPS machine?
>
>Thanks for any assistance. Please Email replies.
>
>
>
>--
>Steve Woods
>Computer Science Graduate Student
>University of Waterloo, ONTARIO Canada
>{ ·······@watdragon.waterloo.edu or ·······@watdragon.uwaterloo.ca }
John Richards | email : ·····@clan.nott.ac.uk
Dept. of Chemical Engineering | : ·····@vax.nott.ac.uk
Nottingham University | tel : (0602) 484848 x2956
Nottingham, NG7 2RD | fax : (0602) 588138
In article <·····················@watdragon.waterloo.edu> ·······@watdragon.waterloo.edu (Steve Woods) writes:
>
>We currently have KCL running on a VAX, but we would like to have
>it run on a MIPS machine. Has anyone done this?
>
>Also - is it possible to get KCL to generate *stand-alone* C code
>that could be ported and run on a MIPS machine?
>
Sorry about my previous post being a repost of the original.
What I wanted to say was that we also would like to run AKCL on a MIPS machine.
I've been having problems with posting just recently, I tried sending the
following but could not get it off of our machine.
Has anyone ported the AKCL to Mips machines. I don't mean to the DEC-stations
that use mips chips, I mean Mips hardware. We have a R2000 and were unable to
build it ourselves. I understand LISP and the system manager knows C but we
couldn't figure it out between us. He said we needed to know something about the
way that Mips C is stored in its COFF encapsulation (I think? - this was 2
months ago).
Has it been done ?
Is it available anonymous ftp ?
etc etc etc..
John
********************************************************************************
John Richards | email : ·····@clan.nott.ac.uk
Dept. of Chemical Engineering | : ·····@vax.nott.ac.uk
Nottingham University | tel : (0602) 484848 x2956
Nottingham, NG7 2RD | fax : (0602) 588138
Just curious:
Are there any people using AKCL for serious purposes? I just find it
funny that people are asking for AKCL on all these fancy machines - the
cost of one of the fine commercial lisps is probably usually minor
compared to the hardware costs involved.
It's not that I don't like pd programs, it's just that I tried a small
program I have that does some runtime compiling when loading, and I found
out that the the AKCL compiler is several times slower on a decstation
3100 than the MACL compiler on the tiny-and-usually-regarded-a-toy
Macintosh SE!! (hw+sw costs about $2000...)
It must be a pain to develop software with it.
(I must admit that the code produced seems reasonably fast, however)
-----------------------------------------
Espen J. Vestre
Department of Mathematics
University of Oslo
P.o. Box 1053 Blindern
N-0316 OSLO 3
NORWAY ·····@math.uio.no
-----------------------------------------
From: Jeff Dalton
Subject: Re: Looking for KCL on MIPS & AKCL.
Date:
Message-ID: <3685@skye.ed.ac.uk>
In article <······················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>Just curious:
>Are there any people using AKCL for serious purposes?
Yes.
>I just find it funny that people are asking for AKCL on all these
>fancy machines - the cost of one of the fine commercial lisps is
>probably usually minor compared to the hardware costs involved.
Just because you can get the machine, one way or another, doesn't
mean you have enough money for commercial Lisp systems too. For
example, most of the people I work with use Suns, but the person
who shares my office has a MIPS workstation. We have no plans to
buy a commercial Lisp for it, because it won't be used in any
Lisp-based projects. We also have a Sequent which is primarily
used for parallel Prolog work. The fastest way to get a Lisp on
it was to port KCl.
>It's not that I don't like pd programs, it's just that I tried a small
>program I have that does some runtime compiling when loading, and I found
>out that the the AKCL compiler is several times slower on a decstation
>3100 than the MACL compiler on the tiny-and-usually-regarded-a-toy
>Macintosh SE!! (hw+sw costs about $2000...)
The main time cost is usually the C compiler. KCL compiles Lisp by
emitting C. Some C compilers can be very slow, at least on the files
emitted by KCL. GCC seems rather fast, but there will always be
some extra cost when compilation follows such an indirect route.
(You also have to compare like with like. Does the MACL compiler
compile to native code?)
>It must be a pain to develop software with it.
Sometimes. But it's smaller than the commercial Common Lisps I've
tried. So, on machines like an 8 meg SPARCstation, it can be much
easier to use, because it doesn't spend so much time paging. For
large programs, though, this advantage may be lost.
-- Jeff
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> Just because you can get the machine, one way or another, doesn't
> mean you have enough money for commercial Lisp systems too. For
> example, most of the people I work with use Suns, but the person
> who shares my office has a MIPS workstation. We have no plans to
> buy a commercial Lisp for it, because it won't be used in any
> Lisp-based projects. We also have a Sequent which is primarily
> used for parallel Prolog work. The fastest way to get a Lisp on
> it was to port KCl.
I can see your point. But isn't it sometimes better to telnet to a
machine running a better lisp implementation?
The reason I looked into AKCL was somewhat different - I wanted to make
sure that my MACL program was portable to other CLs. I wasn't able to run
it, however ("value stack overflow", could this be corrected by setting up
AKCL in another way?).
Luckily, I discovered that I was able to "borrow" a NeXt by telnetting to
it (And NeXts come bundled with Allegro CL as you may know).
> (You also have to compare like with like. Does the MACL compiler
> compile to native code?)
Yes! And very good code as well!
> Sometimes. But it's smaller than the commercial Common Lisps I've
> tried. So, on machines like an 8 meg SPARCstation, it can be much
> easier to use, because it doesn't spend so much time paging. For
> large programs, though, this advantage may be lost.
This reminds me of another question I have: Why on earth are these
systems so large?? Compare it with Macintosh Allegro Common Lisp again:
Although it includes a very fast and very good compiler, a nice
backtracer, an editor and lots of other goodies, it doesn't need more than
2MBs of memory to run properly (for instance the program that I couldn't
get AKCL to load). For small programs, the memory need is even smaller:
The system itself needs only about 800K.
-----------------------------------------
Espen J. Vestre
Department of Mathematics
University of Oslo
P.o. Box 1053 Blindern
N-0316 OSLO 3
NORWAY ·····@math.uio.no
-----------------------------------------
From: Jeff Dalton
Subject: Re: Looking for KCL on MIPS & AKCL.
Date:
Message-ID: <3696@skye.ed.ac.uk>
In article <····················@ulrik.uio.no> ·····@math.uio.no (Espen J. Vestre) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>> Just because you can get the machine, one way or another, doesn't
>> mean you have enough money for commercial Lisp systems too. [...]
>I can see your point. But isn't it sometimes better to telnet to a
>machine running a better lisp implementation?
Yes. I do that too. But not everyone has such other machines.
Indeed, the Dept. of AI in Edinburgh would probably not have been able
to use Common Lisp for teaching at all if it had not been for KCL. We
had KCL back in 1985, before there was much in the way of other Common
Lisps; it was affordable; and it ran on (or could be ported to) the
machines we had. Even now it would be too expensive to get a
commercial license for all the machines used by students.
(It is perhaps because we had KCL so early on that we have a more
positive view of Common Lisp than some other people/places in the
UK.)
>The reason I looked into AKCL was somewhat different - I wanted to make
>sure that my MACL program was portable to other CLs.
In my opinion, it's a good idea to try KCL when checking portability,
but it isn't enough on its own. You would also have to try some of
the commercial CLs.
However, KCL used to be more misleading as a portability check than it
is now. KCL used to have annoyingly nonstandard "evaluation times"
for top- level forms, which meant that EVAL-WHENs had to be added to
programs originally written in KCL; but that has been fixed in AKCL.
>I wasn't able to run it, however ("value stack overflow", could this
>be corrected by setting up AKCL in another way?).
You could try rebuilding KCL with a bigger stack. It's also a good
idea to compile such code to see if that helps.
>Luckily, I discovered that I was able to "borrow" a NeXt by telnetting to
>it (And NeXts come bundled with Allegro CL as you may know).
Is that Allegro as in Franz Inc or Allegro as in Apple?
>> Sometimes. But it's smaller than the commercial Common Lisps I've
>> tried. So, on machines like an 8 meg SPARCstation, it can be much
>> easier to use, because it doesn't spend so much time paging. For
>> large programs, though, this advantage may be lost.
>
>This reminds me of another question I have: Why on earth are these
>systems so large??
The main reason, I suspect, is that being small wasn't much of a
priority when they were written. There must have been many cases
where they thought "should we make this smaller or faster?" and
chose faster.
They also tend to have more sophisticate compilers. It is possible
to have a reasonably good compiler that is fairly small, but such
compilers will fall short of the best compilers in various ways
(by doing fewer optimizations, for example).
And then there are the built-in functions. KCL implements the
sequence functions in a straightforward, but not very efficient,
way. A commercial CL may make a much greater effort to handle
different sequence types in different ways. Lists, simple-vectors,
strings, simple-strings, vectors, and strings might all be different
cases.
-- Jeff
I'm looking for a simple algebraic manipulator which will run
on a Symbolics. It should be able to take something like:
(x = 14y + z), and 'z
and return: z = x - 14y (i.e. solving the equation for z).
Not much more complicated than that. Does anyone know of such
a package that wouldn't cost (too much) money? Macsyma is an
overkill of such a pkg, and is VERY expensive.
Thanks,
Jody
From: Rajeev Jayavant
Subject: Re: Re: Looking for KCL on MIPS & AKCL.
Date:
Message-ID: <20220001@hpfcdj.HP.COM>
/ hpfcdj:comp.lang.lisp / ·····@math.uio.no (Espen J. Vestre) / 8:54 am Oct 31, 1990 /
>> Just curious:
>> Are there any people using AKCL for serious purposes? I just find it
>> funny that people are asking for AKCL on all these fancy machines - the
>> cost of one of the fine commercial lisps is probably usually minor
>> compared to the hardware costs involved.
The group I worked with at MIT uses KCL as the base for its software
environment. We initially started out using Franz/Allegro and
switched to KCL for several reasons. The main one was startup time of
dumped executables - KCL is several times faster. The other is that
we were able to build KCL dumped executables in a way that allowed a
great deal of code to be shared among several processes, reducing
demands on the VM system and reducing swap space requirements.
Although it wasn't a significant factor in our decision to switch to
KCL, you have to remember that there are long-term costs for using
"one of the fine commercial lisps". You do want software upgrades,
don't you (especially if you're doing something serious)? KCL is pd,
updates are available over the net, and since it comes with source, we
could fix problems if we ran into them. I added a number of features
to KCL that tailored it for our use, making it more desirable than
most of the commercially available products.
>> It's not that I don't like pd programs, it's just that I tried a small
>> program I have that does some runtime compiling when loading, and I found
>> out that the the AKCL compiler is several times slower on a decstation
>> 3100 than the MACL compiler on the tiny-and-usually-regarded-a-toy
>> Macintosh SE!! (hw+sw costs about $2000...)
>> It must be a pain to develop software with it.
>> (I must admit that the code produced seems reasonably fast, however)
The fact that KCL is pd was another major reason for switching to it
from a commercial product. In a university research environment, it
is much easier to share your work with others if you don't have to
convince them to buy a license for some commercial product that they
do not already have.
I agree that the KCL compiler is slow, probably because of the
intermediate compile to C, but the bottom line is how fast the
resulting code runs. I am willing to spend a little more development
time to have a faster product. Besides, who says you need to compile
your functions all the time while you're developing code. Use
interpreted code until it seems reasonably stable and then compile it.
Or automate things to do you're compiling at night...
As to the MAC, you have to ask whether you really have comperable
capabilities in the Lisp environment before you can make comparisons
like that. It may be good enough for you example, but what about
"serious" work?
I like(d) developing in the KCL environment, especially after I hacked
in an interface to talk to a running KCL listener from a GNU emacs
buffer (like the emacs support in Allegro).
Rajeev
>> -----------------------------------------
>> Espen J. Vestre
>> Department of Mathematics
>> University of Oslo
>> P.o. Box 1053 Blindern
>> N-0316 OSLO 3
>> NORWAY ·····@math.uio.no
>> -----------------------------------------
-------------------------------------------------------------------------------
Rajeev Jayavant (······@hpfcla.hp.com) "Excuse me, I've lost my marbles"
Hewlett Packard - Graphics Technology Division - P. Opus, [Bloom County]
From: ···@paradigm.com
Subject: "fine commercial lisps" vs KCL vs other ways
Date:
Message-ID: <1353@paradigm.com>
You know what would improve the state of the art of lisp implementations
a bit? If somebody wrote a LISP front-end to GCC.
Really, it should be easier than the C++ stuff that was done with GCC.
Just handle the syntactic and lexical scoping issues (GCC already handles
most of the control construct issues that come up), and *dont* *worry*
about garbage collection. Pass lisp arguments just like arguments
to C procedures.
A definite must: Implement numeric declaration optimizations, fixnums
and floats, for expression evaluation, argument passing and return values.
Another must: Translate the names of arguments and local variable symbols
as little as possible, make sure compiled code can be debugged effectively
using GDB.
As far as the GC goes, don't sweat it. I have some minor (in terms of
understandability) extensions to the techniques used in SIOD that handle
the C object vs. C object ambiguity extremely well in practice and while
supporting the more modern lisp data structures.
The result: A production-quality lisp that lives up to the standards of
PDP-10 maclisp and more. A portable lisp with an understandable and
nearly universally supported compiler.
Maybe RMS will spend some of that MacArther money he won on a lisp
front end for GCC.
Or maybe somebody good enough will decide to stop screwing around
with stuff like KCL and go for the brass ring.
-gjc
In article <····@paradigm.com> ···@paradigm.com writes:
>You know what would improve the state of the art of lisp implementations
>a bit? If somebody wrote a LISP front-end to GCC.
Well, it's not GCC-specific, but it seems like Chestnut's Lisp to C
translator does most of what you say. It also does GC (and provides ways
to control it) and generic arithmetic when declarations aren't provided.
About the only problem is that they charge about $100,000 for it.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: David Vinayak Wallace
Subject: "fine commercial lisps" vs KCL vs other ways
Date:
Message-ID: <GUMBY.90Nov5074810@Cygnus.COM>
Date: 2 Nov 90 14:02:11 GMT
From: ···@paradigm.com
You know what would improve the state of the art of lisp implementations
a bit? If somebody wrote a LISP front-end to GCC.
Jim Miller and I discussed this at the last Lisp conference, using GCC
as the back end for GAMBIT. You're right in that it wouldn't be that
hard, though there is a little more work than you implied.
Looking over my notes: PVM (GAMBIT's representation) or s-codes are a
little higher-level than rtl in that rtl doesn't understand things
like closure variables (e.g. for CL it could compile flet only if you
didn't use upward funargs) and a little low-level (ie rtl can
represent loops, so that it can do various optimisations; PVM
represents loops with branch instructions).
To do a decent lisp with GCC would require the following
modifications: The addition of an apply operator, since the calling
conventions differ, and a modification to procedure code generation so
that functions could have lisp entry points and optimised (post-arg-
checking) entry points for calling by C code and perhaps for
compiler-generated calls when the arity and type are known at compile
time. The calling sequence would have to be fixed too, of course.
The real problem is GC. You really want to tell the compiler about
register conventions it should share with the GC. Unfortunately most
processors now have register usage conventions which are followed by C
compilers and which don't allow you to be able to depend on this.
Also, several new machines have register windows which make it
expensive for the GC to scan the machine state (register windows also
make it extremely unpleasant to use any sort of closure as a funarg).
GCC naturally uses register windows heavily on the machines which
implement them.
We're modifying GCC to allow certain kinds of conservative GC without
scanning the machine registers or stack, but this isn't cheap either.
If you removed the requirement that the compiler trivially intercall
with existing programs then this would become a lot easier.
Using GDB on generated code would be easy in any case, but you'd lose
all the benefits of having lisp in your debugging environment!
Perhaps the thing to do would be to link parts of GDB into your
runtime.
The reason the FSF isn't doing anything like this appear to be a two
(but I don't speak for them): rms' priorities lie in different areas,
and you can't really just write a compiler: you have to write a whole
lisp implementation. Brian Fox wants to work on one; has anyone some
money for him?
From: Per Bothner
Subject: Re: "fine commercial lisps" vs KCL vs other ways
Date:
Message-ID: <11702@spool.cs.wisc.edu>
I've done some thinking about how to design a multi-language
integrated language environment, including Lisp support.
I've been working on a very high-level language, which supports
first-class functions, run-time types, abstract sequence objects,
and various other features. In other words, a language closer to
the Lisp family than C++. In spite of that, most of the run-time
system is written in C++, using a nihlib-like Object hierarchy.
I also compile my language into C++ (though the compiler suffers
from heavy bit-rot, since I'm waiting for some features to
be added to g++).
Some notes:
My compilation model is based on persistent objects, or saving
a workspace: A source "module" is loaded (parsed and evaluated),
and then the resulting "workspace" is "dumped." I write it out
as a C++ source file: The objects local to the workspace are
emitted as static C++ data declarations. The methods/functions
are compiled into source code. (I haven't worked on the compiler
for a while. I understand g++-2.0 will emit run-time type
descriptors. When available, I will remodel my "Class" class
to use these descriptors. This will allow me to simplify
the compiler, the run-time system, and the emitted C++ code.)
All objects are pointers. There are no tag bits on the pointers.
This allows compatibility with the C++ object model, which gives
uniformity, and easier interaction with other tools.
I pre-allocate "small fixints" (about the range -100..+1000)
for speed and space, and these are guaranteed to be "eq".
I use the DEC PRL package for infinite precision integer arithmetic.
However, I don't use their signed-magnitude implementation of
signed integers; instead I implemented a two's-complement package.
This allows fixnums to be a sub-class of bignums, which is quite
convenient: I can write a single implementation for (say) gcd,
or I can choose to write two (one bignum, one fixnum) for speed.
It also makes it easy to implementent the common lisp semantics
for logical operators, shifts, etc.
Symbols:
Symbols are conventional. So far I just implement "keyword"
symbols: No packages, "set", or property lisps, but adding
these shuld be straight-forward.
Since symbols must be interned, this causes a problem with
separate compilation: I emit C++ data declarations for
the various types of object; however each symbol with the
same print-name must be globally unique. I solve this problem
by emitting a symbol as an "extern" reference, and then using
the linker to actually allocate the symbols. (Currently, I
use a utility program prior to linking, but I would like to
merge this code into ld.c at some point.)
Functions: Functions are first-class, and closures are
generated automatically. Functions can take variable
number of parameters, defaults, and keyword parameters.
I support full logic programming
(logic variables, unification, backtracking, as well as
constraints); however, the implementation is undergoing change.
I'm experimenting with supporting shell-like features:
A command is a function that takes one string input (stdin),
some keywords (argv), and emits a string as output (stdout).
This makes a nice model for a functional shell.
A disk file is a string variable.
An open input file is a character iterator.
I've made some effort to make the syntax convenient and
pleasant for interactive use.
Garbage collecton. I have punted on garbage collection for
now. In the long run, I'm hoping to use the implementation
under development for Modula-3 by Eliot Moss and others,
especially if it can be adopted for C++ (or a dialect thereof).
Lisp: I have been thinking about putting a Lisp front-end
on my system (and making the needed changes to the run-times).
I've been toying with various Lisp dialects. One possibilty
is to take gnu emacs, and re-write the definitions of Lisp_Object
in terms of a C++ object hierarchy based on my existing system.
I don't know yet how pervasive the changes would have to be,
but since GNU code (including emacs) makes heavy use of
accessor macros, I hope it would not be too bad. And the
benefit would be an extensible, object-oriented emacs,
in addition to providing a lot of useful library routines
for my own language.
Availability: Well, not really yet. There is very little
documentation, the code is not robust (poor error recovery),
I constantly re-write lange portions of it, there is lots
of obsolete or no-longer-working code, and the compilers
emit many warnings (mostly about const/non-const mismatches).
The code has only been tested recently on a 68020 system
running 4.3 bsd (Sony News), though in the past it ran on
VAX ultrix. I believe it should port easily to any machine
with gcc and g++. Berkeley a.out format would be a plus.
There are some machine dependencies (including assembley code);
the major ones are to support backtracking (which is not essential
and will probably be replaced anyway).
If there is interest, I could make a version available,
to (brave) people who will to return improvements to me.
By the way, I call my language "Q", for no good reason.
Those who are interested could look at my dissertation:
Efficiently Combining Logical Constraints with Functions, Stanford, 1988.
It gives a flavor of an early version of Q, but the syntax has
changed quite a bit, and I've had some second thoughts.
--
--Per Bothner
·······@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison