Re: [Sablevm-developer] Porting SableVM to ARM: Questions

[Etienne M. G. <eti...@uq...>]

On Wed, Dec 04, 2002 at 10:29:27PM -0700, Gunda Domlur wrote:
> I think so. I will check again. I had to do one thing out of the ordinary 
> though. Jikes did not compile on our system (arm/linux), mostly because we 
> don't a working C++ compiler :-(

Ah!  A good reason for writing the VM and class libraries in plain C. :-)

> and  The sablevm-class library was built on a 
> P4/Linux machine and then the whole /usr/local/lib/sablevm/classes-1.0.5 
> contents were ftp'ed to the arm/linux system to the same path. This step 
> shouldn't affect anything I think. Let me know if I got anything wrong.

It should be OK.

> >Also, why are you specifying: -c "/usr/local/lib/sablevm/classes-1.0.5" ?
> 
> I thought this was the way to tell the sablevm the class path. How does the 
> vm know where to look for the class libraries ? 

The default "boot class path" is hardcoded in the VM (value given by
the GNU configure stuff), but can be dynamically specified on the
command-line using "--property".  The command-line options are
documented in an appendix of my thesis(to be made public very soon).

The "application" class path defaults to "." and can be changed using
the --classpath command-line parameter.  "boot" and "application"
class path are managed separately, which simplifies users life a
lot. (Usually, a user should't play with the booclasspath).

So, you could write:

sablevm --property "sablevm.boot.class.path=/usr/local/lib/sablevm/classes-1.0.5" --classpath .:$HOME/classes HelloWorld

For frequently used properties, you can put the into either
/etc/sablevm or $HOME/.sablevm like this:

# beginning of file

property = sablevm.boot.class.path=/usr/local/lib/sablevm/classes-1.0.5

# end of file

> OK I can help with part (a).
> 
> I don't fully understand part (b). After I get the basic interpreter going 
> I intend to work on the inlining part too. I will bug you again on that. 
> Meanwhile if you can elaborate on the "inlinability" that would get me 
> started thinking ...

Chapter 2 of my thesis should help you there.


FYI.  I usually use gdb (or more specifically ddd) to debug sablevm.
You should definitely build sablevm with:
 
./configure --enable-debuggin-features

This will make debugging much easier, as the normal build puts a
"segfault" (which is then catched through a signal habdler) on the
normal execution path of VM bootstrap... This can be somewhat
unsettling for new developers trying to understand what's
happening. ;-)

Have fun!

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/