Couple of places one can start:
        - SBCL - Start from some platform closest to ARM, and progress there -
compiler/runtime/assembler
        - CMUCL - kind of like SBCL?
        - OpenCCL
        - Corman Lisp - yes it's for Windows, but it's full with LAP code that
might be easier to port, then again it's commercial product, not sure
whether one can extend it like that.
        - ECL and GCL are interpretters, they do compile to C, but the
resulting code is still not that efficient (boxing, no global
optimization used) - and requiring "C" compiler on the embedded device
seems a little bit too much.
        - CLISP is interpretter.

As always there are the interpretters, but I'm really looking forward to
a compiler - something that's at most x3-x5 slower than C, not more than
that.

IIRC, CLISP and ECL are already running on ARM. So you could use
either one
and have a relatively fast byte-code engine.

If you are looking for a native code compiler, then I guess you are
out of luck.

This is exactly what I had in mind, but worded it wrongly - a native ARM
compiler.

this looks like a case of premature optimization. do you have particular use
case
in mind, or you just want a compiler for a sake of compiler? last time i've
checked, ECL/GCL were doing number crunching code pretty well, there
was no boxing. as for the rest, i doubt it is really critical.

 DmS> no global  optimization used)

again, i doubt global optimizations will ever help you to run program
which you otherwise could not run.

 DmS> - and requiring "C" compiler on the embedded device
 DmS> seems a little bit too much.

can't you just compile it once and deploy on devices in a compiled form?
programs that really need compiler in runtime are very rare.

unless you're going to do all the development on the device itself..

in ECL there is such option in configure script:

--with-cmp              build in the compiler (default=YES)

 de> Do these projects have easy ways of chopping out parts of the run-time
 de> environment?

I'm mainly generating data into single-float simple-arrays, which are
later drawn by OpenGL ES.

My code is currently in C/Objective-C and for experimental purposes
(faster iteration) I would like to move that piece to Lisp (I'll move it
back to "C" when I'm satisfied). For example I'm getting 30-40fps with
it, half of the time spent in the vertices generator, the other time
spent in drawing, so I expect a reasonable 3-4 times slower LISP
implementation for the vertices drawing won't slow me that much.

Currently from the 30 ms, 16ms are spent on generating, 16ms on drawing.
If the first time goes 3-4 times up it's 48-64ms, total 80ms - about
12fps - which is bearable, but slower times that that It won't be really
what I need.

I haven't done tests of CLISP, ECL, GCL, etc. on the ARM device, but
have done such on X86, and the code is at least x20 times slower, and
this with compiler.

Haven't tried ABCL, but looked at what it generates through JAD, and it
does not look that optimized.

So native ARM Lisp Compiler would be good enough.

I do have similiar problem with porting my application to G1 Phone, in
the Davlik VM Java - it's slow too for what I need.

Granted, I don't need speed in other areas that I'll put - such as game
scripting, etc. - but exactly for vertices generation I do need :)

Maybe I'll stick with "C" for now, and just dream of it :)

reference:   http://www.gigamonkeys.com/book/conclusion-whats-next.html

if that is your device, why not install gcc on it.

 DmS> I haven't done tests of CLISP, ECL, GCL, etc. on the ARM device, but
 DmS> have done such on X86, and the code is at least x20 times slower, and
 DmS> this with compiler.

that's weird, maybe you don't have proper declarations? ECL does not seem
to have any type inference, but if you supply it with enough declarations,
it
is definitely able to create code with native peformance.

for example, simple function that sums elements in the vector:

(defun jspank (a)
  (declare (optimize (speed 3) (safety 0))
           (type (vector single-float) a))
  (let ((x 0.0))
    (declare (single-float x))
    (dotimes (i (length a))
      (declare (fixnum i))
      (setf x (+ x (aref a i))))))

inner loop does not contain any inefficient calls, it is translated directly
to C constructs:

 V2= (float)(V2)+(float)((V1)->array.self.sf[V4]);
 V4= (V4)+1;
L9:;
 if(!((V4)<(V3))){
 goto L13;}
 goto L8;

 DmS> Haven't tried ABCL, but looked at what it generates through JAD,
 DmS>  and it does not look that optimized.

The page says "There are beta builds available for ARM/HPC/WCE300,
SH3/HPC/WCE211 and MIPS/HPC/WCE211."

There are many other binaries on this site (emacs, SWI Prolog, perl, .
..), several of which I have recently run under Windows Mobile 6.0
Classic. I have not touched the gcl.

First you need (simple-vector single-float), instead of vector, then
specifying that it's one dimensional helps further (simple-vector
single-float (*))

Little reorganization of the code, and more declares (I've even put
some Lispworks specific) and disassemble helps even further:

(defun jspank (a)
  (declare (optimize
            (speed 3) (safety 0) (debug 0)
            (compilation-speed 0) (space 0)
            #+lispworks (float 0)
            #+lispworks (fixnum-safety 0))
           (type (simple-array single-float (*)) a))
  (let ((val 0.0e0)
        (len (length a))
        (idx 0))
    (declare (single-float val))
    (declare (fixnum idx len))
    (loop
     (if (<= idx len)
         (setf val (+ (aref a idx) val)
               idx (+ idx 1))
       (return)))))

Off course my code is more, and less understanabdle, but if you have
cases where performace shows that they are slowing down, surely you
can do some more optimizations.

Indeed only one piece of my voxel-space renderer is floating-point
heavy (it generates a buffer with X,Y,Z U,V which is later drawn on
the screen).