mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
shifting u_format.uimmediate by 6 may be affected by sign extension.
Thus, take out the 10 bits for comparison.
Without this patch, errors may occur, such as these bits are all ones.
Signed-off-by: Jinyang He <[email protected]>
---
arch/mips/kernel/process.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
index d737234..74d7fd8 100644
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
* microMIPS is kind of more fun...
*/
if (mm_insn_16bit(ip->word >> 16)) {
- if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
- (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
+ if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
+ ip->mm16_r5_format.rt == mm_jr16_op)
return 1;
return 0;
}
@@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
if (ip->r_format.opcode != mm_pool32a_op ||
ip->r_format.func != mm_pool32axf_op)
return 0;
- return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
+ return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;
#else
if (ip->j_format.opcode == j_op)
return 1;
--
2.1.0
On Thu, 21 Jan 2021, Jinyang He wrote:
> mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
> mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
The minor opcode extension field is comprised of bits 15:6, not 16:7 as
your description suggests. Please be accurate with statements.
> shifting u_format.uimmediate by 6 may be affected by sign extension.
Why? The `uimmediate' bit-field member is unsigned for a reason. No
sign-extension is made on unsigned data with the right-shift operation.
> Thus, take out the 10 bits for comparison.
>
> Without this patch, errors may occur, such as these bits are all ones.
How did you come to this conclusion?
> diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> index d737234..74d7fd8 100644
> --- a/arch/mips/kernel/process.c
> +++ b/arch/mips/kernel/process.c
> @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
> * microMIPS is kind of more fun...
> */
> if (mm_insn_16bit(ip->word >> 16)) {
> - if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
> - (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
> + if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
> + ip->mm16_r5_format.rt == mm_jr16_op)
> return 1;
> return 0;
> }
Code style changes should be submitted on their own as separate patches.
> @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
> if (ip->r_format.opcode != mm_pool32a_op ||
> ip->r_format.func != mm_pool32axf_op)
> return 0;
> - return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
> + return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;
You've now excluded JALR.HB, JALRS, and JALRS.HB instructions. The mask
was there for a reason. If you can't be bothered to verify microMIPS
changes say with QEMU, then at the very least please check documentation.
The intent of this code is clear and these instructions are even spelled
out explicitly in the comment at the top.
Thomas, please revert this change as I can see you've already taken it.
It's plain wrong.
Maciej
On 02/08/2021 05:31 AM, Maciej W. Rozycki wrote:
> On Thu, 21 Jan 2021, Jinyang He wrote:
>
>> mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
>> mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
> The minor opcode extension field is comprised of bits 15:6, not 16:7 as
> your description suggests. Please be accurate with statements.
>
>> shifting u_format.uimmediate by 6 may be affected by sign extension.
> Why? The `uimmediate' bit-field member is unsigned for a reason. No
> sign-extension is made on unsigned data with the right-shift operation.
>
>> Thus, take out the 10 bits for comparison.
>>
>> Without this patch, errors may occur, such as these bits are all ones.
> How did you come to this conclusion?
>
>> diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
>> index d737234..74d7fd8 100644
>> --- a/arch/mips/kernel/process.c
>> +++ b/arch/mips/kernel/process.c
>> @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
>> * microMIPS is kind of more fun...
>> */
>> if (mm_insn_16bit(ip->word >> 16)) {
>> - if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
>> - (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
>> + if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
>> + ip->mm16_r5_format.rt == mm_jr16_op)
>> return 1;
>> return 0;
>> }
> Code style changes should be submitted on their own as separate patches.
>
>> @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
>> if (ip->r_format.opcode != mm_pool32a_op ||
>> ip->r_format.func != mm_pool32axf_op)
>> return 0;
>> - return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
>> + return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;
> You've now excluded JALR.HB, JALRS, and JALRS.HB instructions. The mask
> was there for a reason. If you can't be bothered to verify microMIPS
> changes say with QEMU, then at the very least please check documentation.
> The intent of this code is clear and these instructions are even spelled
> out explicitly in the comment at the top.
It's my fault. :-(
How amazing the opcode design is!
Thanks,
Jinyang
> Thomas, please revert this change as I can see you've already taken it.
> It's plain wrong.
>
> Maciej
On Sun, Feb 07, 2021 at 10:31:38PM +0100, Maciej W. Rozycki wrote:
> On Thu, 21 Jan 2021, Jinyang He wrote:
>
> > mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
> > mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
>
> The minor opcode extension field is comprised of bits 15:6, not 16:7 as
> your description suggests. Please be accurate with statements.
>
> > shifting u_format.uimmediate by 6 may be affected by sign extension.
>
> Why? The `uimmediate' bit-field member is unsigned for a reason. No
> sign-extension is made on unsigned data with the right-shift operation.
>
> > Thus, take out the 10 bits for comparison.
> >
> > Without this patch, errors may occur, such as these bits are all ones.
>
> How did you come to this conclusion?
>
> > diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> > index d737234..74d7fd8 100644
> > --- a/arch/mips/kernel/process.c
> > +++ b/arch/mips/kernel/process.c
> > @@ -292,8 +292,8 @@ static inline int is_jump_ins(union mips_instruction *ip)
> > * microMIPS is kind of more fun...
> > */
> > if (mm_insn_16bit(ip->word >> 16)) {
> > - if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
> > - (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
> > + if (ip->mm16_r5_format.opcode == mm_pool16c_op &&
> > + ip->mm16_r5_format.rt == mm_jr16_op)
> > return 1;
> > return 0;
> > }
>
> Code style changes should be submitted on their own as separate patches.
>
> > @@ -305,7 +305,7 @@ static inline int is_jump_ins(union mips_instruction *ip)
> > if (ip->r_format.opcode != mm_pool32a_op ||
> > ip->r_format.func != mm_pool32axf_op)
> > return 0;
> > - return ((ip->u_format.uimmediate >> 6) & mm_jalr_op) == mm_jalr_op;
> > + return ((ip->u_format.uimmediate >> 6) & GENMASK(9, 0)) == mm_jalr_op;
>
> You've now excluded JALR.HB, JALRS, and JALRS.HB instructions. The mask
> was there for a reason. If you can't be bothered to verify microMIPS
> changes say with QEMU, then at the very least please check documentation.
> The intent of this code is clear and these instructions are even spelled
> out explicitly in the comment at the top.
>
> Thomas, please revert this change as I can see you've already taken it.
> It's plain wrong.
It's now reverted in mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]