[Mono-dev] ARM/NativeClient port

[Zoltan Varga]

Hi,

 I added some comments using the github review system. The rest of the
stuff looks ok, All the #ifdefs make the code look a bit ugly, but I don't
know how else to do it. So its ok.

                   Zoltan

On Thu, Feb 21, 2013 at 6:04 PM, Nikolay Igotti <olonho at google.com> wrote:

>     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
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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/20130223/7a3e3cb0/attachment-0001.html>