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 <[EMAIL PROTECTED]> 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
