Help with SLT insn under MIPS R6

Help with SLT insn under MIPS R6

[Tony Ambardar]

Hello,

While working on a MIPS32 BPF JIT and testing under QEMU, I've
encountered some problems related to the behaviour of the SLT[I][U]
opcode under MIPS ISA R6, and would appreciate some help/insight
clarifying various online and documented descriptions.

In "Introduction to the MIPS32 Architecture"
(MD00082-2B-MIPS32INT-AFP-06.01), some wording states:
"CPU truth values ... are replaced by Release 6 instructions that
generate truth values of all zeroes or all ones (suitable for logical
operations involving masks) and interpret all zeroes or any non-zero
bit as true or false ..."

This change is also echoed elsewhere online:
  - https://www.linuxsecrets.com/linux-mips-wiki/MIPS_Release_6.html#MIPS32.2F64_Release_6
  - https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS64

However, in "The MIPS32® Instruction Set Manual"
(MD00086-2B-MIPS32BIS-AFP-6.06), the SLTU insn *is not* specified to
generate all-ones truth values.

Generating all-ones truth values for SLTU impacts things like
carry-addition code written for MIPS32R6, such as in my BPF JIT
R6-support code. Curiously, while testing this under QEMU I saw many
test-case failures, and debugging seemed to show QEMU not generating
all-ones truth values when emulating the R6 ISA.

Thus, the key questions:
1. What is the correct/expected output of SLT under the MIPS ISA R6?
2. Does QEMU properly emulate SLT under ISA R6? If not, how do other
developers reliably test for R6 compliance?

Thanks in advance for any help,
Tony

Re: Help with SLT insn under MIPS R6

[Serge Semin]

Hi Tony,

Are you working on adding the MIPS32 EBPF JIT support? If so that
would have been super useful to have on MIPS arch!

On Wed, Jun 16, 2021 at 07:15:41PM -0700, Tony Ambardar wrote:
> Hello,
> 
> While working on a MIPS32 BPF JIT and testing under QEMU, I've
> encountered some problems related to the behaviour of the SLT[I][U]
> opcode under MIPS ISA R6, and would appreciate some help/insight
> clarifying various online and documented descriptions.

I can't say about the issue for sure but here are my thoughts regarding
it.

> 
> In "Introduction to the MIPS32 Architecture"
> (MD00082-2B-MIPS32INT-AFP-06.01), some wording states:
> "CPU truth values ... are replaced by Release 6 instructions that
> generate truth values of all zeroes or all ones (suitable for logical
> operations involving masks) and interpret all zeroes or any non-zero
> bit as true or false ..."
> 
> This change is also echoed elsewhere online:
>   - https://www.linuxsecrets.com/linux-mips-wiki/MIPS_Release_6.html#MIPS32.2F64_Release_6
>   - https://en.wikipedia.org/wiki/MIPS_architecture#MIPS32/MIPS64

First of all what I would rely on is the official document rather than an
on an a few words on wiki, which AFAICS were mentioned with no
particular context. So what we need to analyze is what
+ MD00082-2B-MIPS32INT-AFP-6.01 (MIPS® Architecture For Programmers
Volume I-A: Introduction to the MIPS32® Architecture) and
+ MD00086-2B-MIPS32BIS-AFP-6.06 (MIPS® Architecture for Programmers
Volume II-A: The MIPS32® Instruction Set Manual) say.
Here is what MD00082-2B-MIPS32INT-AFP-6.01 says:

"CPU truth values changed from single-bit to multi-bit: pre-Release 6
instructions that only looked at bit 0 of the register containing a
truth value are replaced by Release 6 instructions that generate truth
values of all zeroes or all ones (suitable for logical operations
involving masks) and interpret all zeroes or any non-zero bit as true
or false, which is compatible with programming languages such as C.
There are also related changes to branches and conditional move
instructions."

I think the part regarding the CPU truth values only concerns the
changes described in MD00082-2B-MIPS32INT-AFP-6.01: "5.5.3 Conditional
Move Instructions" and some new conditional branch instuctions
introduced in MIPSr6. So GPR-related MOVN/MOVZ (see
MD00086-2B-MIPS32BIS-AFP-6.06 and "Programming Notes" of these
instructions for details) have been replaced with GPR-related
SELNEZ/SELEQZ. The later ones are now compatible with not only dual
booleans logic (0 and 1 which MOVN/MOVZ produced), but with C-like
booleans interpretation (any non-zero value is true). That doesn't
imply the SLT{I,U,IU} semantic change, but merely that the
SELNEZ/SELEQZ instructions can correctly work with any result
generated by logical operations ({N}OR{I},AND{I},XOR{I}, etc) and data
loaded from external memory. Most likely the similar semantics related
to the C-compatible boolean perception has been implemented in R6
instructions BEQZC/BNEZC.

> 
> However, in "The MIPS32® Instruction Set Manual"
> (MD00086-2B-MIPS32BIS-AFP-6.06), the SLTU insn *is not* specified to
> generate all-ones truth values.

Right. AFAICS it doesn't need to. The way it generates the true value
is perfectly compatible with SELNEZ/SELEQZ and BEQZC/BNEZC.

> 
> Generating all-ones truth values for SLTU impacts things like
> carry-addition code written for MIPS32R6, such as in my BPF JIT
> R6-support code. Curiously, while testing this under QEMU I saw many
> test-case failures, and debugging seemed to show QEMU not generating
> all-ones truth values when emulating the R6 ISA.
> 
> Thus, the key questions:

> 1. What is the correct/expected output of SLT under the MIPS ISA R6?

In accordance with MD00086-2B-MIPS32BIS-AFP-6.06 SLT{I,U,IU} should
generate 1 as true value and 0 otherwise.

> 2. Does QEMU properly emulate SLT under ISA R6? If not, how do other
> developers reliably test for R6 compliance?

Alas I can't say much regarding QEMU. So @Paul, @Thomas, could you
join in the discussion and if possible Cc' someone MIPS-Qemu aware?

-Sergey

> 
> Thanks in advance for any help,
> Tony