harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] Supporting more platforms
Date Sat, 19 May 2007 23:05:44 GMT
On the 0x2DA day of Apache Harmony Gregory Shimansky wrote:
> On Friday 18 May 2007 23:03 Mark Hindess wrote:
> > On 18 May 2007 at 9:58, Egor Pasko <egor.pasko@gmail.com> wrote:
> > > On the 0x2DA day of Apache Harmony Mark Hindess wrote:
> > > > I'm looking at what would need to be changed in drlvm to support more
> > > > platforms.  (Specifically, I'm looking at macosx/ppc32 and I'll
> > > > probably look at freebsd/x86 and maybe freebsd/x86_64.)  I thought I'd
> > > > mention some of the issues I've found so far regarding changes I plan
> > > > to make just to see if I'm taking a reasonable approach.
> > >
> > > my 2c:
> > > may be I am telling very obvious things, but...
> > >
> > > ppc32 is a lot of work for JIT. Unless we have dedicated people in
> > > Jitrino Code Generator for ppc32 a good JIT does not promise to happen
> > > soon. Although, the interpreter can be ported much faster.
> >
> > This is a spare time effort on my part so I'm not sure I'll even get
> > the interpreter ported!  I don't really have any expectations; I'm just
> > curious how far I can get.  My motivation was really to make it a less
> > daunting task for others thinking about new platforms.  These days intel
> > macs are probably more popular anyway but I don't have one - I only got
> > an old ppc mac on a whim a few weeks ago - and I thought adding a new
> > architecture would force me to get the necessary build structure in
> > place.
> 
> In my experience porting interpreter usually is equal to porting functions for 
> calling native methods. This requires implementing 
> interpreter_execute_native_method, interpreterInvokeStaticNative and 
> interpreterInvokeVirtualNative functions in interpreter like it is done for 
> ia32, em64t and ipf architectures. These functions are written in C and 
> prepare arguments for the method in an array (in different ways depending on 
> the architecture, e.g. x86_64 and IPF require distinguishing integer and 
> floating point arguments because they are passed in different registers) and 
> assembly code prepares them in the platform native C calling convention. The 
> rest of the interpreter should be platform independent.
> 
> Other than that there is a unix platform dependent code in signals handling. 
> For the most part the code is needed for hardware exceptions, JVMTI in JIT 
> mode and graceful crash handling, so I think it may be left unimplemented for 
> the start.

AFAIR, DRLVM uses SIGUSR2 signal for GC also, but you can run simple
tests having no GC, just to test the port implementation.

-- 
Egor Pasko


Mime
View raw message