sablevm-user

[Sablevm-user] Greetings!

[Brent F. <bre...@xp...>]

Hi,

I just found your website today.  I was wondering what kind of state
SableVM is in?  I am particularly interested in features of SableVM
that might make implementing functional programming languages on top
of the VM easier...

Thanks,

-Brent

Re: [Sablevm-user] Greetings!

[Etienne M. G. <eg...@j-...>]

Hi Brent.

SableVM is not yet able to run programs (as you may have discovered
already), but it is quite close to it.  Mainly, what is missing is the
native implementation of VM specific classes required by
classpath/sablepath.  (System, Runtime, Thread, etc.)  Also, there are a
few missing bytecodes (wide, multianewarray,...).  So, you may expect to
be able to run simple benchmarks/toy programs soon.

In the last 3 weeks, I wasn't working on the VM, because I had other
research matters to attend to (like presenting a paper at SAS200, and
doing some related work).  I am now working full time on the VM, so
things should progress roundly.

Given the structure of the VM, it should be easy to extend the
instruction set, if this is what you are looking for.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-user] Greetings!

[Brent F. <bfu...@de...>]

On Fri, Jul 14, 2000 at 05:48:40PM -0400, Etienne M. Gagnon wrote:
> SableVM is not yet able to run programs (as you may have discovered
> already), but it is quite close to it.  Mainly, what is missing is the
> native implementation of VM specific classes required by
> classpath/sablepath.  (System, Runtime, Thread, etc.)  Also, there are a
> few missing bytecodes (wide, multianewarray,...).  So, you may expect to
> be able to run simple benchmarks/toy programs soon.
> 
Understood.  I wonder if any of the comparable classes used in Japhar
or Kaffe could be used as a starting point...

> In the last 3 weeks, I wasn't working on the VM, because I had other
> research matters to attend to (like presenting a paper at SAS200, and
> doing some related work).  I am now working full time on the VM, so
> things should progress roundly.
> 
I know just what you're talking about.  I fully understand how outside
time constraints can minimize the time available for these projects.  

> Given the structure of the VM, it should be easy to extend the
> instruction set, if this is what you are looking for.
> 
Well, I located this project while trying to find information on
running Haskell and other functional language interpreters on top
of a Java VM.  You may be familiar with Kawa, which is a Scheme
implementation on a JVM (or JPython for that matter).

My requirements are:
* Open Source
* Efficient
* Embeddable.

The goal is to eventually (whew) build a sort of generic extensible
platform on top of some kind of VM architecture.  The "platform"
would be capable of running various interpreters for different
front-end languages (e.g., Scheme, Haskell, CAML, etc.).

This is obviously far in the future, but the idea came up while
talking with some people on the Guile list about how hard it might
be to do so.  (Since Guile is aimed at translating other scripting
languages [Tcl, Python, etc.] into Scheme for use in Guile).

I thought it might be better (performance-wise) to do things around
a virtual machine, rather than try to translate source-code on
the fly.  We'll see.

At any rate, I learned through my reading that certain functional
programming features (like closures) are hard to implement
efficiently on top of Java.  So, my question.

At any rate, I'm not much of a compiler hacker, but I do happen
to have a copy of the JVM book (O'Reilly's) now, so maybe I
can be of some help? ;-)

Thanks,

-Brent

Re: [Sablevm-user] Greetings!

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> >  Mainly, what is missing is the
> > native implementation of VM specific classes required by
> > classpath/sablepath. ...
> Understood.  I wonder if any of the comparable classes used in Japhar
> or Kaffe could be used as a starting point...

Not really.  That is the catch.  These thigns are really VM dependent. 
As SableVM's internal object layout is quite different from these vms, I
must re-implement them.

> ... You may be familiar with Kawa, which is a Scheme
> implementation on a JVM (or JPython for that matter).

Yeah.  I used some Kawa/Scheme class files to test my type inference
algorithm (the paper I presented).

> My requirements are:
> * Open Source
> * Efficient
> * Embeddable.

This VM might be OK for your needs.

> At any rate, I learned through my reading that certain functional
> programming features (like closures) are hard to implement
> efficiently on top of Java.  So, my question.

Yep.  The Java vm is pretty much tuned to execute Java code.  You would
probably need to rethink part of the vm to get native support for
closures.

> At any rate, I'm not much of a compiler hacker, but I do happen
> to have a copy of the JVM book (O'Reilly's) now, so maybe I
> can be of some help? ;-)

Of course!  It's still a little early, as I need to get a somewhat
functional vm before splitting tasks among people, but you can start
looking a little around the code, to get a feel of it.  One of the
greatest help areas would be in the sablevm/sablepath integration.  The
native code in sablepath seems to be in great need of improvement.  But,
if you are interested in vm specific coding instead, I will also need
help (to be defined;-).

I use the official vm specification (version 2), as reference for the
implementation.  I have the book, but you can find it online at:
http://java.sun.com/docs/books/vmspec/

Have fun!

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-user] Greetings!

[Brent F. <bfu...@de...>]

On Fri, Jul 14, 2000 at 11:15:08PM -0400, Etienne M. Gagnon wrote:
> Brent Fulgham wrote:
> > >  Mainly, what is missing is the
> > > native implementation of VM specific classes required by
> > > classpath/sablepath. ...
> > Understood.  I wonder if any of the comparable classes used in Japhar
> > or Kaffe could be used as a starting point...
> 
> Not really.  That is the catch.  These thigns are really VM dependent. 
> As SableVM's internal object layout is quite different from these vms, I
> must re-implement them.
> 
Well, I suppose that makes sense after all.  But of course the bright side
is that it provides an opportunity to do things *right* :-)

> > At any rate, I learned through my reading that certain functional
> > programming features (like closures) are hard to implement
> > efficiently on top of Java.  So, my question.
> 
> Yep.  The Java vm is pretty much tuned to execute Java code.  You would
> probably need to rethink part of the vm to get native support for
> closures.
> 
Well, and that's really the downside.  As a language base, the VM would
be fine I suppose even if it had some non-standard bytecodes defined.
However, the infrastructure required to implement closures might provide
some separate benefit for Java itself (perhaps through providing a more
efficient means of handling certain functions).  But this is not based
on anything more than my musings right now.

> greatest help areas would be in the sablevm/sablepath integration.  The
> native code in sablepath seems to be in great need of improvement.  But,
> if you are interested in vm specific coding instead, I will also need
> help (to be defined;-).
> 
Fine.  I won't be able to do much for the time being anyway.  I'm trying
to make my way through a bunch of reference material I've accumulated
recently and I want to get that done soon.  I'm actually looking forward
to reading the VM code you've produced as a learning experience.

As I said, VM hacking is not my forte (yet), but implementing some sablepath 
classes and native glue should be doable.  It should make for some nice small
bits that could be implemented piece by piece.  Let me know what you are
thinking regarding what sequence things should be done in, etc.

Oh, I have a Sourceforge login, by the way, "bfulgham", in case you
wanted to add me to the project at some point.

> I use the official vm specification (version 2), as reference for the
> implementation.  I have the book, but you can find it online at:
> http://java.sun.com/docs/books/vmspec/
> 
Great.  Sounds like a lot of fun!

-Brent

Re: [Sablevm-user] Greetings!

[Etienne M. G. <eg...@j-...>]

Brent Fulgham wrote:
> Well, and that's really the downside.  As a language base, the VM would
> be fine I suppose even if it had some non-standard bytecodes defined.
> However, the infrastructure required to implement closures might provide
> some separate benefit for Java itself (perhaps through providing a more
> efficient means of handling certain functions).  But this is not based
> on anything more than my musings right now.

It is worth trying.  If there's something I have learned, it is that you
don't really know before you have tried something.  Sometimes, you get
unexpected results (which can be good or bad news:-).

> >
> Fine.  I won't be able to do much for the time being anyway.  I'm trying
> to make my way through a bunch of reference material I've accumulated
> recently and I want to get that done soon.  I'm actually looking forward
> to reading the VM code you've produced as a learning experience.
> 
> As I said, VM hacking is not my forte (yet), but implementing some sablepath
> classes and native glue should be doable.  It should make for some nice small
> bits that could be implemented piece by piece.  Let me know what you are
> thinking regarding what sequence things should be done in, etc.

In fact, you can simply export CFLAG='-Werror -O0 -ggdb' then try to
"make clean; make" sablepath.  You will discover that there are many
warnings.  Many of these seem suspicious, and there is certainly some
way of writing the code such that no warning is issued (other than
turning off warning options;-).  This could be a starting point, if you
like.  Mainly, you can look at *.c files under sablepath's native/
directory and fix any problem you find.

You should probably find the book "The Java Native Interface", ISBN
0-201-32577-2.  It is the definitive reference for the JNI.  It also
contains programming tips and tells you about pitfalls.  Interesting
reading.

> Oh, I have a Sourceforge login, by the way, "bfulgham", in case you
> wanted to add me to the project at some point.

Done.

Have fun!

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-user] Greetings!

[Etienne M. G. <eg...@j-...>]

Hi Brent.

"Etienne M. Gagnon" wrote:
> In fact, you can simply export CFLAG='-Werror -O0 -ggdb' then try to

Obviously, what I really meant was CFLAGS (with an S).

I noticed you have a "debian" address, so I guess you might know a
little about *.deb packages.  Building Debian source/binary packages
would be useful, too;-)

Feel free to pick whatever help area you are interested in.  If you
discover anything you think you'd like to do, just suggest it.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-user] Greetings!

[Brent F. <bfu...@de...>]

Etienne,

To my knowledge, I have *NOT* ever agreed to the SUN community
source license.  I have also never seen any source code for the
SUN base classes.

I have downloaded the SUN Java tools, but I don't believe this
requires agreement with the SUN community source license.  I know
I have also downloaded documents and some proposed specifications
from their site, but I do not believe any of these required any
special agreements.

I know that I have never physically signed any documents (including
NDA, non-compete, etc.) or done any work with them.  I have never
received source code from SUN or others related to the SUN tools.

I have been conscious of the licensing issue since I played with
Japhar/Classpath and did not want to taint anything.

Yes, I am a Debian developer, so I will be more than happy to 
produce binaries for the Debian system whenever you feel that
Sable is in good shape.

I will download the source code and try a quick compile to see
how things go!  :-)

-Brent



> -- 
> ----------------------------------------------------------------------
> Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
> Author of SableVM:                             http://www.sablevm.org/
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> Sablevm-user mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-user

Re: [Sablevm-user] Greetings!

[Etienne M. G. <eg...@j-...>]

Hi Brent.

> To my knowledge, I have *NOT* ever agreed to the SUN community
> source license.  I have also never seen any source code for the
> SUN base classes.

Terrific!

> Yes, I am a Debian developer, so I will be more than happy to
> produce binaries for the Debian system whenever you feel that
> Sable is in good shape.

That would be really great!

> I will download the source code and try a quick compile to see
> how things go!  :-)

Tell me if you have any problem, so that we make it as easy as possible
for people to compile the thing.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------