* Re: [PATCH] ppc32 use simplified mmenonics
@ 2004-08-22 0:45 Albert Cahalan
2004-08-22 9:43 ` Vincent Hanquez
2004-08-23 1:24 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 13+ messages in thread
From: Albert Cahalan @ 2004-08-22 0:45 UTC (permalink / raw)
To: tab; +Cc: benh, linux-kernel mailing list
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 0:45 [PATCH] ppc32 use simplified mmenonics Albert Cahalan
@ 2004-08-22 9:43 ` Vincent Hanquez
2004-08-22 10:41 ` Albert Cahalan
2004-08-23 1:24 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-22 9:43 UTC (permalink / raw)
To: Albert Cahalan; +Cc: benh, linux-kernel mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 9:43 ` Vincent Hanquez
@ 2004-08-22 10:41 ` Albert Cahalan
2004-08-22 14:45 ` Vincent Hanquez
0 siblings, 1 reply; 13+ messages in thread
From: Albert Cahalan @ 2004-08-22 10:41 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: benh, linux-kernel mailing list
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 10:41 ` Albert Cahalan
@ 2004-08-22 14:45 ` Vincent Hanquez
2004-08-22 12:40 ` Albert Cahalan
2004-08-22 17:02 ` Horst von Brand
0 siblings, 2 replies; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-22 14:45 UTC (permalink / raw)
To: Albert Cahalan; +Cc: benh, linux-kernel mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 14:45 ` Vincent Hanquez
@ 2004-08-22 12:40 ` Albert Cahalan
2004-08-22 16:28 ` Vincent Hanquez
2004-08-22 17:02 ` Horst von Brand
1 sibling, 1 reply; 13+ messages in thread
From: Albert Cahalan @ 2004-08-22 12:40 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: benh, linux-kernel mailing list
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 12:40 ` Albert Cahalan
@ 2004-08-22 16:28 ` Vincent Hanquez
2004-08-22 14:29 ` Albert Cahalan
0 siblings, 1 reply; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-22 16:28 UTC (permalink / raw)
To: Albert Cahalan; +Cc: benh, linux-kernel mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 16:28 ` Vincent Hanquez
@ 2004-08-22 14:29 ` Albert Cahalan
2004-08-22 19:17 ` Vincent Hanquez
0 siblings, 1 reply; 13+ messages in thread
From: Albert Cahalan @ 2004-08-22 14:29 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: benh, linux-kernel mailing list
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 14:29 ` Albert Cahalan
@ 2004-08-22 19:17 ` Vincent Hanquez
0 siblings, 0 replies; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-22 19:17 UTC (permalink / raw)
To: Albert Cahalan; +Cc: benh, linux-kernel mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 14:45 ` Vincent Hanquez
2004-08-22 12:40 ` Albert Cahalan
@ 2004-08-22 17:02 ` Horst von Brand
1 sibling, 0 replies; 13+ messages in thread
From: Horst von Brand @ 2004-08-22 17:02 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: Albert Cahalan, benh, linux-kernel mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 0:45 [PATCH] ppc32 use simplified mmenonics Albert Cahalan
2004-08-22 9:43 ` Vincent Hanquez
@ 2004-08-23 1:24 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2004-08-23 1:24 UTC (permalink / raw)
To: Albert Cahalan; +Cc: tab, linux-kernel mailing list
> 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>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] ppc32 use simplified mmenonics
@ 2004-08-21 22:23 Vincent Hanquez
2004-08-22 2:00 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-21 22:23 UTC (permalink / raw)
To: lkml; +Cc: Benjamin Herrenschmidt
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 */
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-21 22:23 Vincent Hanquez
@ 2004-08-22 2:00 ` Benjamin Herrenschmidt
2004-08-22 9:48 ` Vincent Hanquez
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2004-08-22 2:00 UTC (permalink / raw)
To: Vincent Hanquez; +Cc: lkml
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ppc32 use simplified mmenonics
2004-08-22 2:00 ` Benjamin Herrenschmidt
@ 2004-08-22 9:48 ` Vincent Hanquez
0 siblings, 0 replies; 13+ messages in thread
From: Vincent Hanquez @ 2004-08-22 9:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: lkml
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-08-23 1:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-22 0:45 [PATCH] ppc32 use simplified mmenonics Albert Cahalan
2004-08-22 9:43 ` Vincent Hanquez
2004-08-22 10:41 ` Albert Cahalan
2004-08-22 14:45 ` Vincent Hanquez
2004-08-22 12:40 ` Albert Cahalan
2004-08-22 16:28 ` Vincent Hanquez
2004-08-22 14:29 ` Albert Cahalan
2004-08-22 19:17 ` Vincent Hanquez
2004-08-22 17:02 ` Horst von Brand
2004-08-23 1:24 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2004-08-21 22:23 Vincent Hanquez
2004-08-22 2:00 ` Benjamin Herrenschmidt
2004-08-22 9:48 ` Vincent Hanquez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox