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 Tue, 22 May 2007 13:11:00 GMT
On the 0x2DD day of Apache Harmony Gregory Shimansky wrote:
> On Sunday 20 May 2007 03:05 Egor Pasko wrote:
> > 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.
> 
> It is used for thread suspension, not just GC. But I think SIGUSR2 is quite 
> portable across different unix platforms. I meant hardware exceptions 
> handling code when I wrote about signals handling.

yep, they should be, let's hope for smooth porting :)

-- 
Egor Pasko


Mime
View raw message