ARM Interpreter

[Gary Benson]

Edward Nevill wrote:
> > 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".
> 
> 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.

That's really likely to break.  Would it be possible to have a table
of all the constants you use, and fill it in at VM startup?  The C++
interpreter's init code (bytecodeInterpreter.cpp, around line 560)
would be a nice place.  I saw you inlined ZeroFrame::SHARK_FRAME too,
that sort of thing could go there as well.

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

Maybe wherever it defines the .o: .cpp rule?  

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

Ah, ok.  Perhaps put mkbc.c in the top level directory, and build it
in the top level Makefile.  Have a look at the stamps/ports.stamp
rule, that's a decent example of something that needs running before
the main OpenJDK build happens.  There's also the corresponding
stamps/ports-ecj.stamp rule; sadly all this stuff is duplicated :(

Cheers,
Gary

-- 
http://gbenson.net/