search for: r17

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

...mov r25=ar.unat /* M */ >+ mov r26=ar.pfs /* I */ >+ mov r28=cr.iip /* M */ >+ cover /* B (or nothing) */ >+ ;; >+ mov r1=sp >+ ;; >+ invala /* M */ >+ mov r30=cr.ifs >+ ;; >+ addl r1=-VMM_PT_REGS_SIZE,r1 >+ ;; >+ adds r17=2*L1_CACHE_BYTES,r1 /* really: biggest cache-line >size */ >+ adds r16=PT(CR_IPSR),r1 >+ ;; >+ lfetch.fault.excl.nt1 [r17],L1_CACHE_BYTES >+ st8 [r16]=r29 /* save cr.ipsr */ >+ ;; >+ lfetch.fault.excl.nt1 [r17] >+ mov r29=b0 >+ ;; >+ adds r...

...mov r25=ar.unat /* M */ >+ mov r26=ar.pfs /* I */ >+ mov r28=cr.iip /* M */ >+ cover /* B (or nothing) */ >+ ;; >+ mov r1=sp >+ ;; >+ invala /* M */ >+ mov r30=cr.ifs >+ ;; >+ addl r1=-VMM_PT_REGS_SIZE,r1 >+ ;; >+ adds r17=2*L1_CACHE_BYTES,r1 /* really: biggest cache-line >size */ >+ adds r16=PT(CR_IPSR),r1 >+ ;; >+ lfetch.fault.excl.nt1 [r17],L1_CACHE_BYTES >+ st8 [r16]=r29 /* save cr.ipsr */ >+ ;; >+ lfetch.fault.excl.nt1 [r17] >+ mov r29=b0 >+ ;; >+ adds r...

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

This code works: subset(NativeDominant.df,!ID=="37-R17") This code does not: Tree.df<-subset(NativeDominant.df,!ID==c("37-R17","37-R18","10-R1","37-R21","37-R24","R7A-R1","3-R1","37-R16")) how do i get subset() to work on a range of values? -- View this messa...

...eload support is pointer/data aware (Gordon?). The problem is callee-saved registers. The callee has no type information about the register's current value, and so cannot save it to an appropriately typed save slot in the callee stack frame. Consider: A() has pointer in callee-saved register R17 A() calls B() B() needs R17, so saves it to &R17. Does not know that R17 holds pointer. GC walks stack frame for B(), cannot determine whether the location at &R17 is pointer or data. Naive GC therefore cannot relocate R17. This induces the requirement for A() to reload R17 after...

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > > wrote: > > > >>> If so, then a Collector plugin would need to have info about every > >>> supported backend

...*Android ARM(32-bit) clang-kernel bring-up for Nexus 5(hammerhead)* *[Android Version Information] **&** [Battery Usage of a clang-built kernel ~ better than that of gcc-built kernel (shows one of the instances)]* *[1] Android NDK r13b [LLVM/clang + binutils(as, ld, etc)] [2] Android NDK r17 [LLVM/clang + binutils(as, ld, etc)]* *[3]** Main LLVM/clang + Android NDK r13b binutils(as, ld, etc) **[4]* * Main LLVM/clang + Android NDK r17 binutils(as, ld, etc)* *[5]** Snapdragon Qualcomm LLVM/clang + NDK r13b binutils(as, etc) **[6]* * Snapdragon Qualcomm LLVM/clang + NDK r13b binutils(a...

...his: is there any downside to not having any stack-based local variables at all- just put everything into registers and let the register allocation code decide what needs to get spilled onto the stack? In other words, is there any problem with generating the following IR for the above code: %r17 = call i64 @f(i64 0) %r18 = add i64 %r17 4 The upside of doing this is simpler code generation, and hopefully more efficient code, as I am explicitly telling the optimizer I don't care where this variable lives. But, I'm somewhat worried that by not having any local variables at all,...

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Now all the comments so far have been addressed, but only a few exceptions. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops.

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Please review and comments. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops strategy is appropriate too. Later I'll post the patchset which implements xen domU based on ia64/pv_ops. Currently only ia64/xen pv_ops implementation

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

Hi. This patchset implements ia64/pv_ops support which is the framework for virtualization support. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. On x86 various ways to support virtualization were proposed, and eventually pv_ops won. So on ia64 the pv_ops

...en printing the contents of the packet. Here are some examples: - Some insns contain a 3-bit new value, the new value bits, Nv[2:1] are set to 1, 2, or 3 if the producer is 1, 2, or 3 insns ahead of the consumer. Nv[0] is 1 if the producer is an odd register, 0 for even. { r17 = add(r2, r17) r23 = add(r23, #-1) if (!cmp.eq(r23.new, #0)) jump:t foobar } The above packet has 2 producers, r17 and r23. If the compare and jump is encoded as: 0x2443e000 where new value bits are stored in [18:16] and equal 0x3 then register 23 would be us...

.../ivt.S | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/ia64/kernel/ivt.S b/arch/ia64/kernel/ivt.S index 416a952..f675d8e 100644 --- a/arch/ia64/kernel/ivt.S +++ b/arch/ia64/kernel/ivt.S @@ -580,7 +580,7 @@ ENTRY(dirty_bit) mov b0=r29 // restore b0 ;; st8 [r17]=r18 // store back updated PTE - itc.d r18 // install updated PTE + ITC_D(p0, r18, r16) // install updated PTE #endif mov pr=r31,-1 // restore pr RFI @@ -646,7 +646,7 @@ ENTRY(iaccess_bit) mov b0=r29 // restore b0 ;; st8 [r17]=r18 // store back updated PTE - itc.i r18...

Hi. This patchset implements xen/ia64 domU support. Qing He and Eddie Dong also has been woring on pv_ops so that I want to discuss before going further and avoid duplicated work. I suppose that Eddie will also post his own patch. So reviewing both patches, we can reach to better pv_ops interface. - I didn't changed the ia64 intrinsic paravirtulization abi from the last post. Presumably it