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.
-Mark.
> > There are at least three locations that set up os/arch variables:
> >
> > build/make/build.xml setup.xml targets/ehwa.test.xml
> >
> > For now, I'm just going to update all three, but really we need to
> > figure out how to reconcile these. (Ideally, we should reconcile them
> > along with the classlib logic just as we need to figure out how to
> > reconcile the shared dependencies.)
> >
> > I plan to add an if.unix property (or three ;-). Similarly, I plan to
> > add an osfamily variable for use in the <select /> tags. Ultimately,
> > some of the directories called 'linux' might want to be renamed 'unix'
> > but I'll tackle that after I've seen what code is likely to be common.
> >
> > Is the ant variable vm.port.includes defined anywhere? (I spotted
> > ${vm.port.includes} in verbose logs and just wondered if this was
> > intentional?)
> >
> > Can we remove the env.MACHINE_ARCH variable and just use os.arch (as
> > classlib does)? Or is this a workaround for people building x86_64 with
> > an ia32 jvm?
> >
> > Quite a few files contain #include <malloc.h> but the linux/freebsd/osx
> > man page for malloc(3) says it should be #include <stdlib.h>. I seem
> > to recall making this change in classlib code at some point, but will
> > fixing this in drlvm break anything? Windows?
> >
> > I'll probably start making changes over the weekend. Once I've made the
> > basic build system changes then I guess I'll start looking at porting
> > the actual code.
> >
> > Regards,
> > Mark.
> >
> >
> >
>
> --
> Egor Pasko
>
