[PATCH] ppc32 use simplified mmenonics

[PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

	Hi LKML and Benjamin,

This patch substitutes complex rlwinm instruction to the simplied
instruction clrrwi when possible.

This has the same meaning as the ppc knows only about rlwinm; clrrwi
is just a language simplification.

basicly it's a : s/rlwinm R1,R2,0,0,31-N/clrrwi R1,R2,N/

Please apply or comments,
Thanks

Signed-off-by: Vincent Hanquez <tab@snarc.org>

diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/entry.S linux-2.6.8.1/arch/ppc/kernel/entry.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/entry.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/entry.S	2004-08-21 21:57:47.000000000 +0200
@@ -198,7 +198,7 @@
 #ifdef SHOW_SYSCALLS
 	bl	do_show_syscall
 #endif /* SHOW_SYSCALLS */
-	rlwinm	r10,r1,0,0,18	/* current_thread_info() */
+	clrrwi	r10,r1,13	/* current_thread_info() */
 	lwz	r11,TI_LOCAL_FLAGS(r10)
 	rlwinm	r11,r11,0,~_TIFL_FORCE_NOERROR
 	stw	r11,TI_LOCAL_FLAGS(r10)
@@ -223,7 +223,7 @@
 	mr	r6,r3
 	li	r11,-_LAST_ERRNO
 	cmpl	0,r3,r11
-	rlwinm	r12,r1,0,0,18	/* current_thread_info() */
+	clrrwi	r12,r1,13	/* current_thread_info() */
 	blt+	30f
 	lwz	r11,TI_LOCAL_FLAGS(r12)
 	andi.	r11,r11,_TIFL_FORCE_NOERROR
@@ -310,7 +310,7 @@
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)	/* doesn't include MSR_EE */
 	SYNC
 	MTMSRD(r10)		/* disable interrupts again */
-	rlwinm	r12,r1,0,0,18	/* current_thread_info() */
+	clrrwi	r12,r1,13	/* current_thread_info() */
 	lwz	r9,TI_FLAGS(r12)
 5:
 	andi.	r0,r9,_TIF_NEED_RESCHED
@@ -407,7 +407,7 @@
 ppc_sigsuspend:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30		/* clear LSB to indicate full */
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
 	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_sigsuspend
 
@@ -415,15 +415,15 @@
 ppc_rt_sigsuspend:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30
-	stw	r0,TRAP(r1)
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
+	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_rt_sigsuspend
 
 	.globl	ppc_fork
 ppc_fork:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30		/* clear LSB to indicate full */
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
 	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_fork
 
@@ -431,7 +431,7 @@
 ppc_vfork:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30		/* clear LSB to indicate full */
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
 	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_vfork
 
@@ -439,7 +439,7 @@
 ppc_clone:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30		/* clear LSB to indicate full */
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
 	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_clone
 
@@ -447,7 +447,7 @@
 ppc_swapcontext:
 	SAVE_NVGPRS(r1)
 	lwz	r0,TRAP(r1)
-	rlwinm	r0,r0,0,0,30		/* clear LSB to indicate full */
+	clrrwi	r0,r0,1			/* clear LSB to indicate full */
 	stw	r0,TRAP(r1)		/* register set saved */
 	b	sys_swapcontext
 
@@ -566,7 +566,7 @@
 	.globl	sigreturn_exit
 sigreturn_exit:
 	subi	r1,r3,STACK_FRAME_OVERHEAD
-	rlwinm	r12,r1,0,0,18	/* current_thread_info() */
+	clrrwi	r12,r1,13	/* current_thread_info() */
 	lwz	r9,TI_FLAGS(r12)
 	andi.	r0,r9,_TIF_SYSCALL_TRACE
 	bnel-	do_syscall_trace
@@ -592,7 +592,7 @@
 
 user_exc_return:		/* r10 contains MSR_KERNEL here */
 	/* Check current_thread_info()->flags */
-	rlwinm	r9,r1,0,0,18
+	clrrwi	r9,r1,13
 	lwz	r9,TI_FLAGS(r9)
 	andi.	r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED)
 	bne	do_work
@@ -611,7 +611,7 @@
 /* N.B. the only way to get here is from the beq following ret_from_except. */
 resume_kernel:
 	/* check current_thread_info->preempt_count */
-	rlwinm	r9,r1,0,0,18
+	clrrwi	r9,r1,13
 	lwz	r0,TI_PREEMPT(r9)
 	cmpwi	0,r0,0		/* if non-zero, just restore regs and return */
 	bne	restore
@@ -629,7 +629,7 @@
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)
 	SYNC
 	MTMSRD(r10)		/* disable interrupts */
-	rlwinm	r9,r1,0,0,18
+	clrrwi	r9,r1,13
 	li	r0,0
 	stw	r0,TI_PREEMPT(r9)
 	lwz	r3,TI_FLAGS(r9)
@@ -912,7 +912,7 @@
 	LOAD_MSR_KERNEL(r10,MSR_KERNEL)
 	SYNC
 	MTMSRD(r10)		/* disable interrupts */
-	rlwinm	r9,r1,0,0,18
+	clrrwi	r9,r1,13
 	lwz	r9,TI_FLAGS(r9)
 	andi.	r0,r9,_TIF_NEED_RESCHED
 	bne-	do_resched
@@ -927,7 +927,7 @@
 	andi.	r0,r3,1
 	beq	2f
 	SAVE_NVGPRS(r1)
-	rlwinm	r3,r3,0,0,30
+	clrrwi	r3,r3,1
 	stw	r3,TRAP(r1)
 2:	li	r3,0
 	addi	r4,r1,STACK_FRAME_OVERHEAD
@@ -964,7 +964,7 @@
 	andi.	r0,r3,1
 	beq	4f
 	SAVE_NVGPRS(r1)
-	rlwinm	r3,r3,0,0,30
+	clrrwi	r3,r3,1
 	stw	r3,TRAP(r1)
 4:	addi	r3,r1,STACK_FRAME_OVERHEAD
 	bl	nonrecoverable_exception
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/head_44x.S linux-2.6.8.1/arch/ppc/kernel/head_44x.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/head_44x.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/head_44x.S	2004-08-21 21:57:47.000000000 +0200
@@ -571,7 +571,7 @@
 	ori	r11, r11, swapper_pg_dir@l
 
 	mfspr   r12,SPRN_MMUCR
-	rlwinm	r12,r12,0,0,23		/* Clear TID */
+	clrrwi	r12,r12,8		/* Clear TID */
 
 	b	4f
 
@@ -590,7 +590,7 @@
 
 	rlwinm  r12, r10, 13, 19, 29    /* Compute pgdir/pmd offset */
 	lwzx    r11, r12, r11           /* Get pgd/pmd entry */
-	rlwinm. r12, r11, 0, 0, 20      /* Extract pt base address */
+	clrrwi. r12, r11, 11		/* Extract pt base address */
 	beq     2f                      /* Bail if no table */
 
 	rlwimi  r12, r10, 23, 20, 28    /* Compute pte address */
@@ -720,7 +720,7 @@
 	ori	r11, r11, swapper_pg_dir@l
 
 	mfspr	r12,SPRN_MMUCR
-	rlwinm	r12,r12,0,0,23		/* Clear TID */
+	clrrwi	r12,r12,8		/* Clear TID */
 
 	b	4f
 
@@ -739,7 +739,7 @@
 
 	rlwinm 	r12, r10, 13, 19, 29	/* Compute pgdir/pmd offset */
 	lwzx	r11, r12, r11		/* Get pgd/pmd entry */
-	rlwinm.	r12, r11, 0, 0, 20	/* Extract pt base address */
+	clrrwi. r12, r11, 11		/* Extract pt base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 23, 20, 28	/* Compute pte address */
@@ -789,7 +789,7 @@
 	ori	r11, r11, swapper_pg_dir@l
 
 	mfspr	r12,SPRN_MMUCR
-	rlwinm	r12,r12,0,0,23		/* Clear TID */
+	clrrwi	r12,r12,8		/* Clear TID */
 
 	b	4f
 
@@ -808,7 +808,7 @@
 
 	rlwinm	r12, r10, 13, 19, 29	/* Compute pgdir/pmd offset */
 	lwzx	r11, r12, r11		/* Get pgd/pmd entry */
-	rlwinm.	r12, r11, 0, 0, 20	/* Extract pt base address */
+	clrrwi. r12, r11, 11		/* Extract pt base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 23, 20, 28	/* Compute pte address */
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/head_4xx.S linux-2.6.8.1/arch/ppc/kernel/head_4xx.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/head_4xx.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/head_4xx.S	2004-08-21 21:57:47.000000000 +0200
@@ -347,7 +347,7 @@
 	tophys(r11, r11)
 	rlwimi	r11, r10, 12, 20, 29	/* Create L1 (pgdir/pmd) address */
 	lwz	r11, 0(r11)		/* Get L1 entry */
-	rlwinm.	r12, r11, 0, 0, 19	/* Extract L2 (pte) base address */
+	clrrwi.	r12, r11, 12		/* Extract L2 (pte) base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 22, 20, 29	/* Compute PTE address */
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/head_8xx.S linux-2.6.8.1/arch/ppc/kernel/head_8xx.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/head_8xx.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/head_8xx.S	2004-08-21 22:36:37.000000000 +0200
@@ -329,7 +329,7 @@
 	rlwimi	r20, r21, 0, 2, 19
 3:
 	lwz	r21, 0(r20)	/* Get the level 1 entry */
-	rlwinm.	r20, r21,0,0,19	/* Extract page descriptor page address */
+	clrrwi.	r20, r21,12	/* Extract page descriptor page address */
 	beq	2f		/* If zero, don't try to find a pte */
 
 	/* We have a pte table, so load the MI_TWC with the attributes
@@ -413,7 +413,7 @@
 	rlwimi r20, r21, 0, 2, 19
 3:
 	lwz	r21, 0(r20)	/* Get the level 1 entry */
-	rlwinm.	r20, r21,0,0,19	/* Extract page descriptor page address */
+	clrrwi.	r20, r21,12	/* Extract page descriptor page address */
 	beq	2f		/* If zero, don't try to find a pte */
 
 	/* We have a pte table, so load fetch the pte from the table.
@@ -533,7 +533,7 @@
 	 * assuming we only use the dcbi instruction on kernel addresses.
 	 */
 	mfspr	r20, DAR
-	rlwinm	r21, r20, 0, 0, 19
+	clrrwi	r21, r20, 12
 	ori	r21, r21, MD_EVALID
 	mfspr	r20, M_CASID
 	rlwimi	r21, r20, 0, 28, 31
@@ -556,7 +556,7 @@
 	rlwimi	r20, r21, 0, 2, 19
 3:
 	lwz	r21, 0(r20)	/* Get the level 1 entry */
-	rlwinm.	r20, r21,0,0,19	/* Extract page descriptor page address */
+	clrrwi.	r20, r21,12	/* Extract page descriptor page address */
 	beq	2f		/* If zero, bail */
 
 	/* We have a pte table, so fetch the pte from the table.
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/head_e500.S linux-2.6.8.1/arch/ppc/kernel/head_e500.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/head_e500.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/head_e500.S	2004-08-21 22:37:50.000000000 +0200
@@ -640,7 +640,7 @@
 4:
 	rlwimi	r11, r10, 12, 20, 29	/* Create L1 (pgdir/pmd) address */
 	lwz	r11, 0(r11)		/* Get L1 entry */
-	rlwinm.	r12, r11, 0, 0, 19	/* Extract L2 (pte) base address */
+	clrrwi.	r12, r11, 12		/* Extract L2 (pte) base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 22, 20, 29	/* Compute PTE address */
@@ -787,7 +787,7 @@
 4:
 	rlwimi	r11, r10, 12, 20, 29	/* Create L1 (pgdir/pmd) address */
 	lwz	r11, 0(r11)		/* Get L1 entry */
-	rlwinm.	r12, r11, 0, 0, 19	/* Extract L2 (pte) base address */
+	clrrwi.	r12, r11, 12		/* Extract L2 (pte) base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 22, 20, 29	/* Compute PTE address */
@@ -852,7 +852,7 @@
 4:
 	rlwimi	r11, r10, 12, 20, 29	/* Create L1 (pgdir/pmd) address */
 	lwz	r11, 0(r11)		/* Get L1 entry */
-	rlwinm.	r12, r11, 0, 0, 19	/* Extract L2 (pte) base address */
+	clrrwi.	r12, r11, 12		/* Extract L2 (pte) base address */
 	beq	2f			/* Bail if no table */
 
 	rlwimi	r12, r10, 22, 20, 29	/* Compute PTE address */
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/head.S linux-2.6.8.1/arch/ppc/kernel/head.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/head.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/head.S	2004-08-21 22:38:56.000000000 +0200
@@ -532,7 +532,7 @@
 112:	tophys(r2,r2)
 	rlwimi	r2,r3,12,20,29		/* insert top 10 bits of address */
 	lwz	r2,0(r2)		/* get pmd entry */
-	rlwinm.	r2,r2,0,0,19		/* extract address of pte page */
+	clrrwi.	r2,r2,12		/* extract address of pte page */
 	beq-	InstructionAddressInvalid	/* return if no mapping */
 	rlwimi	r2,r3,22,20,29		/* insert next 10 bits of address */
 	lwz	r3,0(r2)		/* get linux-style pte */
@@ -606,7 +606,7 @@
 112:	tophys(r2,r2)
 	rlwimi	r2,r3,12,20,29		/* insert top 10 bits of address */
 	lwz	r2,0(r2)		/* get pmd entry */
-	rlwinm.	r2,r2,0,0,19		/* extract address of pte page */
+	clrrwi.	r2,r2,12		/* extract address of pte page */
 	beq-	DataAddressInvalid	/* return if no mapping */
 	rlwimi	r2,r3,22,20,29		/* insert next 10 bits of address */
 	lwz	r3,0(r2)		/* get linux-style pte */
@@ -678,7 +678,7 @@
 112:	tophys(r2,r2)
 	rlwimi	r2,r3,12,20,29		/* insert top 10 bits of address */
 	lwz	r2,0(r2)		/* get pmd entry */
-	rlwinm.	r2,r2,0,0,19		/* extract address of pte page */
+	clrrwi.	r2,r2,12		/* extract address of pte page */
 	beq-	DataAddressInvalid	/* return if no mapping */
 	rlwimi	r2,r3,22,20,29		/* insert next 10 bits of address */
 	lwz	r3,0(r2)		/* get linux-style pte */
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/idle_6xx.S linux-2.6.8.1/arch/ppc/kernel/idle_6xx.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/idle_6xx.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/idle_6xx.S	2004-08-21 22:39:45.000000000 +0200
@@ -93,7 +93,7 @@
 	mtmsr	r0
 
 	/* Check current_thread_info()->flags */
-	rlwinm	r4,r1,0,0,18
+	clrrwi	r4,r1,13
 	lwz	r4,TI_FLAGS(r4)
 	andi.	r0,r4,_TIF_NEED_RESCHED
 	beq	1f
@@ -111,7 +111,7 @@
 	 * doesn't even bother doing the dcbf's here...
 	 */
 	mfspr	r4,SPRN_MSSCR0
-	rlwinm	r4,r4,0,0,29
+	clrrwi	r4,r4,2
 	sync
 	mtspr	SPRN_MSSCR0,r4
 	sync
@@ -189,7 +189,7 @@
 1:
 #endif
 	
-	rlwinm	r9,r1,0,0,18
+	clrrwi	r9,r1,13
 	tophys(r9,r9)
 	lwz	r11,TI_CPU(r9)
 	slwi	r11,r11,2
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/idle_power4.S linux-2.6.8.1/arch/ppc/kernel/idle_power4.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/idle_power4.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/idle_power4.S	2004-08-21 22:40:06.000000000 +0200
@@ -65,7 +65,7 @@
 	mtmsr	r0
 
 	/* Check current_thread_info()->flags */
-	rlwinm	r4,r1,0,0,18
+	clrrwi	r4,r1,13
 	lwz	r4,TI_FLAGS(r4)
 	andi.	r0,r4,_TIF_NEED_RESCHED
 	beq	1f
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/misc.S linux-2.6.8.1/arch/ppc/kernel/misc.S
--- linux-2.6.8.1.orig/arch/ppc/kernel/misc.S	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/misc.S	2004-08-21 22:33:33.000000000 +0200
@@ -232,7 +232,7 @@
 	mtspr	SPRN_HID1,r4
 
 	/* Store new HID1 image */
-	rlwinm	r6,r1,0,0,18
+	clrrwi	r6,r1,13
 	lwz	r6,TI_CPU(r6)
 	slwi	r6,r6,2
 	addis	r6,r6,nap_save_hid1@ha
@@ -456,7 +456,7 @@
 #endif /* CONFIG_SMP */
 #else /* !(CONFIG_40x || CONFIG_44x || CONFIG_FSL_BOOKE) */
 #if defined(CONFIG_SMP)
-	rlwinm	r8,r1,0,0,18
+	clrrwi	r8,r1,13
 	lwz	r8,TI_CPU(r8)
 	oris	r8,r8,10
 	mfmsr	r10
@@ -523,7 +523,7 @@
 	isync
 10:
 #elif defined(CONFIG_FSL_BOOKE)
-	rlwinm	r4, r3, 0, 0, 19
+	clrrwi	r4, r3, 12
 	ori	r5, r4, 0x08	/* TLBSEL = 1 */
 	ori	r6, r4, 0x10	/* TLBSEL = 2 */
 	ori	r7, r4, 0x18	/* TLBSEL = 3 */
@@ -537,7 +537,7 @@
 #endif /* CONFIG_SMP */
 #else /* !(CONFIG_40x || CONFIG_44x || CONFIG_FSL_BOOKE) */
 #if defined(CONFIG_SMP)
-	rlwinm	r8,r1,0,0,18
+	clrrwi	r8,r1,13
 	lwz	r8,TI_CPU(r8)
 	oris	r8,r8,11
 	mfmsr	r10
@@ -739,7 +739,7 @@
 	rlwinm	r5,r5,16,16,31
 	cmpi	0,r5,1
 	beqlr					/* for 601, do nothing */
-	rlwinm	r3,r3,0,0,19			/* Get page base address */
+	clrrwi	r3,r3,12			/* Get page base address */
 	li	r4,4096/L1_CACHE_LINE_SIZE	/* Number of lines in a page */
 	mtctr	r4
 	mr	r6,r3
@@ -772,7 +772,7 @@
 	rlwinm	r0,r10,0,28,26			/* clear DR */
 	mtmsr	r0
 	isync
-	rlwinm	r3,r3,0,0,19			/* Get page base address */
+	clrrwi	r3,r3,12			/* Get page base address */
 	li	r4,4096/L1_CACHE_LINE_SIZE	/* Number of lines in a page */
 	mtctr	r4
 	mr	r6,r3
diff -u -Naur linux-2.6.8.1.orig/arch/ppc/kernel/ppc_htab.c linux-2.6.8.1/arch/ppc/kernel/ppc_htab.c
--- linux-2.6.8.1.orig/arch/ppc/kernel/ppc_htab.c	2004-08-21 21:56:22.000000000 +0200
+++ linux-2.6.8.1/arch/ppc/kernel/ppc_htab.c	2004-08-21 21:59:05.000000000 +0200
@@ -275,7 +275,7 @@
 		/* setup mmcr0 and clear the correct pmc */
 	       asm volatile(
 		       "mfspr %0,%1\n\t"     /* get current mccr0 */
-		       "rlwinm %0,%0,0,0,31-6\n\t"  /* clear bits [26-31] */
+		       "clrrwi %0,%0,6\n\t"  /* clear bits [26-31] */
 		       "ori   %0,%0,%2 \n\t" /* or in mmcr0 settings */
 		       "mtspr %1,%0 \n\t"    /* set new mccr0 */
 		       "mtspr %3,%4 \n\t"    /* reset the pmc */
@@ -290,7 +290,7 @@
 		/* setup mmcr0 and clear the correct pmc */
 	       asm volatile(
 		       "mfspr %0,%1\n\t"     /* get current mccr0 */
-		       "rlwinm %0,%0,0,0,31-6\n\t"  /* clear bits [26-31] */
+		       "clrrwi %0,%0,6\n\t"  /* clear bits [26-31] */
 		       "ori   %0,%0,%2 \n\t" /* or in mmcr0 settings */
 		       "mtspr %1,%0 \n\t"    /* set new mccr0 */
 		       "mtspr %3,%4 \n\t"    /* reset the pmc */
@@ -304,7 +304,7 @@
 		/* setup mmcr0 and clear the correct pmc */
 	       asm volatile(
 		       "mfspr %0,%1\n\t"     /* get current mccr0 */
-		       "rlwinm %0,%0,0,0,31-6\n\t"  /* clear bits [26-31] */
+		       "clrrwi %0,%0,6\n\t"  /* clear bits [26-31] */
 		       "ori   %0,%0,%2 \n\t" /* or in mmcr0 settings */
 		       "mtspr %1,%0 \n\t"    /* set new mccr0 */
 		       "mtspr %3,%4 \n\t"    /* reset the pmc */

Re: [PATCH] ppc32 use simplified mmenonics

[Benjamin Herrenschmidt]

On Sun, 2004-08-22 at 08:23, Vincent Hanquez wrote:
> 	Hi LKML and Benjamin,
> 
> This patch substitutes complex rlwinm instruction to the simplied
> instruction clrrwi when possible.
> 
> This has the same meaning as the ppc knows only about rlwinm; clrrwi
> is just a language simplification.
> 
> basicly it's a : s/rlwinm R1,R2,0,0,31-N/clrrwi R1,R2,N/

Oh well.. I've got quite used to tweaking rlwinm directly but I suppose
it's more clear for others to go to clrrwi. I see no obvious problem
though I haven't double checked the bit counts, I suppose you got the
substraction right everywhere but you know... it's always on the trivial
things that we make the nasty mistakes ;)

I'll look again when I'm back (I'm away for the week-end)

Ben.

Re: [PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

On Sun, Aug 22, 2004 at 12:00:49PM +1000, Benjamin Herrenschmidt wrote:
> Oh well.. I've got quite used to tweaking rlwinm directly but I suppose
> it's more clear for others to go to clrrwi. I see no obvious problem
> though I haven't double checked the bit counts, I suppose you got the
> substraction right everywhere but you know... it's always on the trivial
> things that we make the nasty mistakes ;)

Sure, trivial mistakes are the worst !
I have verified already 2 times, but that would not hurt a 3 times with
a different look :)

> I'll look again when I'm back (I'm away for the week-end)

Thanks,

-- 
Tab

Re: [PATCH] ppc32 use simplified mmenonics

[Albert Cahalan]

> This patch substitutes complex rlwinm instruction
> to the simplied instruction clrrwi when possible.
>
> This has the same meaning as the ppc knows only about
> rlwinm; clrrwi is just a language simplification.
>
> basicly it's a : s/rlwinm R1,R2,0,0,31-N/clrrwi R1,R2,N/
>
> Please apply or comments,

I'd rather you went the other way, replacing these
barely-documented instructions with ones that are
easy to look up. Motorola has about a zillion of
these "simplified" instructions. I guess Motorola
and IBM were jealous of Intel's CISC instructions.

The big problem is this:
        THESE ARE NOT IN THE INDEX!!!!!!

So, if I forget what one of these many instructions
does, I'll have quite the time paging through the
manual trying to find it.

If it's not in the index, please avoid it.

Re: [PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

On Sat, Aug 21, 2004 at 08:45:26PM -0400, Albert Cahalan wrote:
> I'd rather you went the other way, replacing these
> barely-documented instructions with ones that are
> easy to look up. Motorola has about a zillion of
> these "simplified" instructions. I guess Motorola
> and IBM were jealous of Intel's CISC instructions.
> 
> The big problem is this:
>         THESE ARE NOT IN THE INDEX!!!!!!
> 
> So, if I forget what one of these many instructions
> does, I'll have quite the time paging through the
> manual trying to find it.
> 
> If it's not in the index, please avoid it.

Well,

let's analyse 'mr R1,R2'. Which is simplified instruction for moving register,
which represent the following instruction 'or R2,0,R1'

when you read 'mr' you obviously know what the source want to do.
However seeing 'or', for my part, I see logicial or operation.
In spite of the fact, there's some case when 'or' could simply move a
register, I guess that's not as obvious as 'mr' instruction.

I guess that's the same for multiple other simplified instruction

bne target = bc 4,2,target

When I see first form, I know exactly what the program do, whereas on
the second form : What the hell is 4,2 ?

So I'ld rather go with simplified instruction, even if that index
doesn't contain them (which I agree with you, is very bad).
There are still in Appendix F of my pdf and you can search with the find
utility include in your reader (xpdf does)

-- 
Tab

Re: [PATCH] ppc32 use simplified mmenonics

[Albert Cahalan]

On Sun, 2004-08-22 at 05:43, Vincent Hanquez wrote:
> On Sat, Aug 21, 2004 at 08:45:26PM -0400, Albert Cahalan wrote:
> > I'd rather you went the other way, replacing these
> > barely-documented instructions with ones that are
> > easy to look up. Motorola has about a zillion of
> > these "simplified" instructions. I guess Motorola
> > and IBM were jealous of Intel's CISC instructions.
> > 
> > The big problem is this:
> >         THESE ARE NOT IN THE INDEX!!!!!!
> > 
> > So, if I forget what one of these many instructions
> > does, I'll have quite the time paging through the
> > manual trying to find it.
> > 
> > If it's not in the index, please avoid it.
> 
> Well,
> 
> let's analyse 'mr R1,R2'. Which is simplified instruction for moving register,
> which represent the following instruction 'or R2,0,R1'

The "or" is much easier, because it follows the
standard 3-register pattern. With "mr", which way
does it go? That's one more thing to remember.
In fact I don't know, but the "or" is obvious.

The 0 is your hint that the "or" isn't a plain "or".

> bne target = bc 4,2,target
> 
> When I see first form, I know exactly what the program do, whereas on
> the second form : What the hell is 4,2 ?

This is a slightly better example, but still, it's
lots easier to look up "bc" to see the selection of
options that are available.

Plus, yeah, "what the hell is 4,2", but those numbers
replace a _lot_ of other things you'd need to remember.
There are 456 of these "simplified" branch instructions.
If you use those, you'll tend to restrict your code to
those few common ones you remember. There's bdnzltrl,
bdnzfla, bunla...  That's madness.

That's 114 opcodes to 1.

> So I'ld rather go with simplified instruction, even if that index
> doesn't contain them (which I agree with you, is very bad).
> There are still in Appendix F of my pdf and you can search with the find
> utility include in your reader (xpdf does)

I have the physical book. Other than being unsearchable,
it's much nicer than the pdf. It's easy on the eyes,
doesn't occupy screen space, and I can read it on the can.

Re: [PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

On Sun, Aug 22, 2004 at 06:41:32AM -0400, Albert Cahalan wrote:
> The "or" is much easier, because it follows the
> standard 3-register pattern. With "mr", which way
> does it go? That's one more thing to remember.
> In fact I don't know, but the "or" is obvious.
> 
> The 0 is your hint that the "or" isn't a plain "or".

Sure, but this is about mmenonic. When I see 'or', my mind doesn't make
any link with 'move register' but only with 'or'. I have to process
another term of the line (the 0) to see that the program want to move a
register.

> > bne target = bc 4,2,target
> > 
> > When I see first form, I know exactly what the program do, whereas on
> > the second form : What the hell is 4,2 ?
> 
> This is a slightly better example, but still, it's
> lots easier to look up "bc" to see the selection of
> options that are available.
> 
> Plus, yeah, "what the hell is 4,2", but those numbers
> replace a _lot_ of other things you'd need to remember.
> There are 456 of these "simplified" branch instructions.
> If you use those, you'll tend to restrict your code to
> those few common ones you remember. There's bdnzltrl,
> bdnzfla, bunla...  That's madness.

So you writing assembly ppc code with your book on your side ?
because I don't see any reason to associate easily '4,2' with 'not equal'

mmenonics is about associating instruction with what they do.
'bc 4,2' doesn't make me associate that with 'branch not equal' but with
'branch conditional something'. Without knowing the something, that won't
help me figure what the program want to do.

if you're able to decode '4,2' in real time you're very strong, but
you're probably a computer ;)

bdnzltrl kinds of mmenonics are actually not fair, they are not really used :).
But even that I would prefer bdnztlrl which I would have to lookup,
than bclr with cryptics numbers which I would had to lookup too.

> That's 114 opcodes to 1.

There's not 1 opcode for conditional branching. There are more on ppc basis:
	
	bc, bca, bclr, bcctr, bcl, bcla, bclrl, bcctrl

Thus if you count bnea, bnelr, bnectl, bnel, as new different instructions
compared to bne, then maybe you need to understand why thoses are called
mmenomics.

So as soon as you know those 8 basis opcodes, thoses are actually very easy to
understand. You just need to append the following (which all bourne
script peoples use)

	ne = not equal
	eq = equal
	lt = less than
	le = less equal
	ge = greater equal
	gt = greater than
	....

ex :
bc = Branch Conditional
bca = Branch Conditional Absolute
bne = Branch Not Equal
bnea = Branch Not Equal Absolute

thus from (8 basis mmenonics) + (12 kind of modifiers) I'm able to decode
in real time those 8 * 12 = 96 simplified instructions.

> > So I'ld rather go with simplified instruction, even if that index
> > doesn't contain them (which I agree with you, is very bad).
> > There are still in Appendix F of my pdf and you can search with the find
> > utility include in your reader (xpdf does)
> 
> I have the physical book. Other than being unsearchable,
> it's much nicer than the pdf. It's easy on the eyes,
> doesn't occupy screen space, and I can read it on the can.

You would better learn few of them and decode them the way it meant to
be, than lookup them all in your book.

That would save your time, your eyes and your desk space ;)

-- 
Tab

Re: [PATCH] ppc32 use simplified mmenonics

[Albert Cahalan]

On Sun, 2004-08-22 at 10:45, Vincent Hanquez wrote:
> On Sun, Aug 22, 2004 at 06:41:32AM -0400, Albert Cahalan wrote:

> > This is a slightly better example, but still, it's
> > lots easier to look up "bc" to see the selection of
> > options that are available.
> > 
> > Plus, yeah, "what the hell is 4,2", but those numbers
> > replace a _lot_ of other things you'd need to remember.
> > There are 456 of these "simplified" branch instructions.
> > If you use those, you'll tend to restrict your code to
> > those few common ones you remember. There's bdnzltrl,
> > bdnzfla, bunla...  That's madness.
> 
> So you writing assembly ppc code with your book on your side ?
> because I don't see any reason to associate easily '4,2' with 'not equal'

As I said, it's a slightly better example.
(it's also NOT what the patch was changing)

> bdnzltrl kinds of mmenonics are actually not fair, they are not really used :).
> But even that I would prefer bdnztlrl which I would have to lookup,
> than bclr with cryptics numbers which I would had to lookup too.

See, that's a problem. You're limiting yourself to
just 96 of the 456 listed operations, which are only
1/5 of the 2304 available operations.

I do admit to using bne at times. The bit manipulation
stuff is different though. It's not so cryptic in the
raw form. The same goes for using "or" to copy a register.

If you don't use the full bit manipulation notation
all the time, you might forget what it can do. Then
you'll end up using 2 instructions where one would do.

> > That's 114 opcodes to 1.
> 
> There's not 1 opcode for conditional branching. There are more on ppc basis:
> 	
> 	bc, bca, bclr, bcctr, bcl, bcla, bclrl, bcctrl

OK, that's 8. Dividing 456 by that, I still see a 57:1 ratio.

There's also that matter of the 1848 operations you can't
access via the "simplified" instruction names.

Re: [PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

On Sun, Aug 22, 2004 at 08:40:22AM -0400, Albert Cahalan wrote:
> As I said, it's a slightly better example.
> (it's also NOT what the patch was changing)

I was just commenting of the fact you prefer using bc than simplified
instructions.

> See, that's a problem. You're limiting yourself to
> just 96 of the 456 listed operations, which are only
> 1/5 of the 2304 available operations.

That was an example to show that your figures were totally silly.
I'm not limiting myself in anyway, and I could do the same stuff for
(most of) all others simplified instructions, but I think that's not the
goal of this list, neither of this thread.

> I do admit to using bne at times. The bit manipulation
> stuff is different though. It's not so cryptic in the
> raw form. The same goes for using "or" to copy a register.

> If you don't use the full bit manipulation notation
> all the time, you might forget what it can do. Then
> you'll end up using 2 instructions where one would do.

Mis-using theses instructions is not actually the point here. I agree
that a person which do that is not right.

However each person that has read some documentations about ppc assembly know
that a 'clrrwi' is a macro to a more complex instruction 'rlwinm'.

Any documentation that wouldn't mention that is just plain wrong.

> OK, that's 8. Dividing 456 by that, I still see a 57:1 ratio.
> 
> There's also that matter of the 1848 operations you can't
> access via the "simplified" instruction names.

Are you counting one operations for 'rlwinm' and one for 'rlwinm.' to have
so much (1848) operations ? or is your figures totally random ?

But anyway it seems, we could discuss the benefit or not, of using simplified
instructions the whole night. I think this is a good idea (obviously) and it
seems Benjamin thinks it too. Thoses simplified instructions are mentioned in
all officials ppc assembly documentation because they are simple and help.

But if kernel people do not want to apply this patch for the reasons you said
that's ok, but I'm not gonna discuss that for 10 hours :p

-- 
Tab

Re: [PATCH] ppc32 use simplified mmenonics

[Albert Cahalan]

On Sun, 2004-08-22 at 12:28, Vincent Hanquez wrote:

> However each person that has read some documentations about ppc assembly know
> that a 'clrrwi' is a macro to a more complex instruction 'rlwinm'.
> 
> Any documentation that wouldn't mention that is just plain wrong.

It's buried in Appendix F.

> > OK, that's 8. Dividing 456 by that, I still see a 57:1 ratio.
> > 
> > There's also that matter of the 1848 operations you can't
> > access via the "simplified" instruction names.
> 
> Are you counting one operations for 'rlwinm' and one for 'rlwinm.' to have
> so much (1848) operations ? or is your figures totally random ?

That's just for branches.

There are 32 condition register bits.
There are 9 values for the BO field. (so far)
There are 8 of these: bc,bca,bcl,bcla,bcctr,bcctrl,bclr,bclrl

That comes to 2304. Subtract the 456 "simplified"
instruction names you have. That leaves 1848 that
you are unable to access.

Take a look at the crand instruction. It uses numbers.
Now, just imagine mixing that with branch instructions
that hide the numbers. I hope you see the problem.

> But anyway it seems, we could discuss the benefit or not, of using simplified
> instructions the whole night. I think this is a good idea (obviously) and it
> seems Benjamin thinks it too. Thoses simplified instructions are mentioned in
> all officials ppc assembly documentation because they are simple and help.

It doesn't appear to be so. He wrote:

: Oh well.. I've got quite used to tweaking rlwinm directly
: but I suppose it's more clear for others to go to clrrwi.

So I'd like him to know that others like rlwinm directly too.
Using instructions that are in the index makes sense.
Using a zillion poorly documented alternatives is madness.

Re: [PATCH] ppc32 use simplified mmenonics

[Vincent Hanquez]

On Sun, Aug 22, 2004 at 10:29:00AM -0400, Albert Cahalan wrote:
> That comes to 2304. Subtract the 456 "simplified"
> instruction names you have. That leaves 1848 that
> you are unable to access.
> 
> Take a look at the crand instruction. It uses numbers.
> Now, just imagine mixing that with branch instructions
> that hide the numbers. I hope you see the problem.

I never said we should use simplified instructions everywhere there are
instructions. Hence I don't see why we care here about 1848 instructions
not beeing accessible. Most of thoses 1848 instructions probably fit in the
'not so much' used, and thus doesn't need a simplified mmenonic.

> It doesn't appear to be so. He wrote:
> 
> : Oh well.. I've got quite used to tweaking rlwinm directly
> : but I suppose it's more clear for others to go to clrrwi.
> 
> So I'd like him to know that others like rlwinm directly too.

sure.

and some other prefer simplified instructions. I guess we're hitting a
wall here :)

But as clrrwi is already use in the kernel (as a lot of others simplified
instructions), either send a patch to remove them or don't say that this
is madness.

> Using instructions that are in the index makes sense.
> Using a zillion poorly documented alternatives is madness.

Maybe then you should rewrite all part of kernels, gcc, objdump and gdb that
use/disassemble the code with simplified instructions (mr, li, b*, etc...) too.
(clrrwi is as documented as mr)

-- 
Tab

Re: [PATCH] ppc32 use simplified mmenonics

[Horst von Brand]

Vincent Hanquez <tab@snarc.org> said:
> On Sun, Aug 22, 2004 at 06:41:32AM -0400, Albert Cahalan wrote:
> > The "or" is much easier, because it follows the
> > standard 3-register pattern. With "mr", which way
> > does it go? That's one more thing to remember.
> > In fact I don't know, but the "or" is obvious.
> > 
> > The 0 is your hint that the "or" isn't a plain "or".
> 
> Sure, but this is about mmenonic. When I see 'or', my mind doesn't make
> any link with 'move register' but only with 'or'. I have to process
> another term of the line (the 0) to see that the program want to move a
> register.

I'd assume somebody familiar with the architecture reads this as a matter
of course. 
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [PATCH] ppc32 use simplified mmenonics

[Benjamin Herrenschmidt]

> I'd rather you went the other way, replacing these
> barely-documented instructions with ones that are
> easy to look up. Motorola has about a zillion of
> these "simplified" instructions. I guess Motorola
> and IBM were jealous of Intel's CISC instructions.

It's just simplified mnemonics, not instructions ;)

> The big problem is this:
>         THESE ARE NOT IN THE INDEX!!!!!!

Yah, that sucks, I tend to agree... I've had a hard time in the
"early days" finding some of them in the manuals

> So, if I forget what one of these many instructions
> does, I'll have quite the time paging through the
> manual trying to find it.
> 
> If it's not in the index, please avoid it.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>