gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Various questions about GCL


From: Camm Maguire
Subject: Re: [Gcl-devel] Various questions about GCL
Date: 28 Sep 2004 12:06:25 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and please excuse the delayed reply!

"Goffioul Michael" <address@hidden> writes:

> Hi,
> 
>  
> 
> I'm currently evaluating GCL for use in our internal project. It has
> some nice features for our purpose but there are some issues and
> questions I'd like to ask. I put everything in one mail.  I'd be
> pleased to get some feedback/comments on these.
> 
>  
> 
> 1) Would it be possible to make GCL embedded into a C library
> (preferably shared) such that a 3rd party application could make
> use of GCL as an embedded computation engine? This would mean to
> have an API to initialize/terminate the GCL engine, to convert
> between C types and LISP objects, to "eval()" or "funcall()"
> arbitrary code. Our final target is actually to embed a LISP engine
> into a MEX file such that our framework written in LISP can be
> accessed from the MATLAB user interface.
> 

This is one of the topics I would like to discuss in setting
directions for GCL 2.7.x development.  In my opinion, lisp as
conventionally used is naturally limited to applications of great
complexity in a mostly single user environment.  If anyone ever wanted
to use list for something light that will run many simultaneous copies
on a given machine, the lack of a shared memory structure for at least
most of the base image would seem quite prohibitive.  

The machinery already exists (see separate post today) for conversion
between C and lisp types, and interfacing between lisp and C
functions, but the perspective is that one will typically be doing
this from within lisp, the 'higher level' of the two languages.  Doing
this rather from C is possible in principle, but might present some
surprises.  Calling main, eval, and funcall on compiled lisp objects
is straightforward.  eval is written in C -- function calling
semantics are best illustrated in o/funlink.c.

The real issue IMHO is handling the heap.  Right now, object code,
whether compiled from lisp or not, that is linked into the final image
via ld (e.g. see docs for compiler::link) is in the static .text
section of the executable.  Code dynamically compiled and generated at
runtime is added with all other data onto the growing heap, in the
.data section, expanded as necessary via sbrk.  Lisp is a very
'dynamic' language, so this heap is in a constant state of flux, and
must be garbage collected periodically.  So how does one share the
base heap image in a multi user environment?  If one could guarantee
mmaping the image to the proper location in the user process' memory
space, perhaps copy-on-write pages would still allow substantial
sharing.  But to be transparent with typical GCL usage, one needs to
somehow reset the end of the working .data section past the end of the
shared map.  Even more complicated would be interfacing with
saved-system, which would have to know which pages were dirty and
needed saving, and where they belong when the image is restarted.

If this nut could be cracked, I think it would open up many new
avenues for lisp.

>  
> 
> 2) Is there any FFI framework?
> 
>  

Yes, quite well established.  Please see my separate posting today for
some examples, and please write back if any of it is unclear.

> 
> 3) (make-hash-table :test #'equalp) is not supported
> 
>  

Yes, this is an ansi issue.  If it is important to your project, we
could move it up on the priority list.

> 
> 4) Code like the following does not compile:
> 
> (unless (find-package "MYPKG")
> 
>   (defpackage "MYPKG" (:use "COMMON-LISP")))
> 
> (in-package "MYPKG")
> 
> (export 'f1)
> 
> (defun f1 (x) (* x x))
> 

This compiles and works, to my understanding, but gives bad warnings,
which again is a known issue on our todo list.  The compiler has
traditionally required that all package operations be toplevel and at
the top of the source files.

Here is my session with your code:

=============================================================================
(sid)address@hidden:/fix/k/camm/gcl$ gcl
GCL (GNU Common Lisp)  2.6.5 CLtL1    Sep  3 2004 17:47:27
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(compile-file "/tmp/q.l")

Compiling /tmp/q.l.
; (IN-PACKAGE "MYPKG") is being compiled.
;; Warning: The package operation (IN-PACKAGE "MYPKG") was in a bad place.
; (EXPORT 'F1) is being compiled.
;; Warning: The package operation (EXPORT 'F1) was in a bad place.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /tmp/q.l.
#p"/tmp/q.o"

>(load "/tmp/q.o")

Loading /tmp/q.o
start address -T 0x83cdf70 Finished loading /tmp/q.o
144

>(f1 2)

Error: The function F1 is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at EVAL.  Type :H for Help.
>>:q

Top level.
>(MYPKG::f1 2)

4

>(by)
=============================================================================

>  
> 
> It complains at "in-package" statement. If I enclose the first 2 top-level 
> forms (unless, in-package)
> 
> into an "(eval-when (compile load eval) ...)" form, it compiles but doesn't 
> load (after restarting GCL),
> 
> still complaining at "in-package" statement.
> 
> (Note: I'm using anonymous CVS version under Linux)
> 
>  
> 
> 5) Would GCL compile/work under Win32/MSVC6?
> 

Mike Thomas is the man to ask here, but we have a quite functional
port under Win32/Mingw.  Would this suffice?

Take care,

>  
> 
> Thanks.
> 
>  
> 
> Michael.
> 
>  
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]