Stefan Kain wrote:
> "Will there be any speed gain?"
> Unlikely. If so, I will be truly surprised. The generated object-code
> from this C-code will be significantly larger than the bytecode.
> The instruction cache is usually pretty small.
Generally, the technique you describe yields a little speed gain, for the exact reason you mention (removing one level of interpretation).
However to me, the question is: is it worth it?
o Native code compilers like CMUCL do one step more: they remove another level of interpretation, achieving *major* speed gains.
E.g., your C code will do lots of pushSTACK(arg0);pushSTACK(arg1);funcall(argf,2);
That means, it still operates on the CLISP stack and object model, like a JVM, while "true" native code goes one interpretation level beyond that.
o Common Lispers who really want native code have a vast choice of implementations (CMUCL, SBCL, POPLOG(?), ECLS, LW, ACL ...). Why should CLISP follow that beaten path?
o Something however, which is not there(?) is:
Common Lisp to JVM bytecode.
That'll be something new, well adapated to CLISP IMHO (because it already does some form of bytecode), and possibly more grateful than providing yet another Lisp->C translator, which is highly unlikely to beat CMUCL.
Even more advertising :): if you go into Lisp->JVM, you'll find yourself among very nice people, like Bruno Haible, working on something current (and shared with Smalltalker, Schemers, and half a dozen more languages).
With Lisp->C, you'll work with "old" people who've done that before (authors of the above implementations), and thus have memory and experience to help you, but it's not a hot topic for them anymore.
Just my 0,00$. I wanted to send that privately, but since you just wrote to the list...
Get latest updates about Open Source Projects, Conferences and News.