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
