ARM Interpreter

[Edward Nevill]

I did not see that email as I was not subscribed to the ML when it was
written.

>Also, did you see this email?
>
>
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-July/006543.html

>Matthias Klose wrote:
>> +#if defined(PRODUCT) && defined(HOTSPOT_ASM)
>
>So my first question is why is everything conditionalized on PRODUCT?
>Not being able to build not-PRODUCT means no assertions, no debug
>helpers and no diagnostic options.  I'd like to see all these
>conditionals replaced with "#ifdef HOTSPOT_ASM".
>
>> +#endif

The reason everything is conditionalised on PRODUCT is that the Asm loop
will not work with a non product build. This is because all the offsets in
the structures change on a non product build because of the addition of
debug info into the structures.

You can still do a non PRODUCT build for debug purposes and get all the
assertions etc, its just you wont get the Asm loop at the same time, it will
revert to the C++ loop.

>HotSpot seems to follow the convention that #endifs are annotated:
>
>  #ifdef HOTSPOT_ASM
>  ...
>  #endif // HOTSPOT_ASM

OK. Will do.

>+ifdef ICEDTEA_ZERO_BUILD
>+ifeq ($(ZERO_LIBARCH),arm)
>+Obj_Files += cppInterpreter_arm.o
>+CFLAGS += -DHOTSPOT_ASM -DHW_NULL_PTR_CHECK -g0 -O2
>+%.o: %.S
>+     @echo Assembling $<
>+     $(QUIETLY) $(REMOVE_TARGET)
>+     $(COMPILE.CC) -o $@ $< $(COMPILE_DONE)
>+endif
>+endif

OK. Will do

Also. I think there is probably a better place for the .o: .S rule, but I
couldn't find any better placed that wasn't in OpenJDK code.

>> @@ -29,4 +29,32 @@
>>  void Bytecodes::pd_initialize()
>>   {
>>      // No zero specific initialization
>>      +#if defined(PRODUCT) && defined(HOTSPOT_ASM)
>     
>The "// No zero specific initialization" line needs removing, as there
>is now some zero specific initialization.

OK. Will do.

>> diff -r 914f2022b402 ports/hotspot/src/cpu/zero/vm/mkbc.c
>
>This file isn't part of HotSpot, it's a generator for some other files.
>Can it be placed into contrib?

I'm not sure where the best place for this is. The mkbc.c generates the mkbc
tool which generates the bytecodes.s file from the bc.def file.

Ideally this would all be part of the build and the bytecodes.s file would
not need to be checked in because it would be generated from bc.def.

However, currently I have included the bytecodes.s file manually generated
because I am unclear how to handle the mkbc tool in the OpenJDK / IcedTea
build.

Regards,
Ed.