enevill at arm.com
Fri Jul 10 06:20:39 PDT 2009
>I finally got a chance to look at this today. I don't have ARM
>hardware so I can't try it, but I've been looking at the sources
>to see how it all hooks in.
If you need some ARM hardware I am going on holiday from Weds of
next week so could lend you one of my boards for 3 weeks.
Alternatively, I could make arrangements for you to access the
boards on my desk remotely - but that won'cput help you if you need
to reset them.
>I have to say I'm a little confused by how it relates to Zero.
>I see that you have asm method entries for everything that Zero
>has a method entry for, and looking at the symbols the assembly
>code references it doesn't seem to call back into any Zero code.
>So it seems that the only bit of Zero it uses is the call stub.
>Am I right?
Hmmm. Yes, possibly. I hadn't realised how little of Zero it
still depends on. It started depending on a lot more when I
only optimised bytecodeInterpreter.cpp, but as I moved to
optimising the entry points (normal_entry and then native_entry)
it grew less and less.
Here are the pieces of Zero I believe it still uses.
- It uses the Zero stack.
- It uses Zero in all the cases it cannot support IE
UseCompiler == true
TaggedStackInterpreter == true
JvmtiExport::can_post_interpreter_events == true
- It uses a lot of the other files in cpu/zero/vm.
assembler_zero.cpp, bytecodeInterpreter_zero.cpp, ...
May of these are just Unimplemented() or have trivial implementations.
- It uses 'ffi' to do native calls, so relies on stuff in
interpreterRT_zero.cpp to do the signature parsing.
- It relies on all of os_cpu/linux_zero/vm/... I haven't touched any
So it is still reliant on quite a bit of Zero.
More information about the zero-dev