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 <olo...@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 <olo...@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 <var...@gmail.com> wrote: >> >>> >>> On Mon, Feb 4, 2013 at 10:34 AM, Nikolay Igotti <olo...@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 <var...@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@lists.ximian.com >>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list