Zero/ARM

[Edward Nevill]

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

So it is still reliant on quite a bit of Zero.

Regards,
Ed.