search for: r9

Has anyone received this message while attempting to do a MAKE INSTALL on ZAPTEL depmod: *** Unresolved symbols in /lib/modules/2.4.26-gentoo-r9/misc/ztdummy.o I am not running DEVFS so that's not the issue. Zaptel drivers/modules all load, but ztdummy won't /lib/modules/2.4.26-gentoo-r9/misc/ztdummy.o: /lib/modules/2.4.26-gentoo-r9/misc/ztdummy.o: unresolved symbol unlink_td /lib/modules/2.4.26-gentoo-r9/misc/ztdum...

...mla r5, r4, r14,r6 @ mem[0] = mem[1] - den[0]*y[i] ldrsh r4, [r1, #4] mla r6, r0, r14,r7 @ mem[1] = mem[2] - den[1]*y[i] ldrsh r0, [r1, #6] mla r7, r4, r14,r8 @ mem[2] = mem[3] - den[2]*y[i] ldrsh r4, [r1, #8] mla r8, r0, r14,r9 @ mem[3] = mem[4] - den[3]*y[i] ldrsh r0, [r1, #10] mla r9, r4, r14,r10 @ mem[4] = mem[5] - den[4]*y[i] ldrsh r4, [r1, #12] mla r10, r0, r14,r11 @ mem[5] = mem[6] - den[5]*y[i] ldrsh r0, [r1, #14] mla r11, r4, r14,r12 @ mem[6]...

...t; { > 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z; > 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z; > 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z; > 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z; > } > P0 | P1 | P2 | P3 ; > lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ; > lwsync | lwsync | lwsync | sync ; > stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ; > lwsync | lwz r7,0(r2) | | ; > stw r1,0(r5) | lwsync |...

...t; { > 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z; > 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z; > 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z; > 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z; > } > P0 | P1 | P2 | P3 ; > lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ; > lwsync | lwsync | lwsync | sync ; > stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ; > lwsync | lwz r7,0(r2) | | ; > stw r1,0(r5) | lwsync |...

On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two

On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two

...-- PPC local-transitive "" { 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z; 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z; 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z; 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z; } P0 | P1 | P2 | P3 ; lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ; lwsync | lwsync | lwsync | sync ; stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ; lwsync | lwz r7,0(r2) | | ; stw r1,0(r5) | lwsync | | ;...

...les changed, 54 insertions(+), 53 deletions(-) diff --git a/nvkm/subdev/pwr/fuc/kernel.fuc b/nvkm/subdev/pwr/fuc/kernel.fuc index 54276c9..5cf5be6 100644 --- a/nvkm/subdev/pwr/fuc/kernel.fuc +++ b/nvkm/subdev/pwr/fuc/kernel.fuc @@ -98,12 +98,16 @@ wr32: // $r14 - ns // $r0 - zero nsec: + push $r9 + push $r8 nv_iord($r8, NV_PPWR_TIMER_LOW) nsec_loop: nv_iord($r9, NV_PPWR_TIMER_LOW) sub b32 $r9 $r8 cmp b32 $r9 $r14 bra l #nsec_loop + pop $r8 + pop $r9 ret // busy-wait for a period of time @@ -115,6 +119,8 @@ nsec: // $r11 - timeout (ns) // $r0 - zero wait: + push $r9...

Hi, Chris (cc) and I try to get the SGE master monitor work with Apple Leopard dtrace. Unfortunately we are stuck with the error msg below. Anyone having an idea what could be the cause? What I can rule out as cause is function inlining for the reasons explained below. Background information on SGE master monitor implementation is under http://wiki.gridengine.info/wiki/index.php/Dtrace

...=v; 0:r4=x; 0:r5=y; 0:r6=z; > > 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z; > > 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z; > > 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z; > > } > > P0 | P1 | P2 | P3 ; > > lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ; > > lwsync | lwsync | lwsync | sync ; > > stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ; > > lwsync | lwz r7,0(r2) | | ; > > stw r1,0(r5) | lwsync...

On Fri, 7 Feb 2014, Timothy B. Terriberry wrote: > Martin Storsjo wrote: >> This is required in order to build using the built-in assembler >> in clang. > > These patches break the gcc build (with "Error: bad instruction"). Ah, right, sorry about that. > Documentation I've seen is contradictory on which order ({cond}{size} or > {size}{cond}) is correct.

...); + DEFINE(OFFSET_VCPU_R5, offsetof(struct vcpu_guest_context, r5)); + DEFINE(OFFSET_VCPU_R6, offsetof(struct vcpu_guest_context, r6)); + DEFINE(OFFSET_VCPU_R7, offsetof(struct vcpu_guest_context, r7)); + DEFINE(OFFSET_VCPU_R8, offsetof(struct vcpu_guest_context, r8)); + DEFINE(OFFSET_VCPU_R9, offsetof(struct vcpu_guest_context, r9)); + DEFINE(OFFSET_VCPU_R10, offsetof(struct vcpu_guest_context, r10)); + DEFINE(OFFSET_VCPU_R11, offsetof(struct vcpu_guest_context, r11)); + DEFINE(OFFSET_VCPU_R12, offsetof(struct vcpu_guest_context, r12)); + DEFINE(OFFSET_VCPU_R13, offsetof(stru...

Hi Tim, thanks for the swift response! @debug is defined in the same module, which makes this all the more confusing. The target information from the working example are: target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64" target triple = "armv6kz--linux-gnueabihf" from the ghc produced module: target datalayout =

...acket length +// $r3 - opcode desciption +// $r0 - zero +memx_func_train: +#if NVKM_PPWR_CHIPSET == GT215 +// $r5 - outer loop counter +// $r6 - inner loop counter +// $r7 - entry counter (#memx_train_head + $r7) + movw $r5 0x3 + movw $r7 0x0 + +// Read random memory to wake up... things + imm32($r9, 0x700000) + nv_rd32($r8,$r9) + movw $r14 0x2710 + call(nsec) + + memx_func_train_loop_outer: + mulu $r8 $r5 0x101 + sethi $r8 0x02000000 + imm32($r9, 0x1111e0) + nv_wr32($r9, $r8) + push $r5 + + movw $r6 0x0 + memx_func_train_loop_inner: + movw $r8 0x1111 + mulu $r9 $r6 $r8 + shl b...

Sadly the latest optimization broke completely everything. The asm code isn't gas compliant. the libFLAC linker script has a typo, disabling the asm optimization and/or altivec won't let a correct build anyway. Instant fixes for the asm stuff: sed -i -e"s:;:\#:" on the lpc_asm.s to load address instead of addis+ori you could use lis and la and PLEASE use the @l(register)

...movl %esi, 36(%rsp) # 4-byte Spill movl %ecx, %esi movl %ecx, %edx movl %eax, 32(%rsp) # 4-byte Spill movl %ecx, 28(%rsp) # 4-byte Spill callq yfunc movslq %eax, %r8 movq 48(%rsp), %r9 # 8-byte Reload movl (%r9,%r8), %eax movl 32(%rsp), %edi # 4-byte Reload movl 36(%rsp), %esi # 4-byte Reload movl 28(%rsp), %edx # 4-byte Reload movl %eax, 24(%rsp) # 4-byte Spill call...

...r_ should be a _ldrne_ instruction or the _ldreq_ instruction should be removed. The error seems to come from the IfConvertion MachinePass. Here's is what it looks like before and after. > #BEFORE IfConversion MachinePass > > BB#7: > Live Ins: %LR %R0 %R1 %R2 %R4 %R5 %R6 %R7 %R8 %R9 %R10 %R12 > Predecessors according to CFG: BB#5 BB#6 > STRBi12 %R5, %R6<kill>, 0, pred:14, pred:%noreg; mem:ST1[%cond.i23.i.i.i] > %R6<def> = LDRBi12 %R7, 0, pred:14, pred:%noreg; mem:LD1[%15](align=4) > %R3<def> = EORri %R6, 254, pred:14, pred:%noreg, opt:%noreg &gt...

...involves adding them to the reserved register set and preventing them from being callee-saved. We have deliberately tried to avoid registers that have a distinct ABI/AAPCS use, such as call-clobbered registers, LR and PC etc. Naturally the current support for the stack-pointer remains. r7, r11 and r9 at least are special cases, and are mentioned in more detail below. Clang Changes ---------------------- The main proposed functional change to Clang is the tracking of global register variable declarations via module flags. Each declaration in a translation unit such as "register unsigned in...

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect

This patch set is intended for the next merge window. They are just enhancements of the already merged patches or ia64 porting from x86 paravirt techniques and that their quality is enough for merge. This patch set is for binary patch optimization for paravirt_ops. The binary patch optimization is important on native case because the paravirt_ops overhead can be reduced by converting indirect