eczjr@clan.nott.ac.uk (John Richards) (10/26/90)
In article <1990Oct22.203128.8763@watdragon.waterloo.edu> sgwoods@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 : eczjr@clan.nott.ac.uk Dept. of Chemical Engineering | : ecxam@vax.nott.ac.uk Nottingham University | tel : (0602) 484848 x2956 Nottingham, NG7 2RD | fax : (0602) 588138
espen@math.uio.no (Espen J. Vestre) (10/31/90)
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 espen@math.uio.no -----------------------------------------
jeff@aiai.ed.ac.uk (Jeff Dalton) (11/01/90)
In article <1990Oct31.155432.16911@ulrik.uio.no> espen@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
jayavant@hpfcdj.HP.COM (Rajeev Jayavant) (11/02/90)
/ hpfcdj:comp.lang.lisp / espen@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 espen@math.uio.no >> ----------------------------------------- ------------------------------------------------------------------------------- Rajeev Jayavant (rajeev@hpfcla.hp.com) "Excuse me, I've lost my marbles" Hewlett Packard - Graphics Technology Division - P. Opus, [Bloom County]
espen@math.uio.no (Espen J. Vestre) (11/02/90)
In article <3685@skye.ed.ac.uk> jeff@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 espen@math.uio.no -----------------------------------------
jeff@aiai.ed.ac.uk (Jeff Dalton) (11/06/90)
In article <1990Nov2.094418.9391@ulrik.uio.no> espen@math.uio.no (Espen J. Vestre) writes: >In article <3685@skye.ed.ac.uk> jeff@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