[Mono-dev] ARM/NativeClient port

[Nikolay Igotti]

    Hi,

 This pull request https://github.com/mono/mono/pull/571 implements
approach suggested
(only jumptables are no longer bound to domain, as trampolines init happens
eariler than root domain init) and it would be great to have change
reviewed and integrated.

 It passes SciMark and few other tests. SciMark score with jumptables is
44.5MFlops, vs.  55.7MFlops without on Google Nexus 7, which is pretty
natural, considering nature of the change.
Performance likely could be improved, as in few places we could replace
always
indirect jumps with direct ones.

   Thanks,
     Nikolay

On Tue, Feb 5, 2013 at 4:14 PM, Nikolay Igotti <olonho at google.com> wrote:

>        Hi Zoltan,
>
>  Good idea, but unfortunately for [reg + reg] loads it's hard to easily
> verify
> that address does not escapes sandbox, so NaCL only allows [reg + imm]
> addressing mode.
>
>  So far, my approach is to augment MonoDomain with jumptable field, and
> replace inline jumptable with access to this domain-wide table.
>
>  Generated ASM for trampoline looks like:
>
>   movw rX, lo(jump_table_entry_addr)
>   movt rX, hi(jump_table_entry_addr)
>   ldr rX, [rX]
>   bic rX, rX, #MASK ; for NaCL only
>   bx rX
>
> and patching code decodes location to patch from movw/movt instruction
> (similar to what you suggested).
>
>  Nikolay.
>
>
> On Tue, Feb 5, 2013 at 10:35 AM, Zoltan Varga <vargaz at gmail.com> wrote:
>
>>
>> On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti <olonho at google.com>wrote:
>>
>>>    Hi Zoltan,
>>>
>>>  For PC-relative addressing at least 2 conditions has to be satisfied:
>>>  1. code must know which PC it runs at
>>>  2. offset to data must be smaller than 4K to fit into immediate encoding
>>>
>>> If we're not using inline constant pools, it would lead to rather tricky
>>> memory layout of code
>>> interleaved with data.
>>>
>>>   Nikolay
>>>
>>>
>> PC relative addressing is already used by the runtime in AOT mode, see
>> the implementation of the OP_AOTCONST opcode, you can generate:
>> movw <temp reg>, 0
>> movt <temp reg>, 0
>> mov <dreg>, [pc+temp reg]
>> and patch the movw/movt when the address of the code and the data is
>> known. I.e. for trampolines, this is already known, for methods, you can
>> patch the movw/movt
>> in mono_arch_patch_code ().
>>
>>                     Zoltan
>>
>>
>>>
>>> On Sun, Feb 3, 2013 at 10:09 PM, Zoltan Varga <vargaz at gmail.com> wrote:
>>>
>>>> >  Hi,
>>>> >
>>>> >  We're working on implementation of Mono JIT/ARM for Native Client,
>>>> and want to discuss certain details about design of our solution.
>>>> >  Native Client's sandboxing mechanism, being a SFI solution, has
>>>> rather strict  limitations on how verifiable machine code may look like. To
>>>> be precise:
>>>>
>>>> >  Our idea is to emit per-method (or per class?) "jump table"
>>>> somewhere in .data, which contains list of all relocations, and use some
>>>> register to point to this table.
>>>> > So for example, trampoline like this:
>>>> >        ldr ip, [pc, #0]
>>>> > b skip
>>>> >        .word target
>>>> >      skip:
>>>> > mov lr, pc
>>>> > mov pc, ip
>>>> > would become (if r10 is used as jump table base register):
>>>> >      .align 4 # for NaCl only
>>>> >         ldr ip, [r10, #32] # unique (per-method or class) index for
>>>> every callsite
>>>> >         nop  # for NaCl only, to have bl at bundle end
>>>> >         bic r10, r10, #0xc000000f # for NaCl only
>>>> >         bl ip # or blx
>>>> >  r10 could point somewhere in method metadata, where its relocation
>>>> table is stored.
>>>>
>>>> > So our question is if someone sees problem with such approach, or
>>>> could suggest better alternative. Also advises which register could be used
>>>> as the jump table base, and where > to store
>>>> > such a table (maybe patch info?) are very welcome.
>>>>
>>>> Hi,
>>>>
>>>> ARM has PC relative addressing, so it would be easier to use that
>>>> instead of reserving a register.
>>>>
>>>>                  Zoltan
>>>>
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130221/b1440ab6/attachment.html>