[Openmcl-devel] starting an openmcl session from inside another program
gb at clozure.com
Thu Jan 4 01:14:18 EST 2007
The stuff that the lisp kernel does in OpenMCL includes exercising
some control (in various ways) over the layout of the address space
that lisp runs in. Those ways include:
- ensuring that a couple of pages low in the address space can
have data from the lisp image mapped into them. (Keeping these
pages at "low" (near 0) addresses allows shorter/faster intructions
to be used to reference things like NIL; this is especially true
on the PPC, which has a "16-bit absolute" addressing mode.)
- mapping at least one other low-memory page at a fixed address
to allow lisp code to call runtime support functions ("subprimitives")
using efficient instruction sequences. (Again, this is more
important on the PPC and exploits a similar addressing mode.)
- tries to map "most of the available address space" (on 32-bit
platforms) or "as big a chunk of address space as it can get away
with" (on 64-bit platforms) and manage that address space as
"in use, not available to malloc or the dynamic linker, but
The platform-dependent address used here -might- not be available;
if a lisp image is mapped at some address other than the one
it was saved from, it can be relocated but that can take time.
If the lisp kernel was a shared library rather than an application,
it might be harder for it to exercise this control ("harder" might
or might not imply "impossible".)
You could conceivably rearchitect some of OpenMCL to relax some
of these requirements. For instance, you could keep the value of
NIL in a register rather than assuming that it's a constant, and
relocate all references to it when an image is loaded. If you
did that, the compiler would have one fewer register available
for other things and images would load a little more slowly.
"The ability to embed OpenMCL in arbitrary applications" has never
seemed to me to be a compelling argument against "trying to exploit
things that require control over the layout of the address space".
Does that make sense ?
On Wed, 3 Jan 2007, Joshua Moody wrote:
> In the ACL documentation, I see the following:
>> Any Unix or Windows program may serve as a Lisp main program if it:
>> Gathers up proper information about the locations of all necessary
>> Links or dynamically loads the Allegro Shared Library; and
>> Calls lisp_init() with the appropriate arguments before trying to
>> call any Lisp functionality.
> I believe this allows an ACL image to be created inside another
> Is there an equivalent mechanism in OpenMCL?
> Generally, I am investigating how to open a Lisp image from inside a
> C program.
> Specifically, I am trying to find a Lisp to use as front-end to the
> Breve simulator. I've investigated ECL, but have encountered
> problems using SLIME and some bizarre behavior while trying to use
> our in house CLOS utilities (which are portable across OpenMCL, MCL,
> ACL, and LW).
> I am woefully out of my depth here, so any advice or comments are
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel