| Message ID | YoOZy3A3R0i0DUWB@p100 (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | parisc: Prevent using same register as soure and target in extru/shr | expand |
On 5/17/22 14:49, Helge Deller wrote: > In 2004 Randolph added the shr() assembly macro and noted that the > source and target register could not be the same. > > I did not find any confindence in the docs for this restriction. Maybe > it's related that on PA2.0 the upper bits may be clobbered? Looking at the generated kernel code from C-files, I'll find all over usages of extru source, x,y, target where source and target are the same register. So, at least for 32-bit this restriction can't be true. Any ideas why this restriction could have been added to the comments? Helge > Anyway, add a compile-time check for it now. > > Signed-off-by: Helge Deller <deller@gmx.de> > > diff --git a/arch/parisc/include/asm/assembly.h b/arch/parisc/include/asm/assembly.h > index ea0cb318b13d..ca1a12ae5ee7 100644 > --- a/arch/parisc/include/asm/assembly.h > +++ b/arch/parisc/include/asm/assembly.h > @@ -146,6 +146,9 @@ > /* Shift Right - note the r and t can NOT be the same! */ > .macro shr r, sa, t > extru \r, 31-(\sa), 32-(\sa), \t > +.ifc \r,\t > + .error "Can not used the same register (\r) in shr/extru as source and target register." > +.endif > .endm > > /* pa20w version of shift right */
I'm not aware of any PA-RISC instructions where the source and target registers can't be the same. In gcc asm statements, there are early clobber situations where the source and target can't be the same. The same situation could occur in assembler macros but never when there's a single instruction. The only thing unusual about the extru instruction is the most significant 32 bits in the target are undefined on PA 2.0. Thus, its use needs to be limited to 32-bit extracts. Dave On 2022-05-17 8:54 a.m., Helge Deller wrote: > On 5/17/22 14:49, Helge Deller wrote: >> In 2004 Randolph added the shr() assembly macro and noted that the >> source and target register could not be the same. >> >> I did not find any confindence in the docs for this restriction. Maybe >> it's related that on PA2.0 the upper bits may be clobbered? > Looking at the generated kernel code from C-files, I'll find all over usages of > extru source, x,y, target > where source and target are the same register. > So, at least for 32-bit this restriction can't be true. > > Any ideas why this restriction could have been added to the comments? > > Helge > > >> Anyway, add a compile-time check for it now. >> >> Signed-off-by: Helge Deller <deller@gmx.de> >> >> diff --git a/arch/parisc/include/asm/assembly.h b/arch/parisc/include/asm/assembly.h >> index ea0cb318b13d..ca1a12ae5ee7 100644 >> --- a/arch/parisc/include/asm/assembly.h >> +++ b/arch/parisc/include/asm/assembly.h >> @@ -146,6 +146,9 @@ >> /* Shift Right - note the r and t can NOT be the same! */ >> .macro shr r, sa, t >> extru \r, 31-(\sa), 32-(\sa), \t >> +.ifc \r,\t >> + .error "Can not used the same register (\r) in shr/extru as source and target register." >> +.endif >> .endm >> >> /* pa20w version of shift right */
Helge Deller <deller@gmx.de> writes: > On 5/17/22 14:49, Helge Deller wrote: >> In 2004 Randolph added the shr() assembly macro and noted that the >> source and target register could not be the same. >> >> I did not find any confindence in the docs for this restriction. Maybe >> it's related that on PA2.0 the upper bits may be clobbered? > > Looking at the generated kernel code from C-files, I'll find all over usages of > extru source, x,y, target > where source and target are the same register. > So, at least for 32-bit this restriction can't be true. I did a quick objdump on the 64 bit HP-UX kernel and that one also uses extrd/extrw where target and source are the same register. So i don't think that restriction is true.
On 5/18/22 08:57, Sven Schnelle wrote: > Helge Deller <deller@gmx.de> writes: > >> On 5/17/22 14:49, Helge Deller wrote: >>> In 2004 Randolph added the shr() assembly macro and noted that the >>> source and target register could not be the same. >>> >>> I did not find any confindence in the docs for this restriction. Maybe >>> it's related that on PA2.0 the upper bits may be clobbered? >> >> Looking at the generated kernel code from C-files, I'll find all over usages of >> extru source, x,y, target >> where source and target are the same register. >> So, at least for 32-bit this restriction can't be true. > > I did a quick objdump on the 64 bit HP-UX kernel and that one also uses > extrd/extrw where target and source are the same register. So i don't > think that restriction is true. Thanks for checking! Maybe it's meant that it clobbers when running *32-bit* code on PA2.0? Just a thought... Helge
diff --git a/arch/parisc/include/asm/assembly.h b/arch/parisc/include/asm/assembly.h index ea0cb318b13d..ca1a12ae5ee7 100644 --- a/arch/parisc/include/asm/assembly.h +++ b/arch/parisc/include/asm/assembly.h @@ -146,6 +146,9 @@ /* Shift Right - note the r and t can NOT be the same! */ .macro shr r, sa, t extru \r, 31-(\sa), 32-(\sa), \t +.ifc \r,\t + .error "Can not used the same register (\r) in shr/extru as source and target register." +.endif .endm /* pa20w version of shift right */
In 2004 Randolph added the shr() assembly macro and noted that the source and target register could not be the same. I did not find any confindence in the docs for this restriction. Maybe it's related that on PA2.0 the upper bits may be clobbered? Anyway, add a compile-time check for it now. Signed-off-by: Helge Deller <deller@gmx.de>