Subject: [clisp-list] A general query on the virtual machine

From: Scott Williams <[email-masked]>
Date: Fri Apr 12 17:37:01 2002

Browsing through the impnotes, i ran across this:

"The virtual machine

The bytecode can be thought of as being interpreted by a virtual processor.
The engine which actually interprets the bytecode (the "implementation of the
virtual machine") is actually a C function, but it could as well be a
__just-in-time compiler which translates a function's bytecode into hardware CPU
instructions__ the first time said function is called."

I'm interested in the part that's preceded by __'s: "just-in-time compiler
which translates a function's bytecode into hardware CPU instructions." How
hard would this be to do? I haven't dug extensively, and i'm still not very
familiar with clisp, but could anyone point me to more documentation on how the
bytecode compiler/interpreter works? :o) This is mostly curiosity, as i doubt
i'm skilled enough to actually implement a byte-code to native linux
assembler, but the attempt would improve my understanding of clisp and assembler.

Thanks,
-Scott

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

---

From: Peter Wood <[email-masked]>
Date: Fri Apr 12 23:02:02 2002

Hi,
On Sat, Apr 13, 2002 at 02:35:56AM +0200, Scott Williams wrote:
> but could anyone point me to more documentation on how the
> bytecode compiler/interpreter works? 

Impnotes is the documentation.  Apart from that, the source and your
friend, GDB.. 

Regards,
Peter

---

From: Sam Steingold <[email-masked]>
Date: Sat Apr 13 11:38:03 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] A general query on the virtual machine"
> * Sent on Sat, 13 Apr 2002 02:35:56 +0200 (MEST)
> * Honorable Scott Williams <[email-masked]> writes:
>
> ...a byte-code to native linux assembler...

look at interpret_bytecode_() in eval.d.
byte-code --> C compiler would be a great speed gain
(some estimate a factor of 3-4; it remains to be seen).

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
nobody's life, liberty or property are safe while the legislature is in session

---

From: Scott Williams <[email-masked]>
Date: Sat Apr 13 14:58:02 2002

> (some estimate a factor of 3-4; it remains to be seen).

So in theory, one would load all necessary functions into clisp, then export
the lispimage, then convert the lispimage to C, compile it, and link it with
the memory allocation functions and garbage collector---that would work to
make stand-alone executables (ie, no other files needed for the program to
run), but what sort of process would you go through so that natively assembled
object files could be loaded just like a bytecode FAS file?
-Scott

> _______________________________________________
> clisp-list mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>

---

From: Sam Steingold <[email-masked]>
Date: Sat Apr 13 15:54:01 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] A general query on the virtual machine"
> * Sent on Sat, 13 Apr 2002 23:57:19 +0200 (MEST)
> So in theory, one would load all necessary functions into clisp, then
> export the lispimage, then convert the lispimage to C, compile it, and
> link it with the memory allocation functions and garbage
> collector---that would work to make stand-alone executables (ie, no
> other files needed for the program to run), but what sort of process
> would you go through so that natively assembled object files could be
> loaded just like a bytecode FAS file?

these natively assembled object files will be linked into lisp.run
using the existing modules infrastructure or linked into a shared object
(DLL) and dynamically loaded into CLISP using the code Joerg is working
on right now (or so I hope :-)

note that we are talking pure sci-fi here already.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
Bus error -- please leave by the rear door.

---

From: Dan Stanger <[email-masked]>
Date: Sat Apr 13 19:45:02 2002

The gcj project which is a front end for the gnu compiler for java, can read java
byte codes
and convert them to a executable.  The Kaffe project has a jit for the java virtual
machine.
Perhaps one of these could be modified to be a jit for clisp.
Dan Stanger

---

From: Will Newton <[email-masked]>
Date: Sat Apr 13 20:00:02 2002

On Sunday 14 Apr 2002 3:45 am, Dan Stanger wrote:
> The gcj project which is a front end for the gnu compiler for java, can
> read java byte codes
> and convert them to a executable.  The Kaffe project has a jit for the java
> virtual machine.

Kava does Scheme -> Java Bytecode also.

---

From: Peter Wood <[email-masked]>
Date: Sun Apr 14 00:01:12 2002

Hi,

> (some estimate a factor of 3-4; it remains to be seen).

What is this speedup needed for?  If you need something to be fast in
Clisp, you could write it in C (.d), as a start.

Have you considered the disadvantages: much more space needed; added
complexity.

Is the general consensus that fast, faster, fastest == good, better,
best?   If that is an unconditional judgement, then move to CMUCL.

Regards,
Peter

---

From: [email-masked] (Don Cohen)
Date: Sun Apr 14 01:32:03 2002

> > (some estimate a factor of 3-4; it remains to be seen).
As this line already suggests, not everyone believes that estimate.
Most will readily agree that the factor depends a lot on what you
are doing.  My one data point is quite old now, but it was certainly 
evidence against such a factor.  I had a large body of code that was 
originally written for symbolics and had more recently been running
in lucid.  My tests ran only slightly faster in ACL (which is compiled
to machine code) than in clisp.  

 > best?   If that is an unconditional judgement, then move to CMUCL.
Or assembly language, or special purpose hardware.

The fact that someone uses lisp is already pretty good evidence that
he recognizes value in other things besides speed.  If you believe
that clisp is slower than other lisps then it seems likely that clisp
users are even more of that opinion than users of other lisps.  On the
other hand, most people will agree that faster is better if all other
things can be made to stay the same.  The added complexity above might
impact the compiler writer but not the lisp programmer, in which case
it's not a disadvantage for him.