Has been asked, was needed, but if one is to start an experimental ARM
lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an easy
way?
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.
- Off course - Ocaml is there, once the ARM Lisp Compiler is born Jon
can post how awesome it is.
On 12 Jan., 20:56, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> Has been asked, was needed, but if one is to start an experimental ARM
> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an easy
> way?
>
> 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.
>
> - Off course - Ocaml is there, once the ARM Lisp Compiler is born Jon
> can post how awesome it is.
CLISP, ECL and GCL are not 'interpreters'. They include an interpreter
and a compiler.
ECL and GCL compile to native code via compiling to C. CLISP compiles
to a byte-code,
which is executed by a byte-code interpreter - it is kind of a virtual
machine.
CMUCL also includes such a virtual machine (additionally to an
interpreter and
a native code compiler), where you can mix code freely running native,
byte-coded or interpreted. ECL also has such a byte-code interpreter.
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.
Though it might be interesting to have a native code compiler. There
are some
non-phone computers running Linux on ARM. On the phone side, Apple
does not
allow running Lisp (and similar languages) on the iPhone, Google's
Android
uses their own kind of java virtual machine, ...
······@corporate-world.lisp.de wrote:
> On 12 Jan., 20:56, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
>> Has been asked, was needed, but if one is to start an experimental ARM
>> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an easy
>> way?
>>
>> 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.
>>
>> - Off course - Ocaml is there, once the ARM Lisp Compiler is born Jon
>> can post how awesome it is.
>
> CLISP, ECL and GCL are not 'interpreters'. They include an interpreter
> and a compiler.
> ECL and GCL compile to native code via compiling to C. CLISP compiles
> to a byte-code,
> which is executed by a byte-code interpreter - it is kind of a virtual
> machine.
> CMUCL also includes such a virtual machine (additionally to an
> interpreter and
> a native code compiler), where you can mix code freely running native,
> byte-coded or interpreted. ECL also has such a byte-code interpreter.
>
> 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.
Thanks, Rainer!
This is exactly what I had in mind, but worded it wrongly - a native ARM
compiler.
>
> Though it might be interesting to have a native code compiler. There
> are some
> non-phone computers running Linux on ARM. On the phone side, Apple
> does not
> allow running Lisp (and similar languages) on the iPhone, Google's
> Android
> uses their own kind of java virtual machine, ...
Still for internal development, ad-hoc distribution, and non-G1 Android
development - you are free to do that. And there should not be any
problem with Windows Mobile.
> - 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.
Therefore, one could conclude you need either an interpreter or
externally compiled code.
For the former, I would recommend CLISP, for the latter I don't know
how to do it without using Linux in both the ARM and the external
systems.
DmS> - ECL and GCL are interpretters, they do compile to C, but the
DmS> resulting code is still not that efficient (boxing,
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..
that said, i don't think that having gcc on the device is anyhow
more weird than having SBCL on the device.
On Jan 13, 4:32 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> 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.
How would one take ECL or GCL and generate a run-time environment that
does not include the compiler? (Meaning, not include the LISP-to-C
compiler?)
Do these projects have easy ways of chopping out parts of the run-time
environment?
de> How would one take ECL or GCL and generate a run-time environment that
de> does not include the compiler? (Meaning, not include the LISP-to-C
de> compiler?)
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?
there are some more options in ECL. if something's missing, i think it
would be pretty easy to modify make files to exclude something.
Alex Mizrahi wrote:
> DmS> - ECL and GCL are interpretters, they do compile to C, but the
> DmS> resulting code is still not that efficient (boxing,
>
> 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..
>
> that said, i don't think that having gcc on the device is anyhow
> more weird than having SBCL on the device.
>
>
Unfortunately the interpretted speed is not enough with these LISP
environments. I want to avoid "C" library linkage, as I would like to
iteratively develop on the device, and that would beat it's purpose.
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 :)
I'm still in my Common Lisp Diapers, but I might try to start a backend
for SBCL, or any of the others - I just have a feeling that would drive
my project too far away, nevertheless it would be interresting...
On Jan 13, 1:47 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> 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.
Wow... Once OPTIMIZE and DECLAREs are coordinated for speed, the
compilers I've tried make really fast code (GCL and SBCL I've tried
this on).
reference: http://www.gigamonkeys.com/book/conclusion-whats-next.html
If OPTIMIZE options aren't set for speed at the expense of others [ie,
(OPTIMIZE (SPEED 3) (SAFETY 0) (DEBUG 0))], I've noticed that these
Lisps will tend to use DECLAREd data types to insert _more_ type
checking code...
On Tue, 13 Jan 2009 10:47:14 -0800, Dimiter \"malkia\" Stanev wrote:
> 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).
Well, if you are using Objective-C and you want something more
interactive, you might also see what kind of Smalltalk implementations
are available for ARM.
Matt
--
Truth will out this morning. (Which may really mess things up.)
DmS> Unfortunately the interpretted speed is not enough with these LISP
DmS> environments. I want to avoid "C" library linkage, as I would like to
DmS> iteratively develop on the device, and that would beat it's purpose.
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.
yep
On Jan 14, 6:32 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> DmS> Unfortunately the interpretted speed is not enough with these LISP
> DmS> environments. I want to avoid "C" library linkage, as I would like to
> DmS> iteratively develop on the device, and that would beat it's purpose.
>
> 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.
>
> yep
Thanks, Alex, but what you have posted generates definitely slower
(but more general) code for AllegroCL, LispWorks, OpenMCL, CMUCL and
SBCL.
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).
I surely don't need to optimize other pieces of the code, just that
pieces, and it contains operations such as above.
1/12/2009 5:19:45 PM
"Dimiter \"malkia\"Stanev" <······@mac.com> wrote in message
<············@malkia.motzarella.org>
> Has been asked, was needed, but if one is to start an experimental
ARM
> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an
easy
> way?
>
[snip]
There is a 2001 gcl 2.4.0 implementation for ARM here: http://www.
rainer-keuchel.de/wince/gcl-ce.html
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.
chw
C Wilson wrote:
> 1/12/2009 5:19:45 PM
> "Dimiter \"malkia\"Stanev" <······@mac.com> wrote in message
> <············@malkia.motzarella.org>
>
>> Has been asked, was needed, but if one is to start an experimental
> ARM
>> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an
> easy
>> way?
>>
> [snip]
> There is a 2001 gcl 2.4.0 implementation for ARM here: http://www.
> rainer-keuchel.de/wince/gcl-ce.html
>
> 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.
>
> chw
Thanks! I've used GCL on my HTC Universal (Windows Mobile 5) - but moved
to G1 Android and iPod Touch since then.
On Jan 12, 10:56 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> Has been asked, was needed, but if one is to start an experimental ARM
> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an easy
> way?
>
> Couple of places one can start:
> - SBCL - Start from some platform closest to ARM, and progress there -
> compiler/runtime/assembler
http://www.lisphacker.com/projects/sbcl-arm/port-log.txt (not finished)
stassats wrote:
> On Jan 12, 10:56 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
> wrote:
>> Has been asked, was needed, but if one is to start an experimental ARM
>> lisp compiler (iPhone, G1, Windows Mobile, etc.) - what might be an easy
>> way?
>>
>> Couple of places one can start:
>> - SBCL - Start from some platform closest to ARM, and progress there -
>> compiler/runtime/assembler
>
> http://www.lisphacker.com/projects/sbcl-arm/port-log.txt (not finished)
Thanks a lot! A lot of good stuff!