From: Ronald
Subject: Need Common Lisp for 386 UNIX
Date:
Message-ID: <137@bsts00.UUCP>
Hi, does anyone know where I can get source to a common lisp
that will run on 386 AT&T style UNIX?
Thank's in advance.
Ron
--
Ron Bolin (404) 529-3945
BellSouth Services Rm 25M64, 675 W. Peachtree St. Atlanta, Ga 30375
USENET EMAIL/Reply To: ..!gatech!sbmsg1!bsts00!rlb
BellSouth EMAIL/Reply To: sbesac!!bsts00!rlb or aimsx!bsts00!rlb
From: ยทยทยท@cs.umass.edu
Subject: Continuations, executables, maths etc.
Date:
Message-ID: <26552@dime.cs.umass.edu>
> As an AI programmer, I'd have relegated all those math
> functions (branch cuts, etc.) to some distant shore, too.
As an academic I would be willing to lay bets on the immortality of the
work in symbolic mathematics for which LISP has been such an important
vehicle. As a FAAAI I would be inclined to lay fewer bets on the immortality of
the great bulk of work in AI, though I do believe that a significant
distillate will eventually emerge.
> Has anyone ever made a lisp-like compiler that produces relatively
> small stand-alone executables? Of course, there would be appropriate
> restrictions on the language, or even the ability to cons freely. But
> perhaps there's a large class of useful small applications that could
> be written with such a system, even with those limitations.
POPLOG Common Lisp produces a relatively small executable, since it relies
on autoloading to provide a large part of the Common Lisp capabilities.
I believe the U.Sussex team (John Gibson in particular) are aiming to provide
a capability of generating executables that contain ONLY what is required for
a given user program. This has long been identified by Integral Solutions Ltd.
as a capability their customers want, although I understand that the effort
required to support their C-based approach to X-windows has diverted them from
delivering this independent compilation capability in the next release (V14).
The approach adopted by Sussex to providing executables for a given program
makes use of the fact that the Poplog Virtual Machine exists in two forms.
One is an incremental code-generator that generates machine code for
the machine the system is running on. The other is a code-generator
that produces more-or-less conventional object modules, for a target
machine. These are linked with a more-or-less conventional linker
(I note on looking at the system sources that the linking and
library utilities are in fact POP-11 executables - hence I say
"more-or-less"). In principle, if the LISP compiler (or for that matter the ML
or Prolog compilers) were compiled on top of the second version of the Poplog
VM, then it would generate object code modules that could subsequently be
linked up to form an executable. The library mechanism would then be used
to provide just those system utilities that the user program required,
including the storage allocator if any consing was done, just as C programs
may need to have malloc linked in. One can conceive that various "el cheapo"
versions of the storage allocator could be provided if use of the heap by
a given program was limited.
I am not sure how much work needs to be done before this independent
compilation is released. Aaron Sloman is visiting me this week, and may be
able to elucidate the matter. Since the second version of the POPLOG VM is
currently used only to produce code for POPC (POP-11 extended to provide
C-equivalent control over the machine) and Prolog in particular requires
VM capabilities beyond those needed for POP-11, it is possible that some
extension is required.
> Hi, does anyone know where I can get source to a common lisp
> that will run on 386 AT&T style UNIX?
Claude Fennema at Mt. Holyoke College has a copy of POPLOG Common Lisp
running under SCO Unix on a 486. The original port was done on a 386.
The source of the LISP sub-system is provided as standard. Claude, who has
been programming in LISP since 1963, seems happy with it.
> There are some architectures where operations on the stack pointer register
> are restricted, so you can't just set the stack pointer to point to a
> heap-allocated activation record.
So, the "frozen" form of the activation has to be copied into the stack
space - feasible but expensive. Incidentally, what happens to Scheme
implementations on such architectures? My understanding of Scheme is that
it is so clean you should be able to set the hardware pointers from a
continuation and fire it up with almost no overhead.
> And what about the fact that call/cc makes unwind-protect more complicated;
> don't you have to provide code that runs when re-entering the environment?
> This means that the addition of upward control closures would not be
> transparent to implementors of many macros (e.g. WITH-OPEN-FILE would have
> to be changed to save its state in the closure and reopen the file and seek
> to the saved place upon re-entry).
The POP-11 "dlocal" capability provides for this kind of requirement, and is
integrated with the process creation mechanism. Thus, again, there would seem
to be no difficulty in providing a call/cc within POPLOG Common Lisp, although
the overheads would be high.