Well, I have been looking comments for and against C++/LISP and quite a many peoples are complaining, that the lisp is not optimized??
We made some years ago an optimizing Lisp to C - translator for RS6000/AIX and SunOS environments.
Some material from those days follows -->
[
Lisp Kit and the attached tools were developed in Helsinki, Finland in 89 - 92 conjunction with the Episthema project, a Finnish government funded R&D project.
The developers were: Mr. Orri Erling (GC, Object System, RPC's), Mr. Petri Krohn (compiler) and Mr. Markku Laukkanen (compiler, type inferencing , run time functionality)
]
Lisp Kit Technical Overview
Is C The Only Way?
Many Lisp developers have turned to C simply because Lisp overhead in both space and time made it hard to compete against C based products. This conversion is costly and often requires stripping down features.
This is why Lisp Kit translates Common Lisp to C and allows choosing what parts of Common Lisp are needed with an application. Lisp Kit still retains the advantages of Lisp, such as automatic memory management and incremental loading of code.
Lisp Kit is specially geared toward delivering Lisp based applications. It is possible to develop on any Lisp platform and take advantage of sophisticated software development environments. When it is time to deliver software, you do not however want to pay megabytes of space for the ease of development.
So, if you are serious about developing and delivering on Lisp consider:
Facts
Optimizing Compiler. The C translator takes full advantages of type declarations to produce code typed at compile time.
Even without any type declarations code is optimized quite well( open coded structure accessors, when possible etc. etc. etc.)
600K Minimum Application. Lisp Kit applications start at 600K including GC, multiple stack groups, reader, fixnum arithmetic and almost every CLtL1 function (including eval!)
C Integration either through foreign functions with automatic type conversion and possibility of recursion between C and Lisp or plain in-line C code when speed counts.
No macros at run-time. Including macros and other macro or compile time definitions into an application is optional.
Fast, Compact Interpreter. Many applications need an extension language for customization. Lisp Kit offers a fast, compact interpreter that requires no other components.
Ephemeral GC. As all other state of the art Lisps, Lisp Kit offers a parametrizable ephemeral GC that makes memory management fast and unobtrusive. It is also possible to write garbage-free code by explicitly controlling memory management.
Using Lisp Kit we have developed the following programming tools.
Object System - The Lisp Kit object system has been inspired by knowledge representation systems such as KnowledgeCraft amd KEE. It features efficient worlds, daemons, multiple inheritance and CLOS like method combination discriminating on a single argument. Instance migration on class redefinition is supported as well as changing instances' class during the instance's life time.
Futures - This is a Lisp based RPC mechanism that allows processes to call arbitrary functions in other Lisp Kit ptocesses. Futures offer both synchronous and asynchronous RPC's over multiple threads in a peer to peer environment. Thus any Lisp Kit process can concurrently act as both a Futures client and server. The underlying protocol is TCP.
The external data representation supports any Lisp forms plus distributed objects with the Lisp Kit Object System.
Futures RPC's are also supported in C by use of the IdentiCom package. This allows C and Lisp processes to communicate with transparent data conversion and without need to know about the implementation language of the remote process.
Persistent and Distributed Objects - Objects in the Lisp Kit Object System can be transferred between Lisp Kit applications and sent messages using Futures. The external object representation can also be stored into an Object Oriented DBMS external to Lisp Kit.
Presentations - This is an object library that parallels the OSF/Motif's widget hierarchy. This makes it fast and convenient to develop Motif GUI's in Lisp. The Motif API can be accessed as foreign functions when required. Presentations translate between Lisp Kit objects and widgets
Total of 86820 lines lisp code , 2814 lines c code and 1619 lines h files.
83 lines SunOS assembler, 615 lines RS6000 assembler
Excluding OBDMS
Biggest Leaks in the system:
Doesn't support closures. (Easily done)
Doesn't support package functions. (Easily done)
Doesn't support bignum,ratio and complex arithmetics
Doesn't have a dumper. (data is always initialized, when the applications starts)
If somebody would send us the bignum code, (written in lisp) or algorithm, we could write that one,rewrite the compiler to generate three address code instead of complex C expressions (much more easier , closures and give you access to code in the Public Domain (would take something like 3 months to do).
PS.
how the lisp should be written?
LIKE THIS
(eval-when (compile)
(defmacro ar-maker (x y)
`(defun ,x (x y)
(declare (optimize (speed 3)(safety 0)))
(if (fixnump x)
(if (fixnump y)
(,y x y)
(if (floatp y)
(,y x y)
(ar-error x y ',y)))
(if (floatp x)
(if (floatp y)
(,y x y)
(if (fixnump y)
(,y x y)))
(ar-error x y ',y))))))
(ar-maker twoop+ +)
(ar-maker twoop- -)
(ar-maker twoop* *)
(ar-maker twoop/ /)
(ar-maker twoop< <)
(ar-maker twoop> >)
(ar-maker twoop<= <=)
(ar-maker twoop>= >=)
(ar-maker twoop= =)
(ar-maker twoop/= /=)
(defun + (&stack)
(case (%arg-count)
(0 0)
(1 (%stack-arg 0))
(2 (+ (%stack-arg 0) (%stack-arg 1)))
(t (let ((res (+ (%stack-arg 0) (%stack-arg 1))))
(let ((count (the fixnum (- (the fixnum (%arg-count)) 2))))
(declare (type fixnum count))
(dotimes (i count res)
(declare (fixnum i))
(setf res (+ res (%stack-arg (the fixnum (+ i 2)))))))))))
is easy to read (and understand ?) in any case!!
If somebody is interested, please contact by mail
······@ctron.com or
······@ctron.com or
·········@cc.helsinki.fi
PKY