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 <[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. > > 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
