On Aug 26, 7:55 am, Mercury <[email protected]> wrote:
> I do not understand the above algorithm and the meaning of every lines
> code that implement op code invoke static for ARM assembler
Some things are defined with C pre-processor macros in mterp/armv5te/
header.S. For example, rIBASE is the symbolic form of r8, and
EXPORT_PC() turns into a STR instruction.
> What is
>
> /* op vB, {vD, vE, vF, vG, vA}, cl...@cccc */
> /* op {vCCCC..v(CCCC+AA-1)}, m...@bbbb */
Those are comments referring to the Dalvik bytecode specification. If
you go to:
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dalvik-bytecode.html;hb=HEAD
and find "invoke-kind" and "invoke-kind/range" you will see similar
lettering. (The doc looks best if you pull it down and view it with
the associated CSS file. It's also found in dalvik/docs/dalvik-
bytecode.html in the source tree.)
> and what is the meaning of every line of above code, for example
>
> ldr r3, [rGLUE, #offGlue_methodClassDex] @ r3<- pDvmDex
>
> Could you help me how to understand the above code and the algorithm
> to implement op code invoke static? Do we have any document about it?
That's an ARM instruction that loads the 32-bit value at offset
#offGlue_methodClassDex from the address in register rGLUE (r8). In
C, this would be written like:
DvmDex* pDvmDex = glue->methodClassDex;
You can find various integer constants in mterp/common/asm-
constants.h, e.g.:
MTERP_OFFSET(offGlue_methodClassDex, MterpGlue, methodClassDex,
20)
This says that "offGlue_methodClassDex" has the value 20. When the VM
starts up, it compares that value to offsetof(MterpGlue,
methodClassDex); if the value isn't 20, the VM halts with an error.
Everything after the '@' is a comment. A philosophy I picked up many
years ago is that every line of assembly should have a comment; this
one is noting that r3 is now what in C would be pDvmDex. If you're
already familiar with the C version then the asm version makes a
little more sense.
The ARM instructions themselves are documented in various places.
The handler itself does very little; just resolves the method and then
branches to common method invocation code
(common_invokeMethodNoRange).
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
