RiscV assembler - problem with 'SLTI' command about riscv-binutils-gdb HOT 19 CLOSED

The immediate is 12 bits, but that corresponds to the range [-0x800,0x7ff]. 0xfff is out of range.

from riscv-binutils-gdb.

OK so the immediate value is sign-extended to 12 bits. And in the case of 0x7ff the MSB would be set (bit 11). Is that a correct summary? So I tested the SLTIU instruction and it handles the 0xfff immediate value with no errors. i naively assumed you could write any 12 bit value to the immediate field and the opcode would tell you if the processor interprets the immediate field as signed or not signed. Kind of like letting the programmer do the sign extension.

For the SLTI instruction, the programmer only has access to write imm[10:0] and the value is sign-extended. The table on page 54 could use some clarification. Is it fair to say that for SLTI, imm[11] is reserved for sign extension?

from riscv-binutils-gdb.

All 12, 13, 20, and 21-bit immediates are sign extended, per https://cdn.rawgit.com/riscv/riscv-isa-manual/master/release/riscv-spec-v2.2.pdf#page=23 §2.2

from riscv-binutils-gdb.

I have no argument on the length of the immediate fields, but for 12 bit immediate on SLTI, the programmer only has access to 11 bits. Why not make that clear in the tables and instruction listings?

But here is what is really bugging me - here is a snippet from the list file

7ff02013 slt x0,x0,2047

Looks to be 2 problems. The opcode mnemonic is not correct. Why is SLTI disassembled to SLT? The machine code looks to be legitimate SLTI. OK - I'll run with that - but what happened to the sign extension? Shouldn't the MSB of the instruction word be set to 1? Otherwise how does sign extension (via the assembler) help the hardware decode task? The hardware decode will simply strip off the 12 bits in this immediate field. It is like the MSB of the machine code for SLIT is always 0. Don't get me wrong here - I think the idea of the ISA in RiscV performing the chore of sign extension - is a good idea - but is that really happening here?

from riscv-binutils-gdb.

2047 = 0111 1111 1111

from riscv-binutils-gdb.

OK gave it some more thought and ran this code.

cat testSLTI.s
.text
slti x0,x0,-1

./riscv64-unknown-elf-as testSLTI.s -o testSLTI.o
./riscv64-unknown-elf-objdump -h -l -M numeric,no-aliases -S -d -EL testSLTI.o

testSLTI.o: file format elf64-littleriscv

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000004 0000000000000000 0000000000000000 00000040 22
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 0000000000000000 0000000000000000 00000044 20
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 0000000000000000 0000000000000000 00000044 2**0
ALLOC

Disassembly of section .text:

0000000000000000 <.text>:
0: fff02013 slt x0,x0,-1

The machine code looks correct for SLTI (the best way to test this is with positive and negative decimal values for the immediate field). The 12 bit immediate is considered signed and the programmer has 11 bits of magnitude. Got it. But SLT should not have 2 register operands and one immediate value. So, I still see a problem with the disassembly.

from riscv-binutils-gdb.

The assembler and disassembler both accept slt as a synonym for slti when used with an immediate argument. This is not going to change.

from riscv-binutils-gdb.

The list file shows a machine code that is not for SLT. Agree?

from riscv-binutils-gdb.

The slt machine code and the slt assembler mnemonic are not the same thing.

The slt assembler mnemonic is a pseudoinstruction which can generate either a slt machine code or a slti machine code.

All of the ALU operations are like this.

from riscv-binutils-gdb.

If SLT is a pseudoinstruction then why is it not listed as a pseudoinstruction in the spec? I did not find SLT listed in Table 21.1 in the v2.1 spec or in Table 20.2 of the v2.2 spec. And what value is there in creating a pseudoinstruction that has the exact same mnemonic as a base instruction mnemonic?

from riscv-binutils-gdb.

As far as I know it wasn't done on purpose, it's MIPS baggage that we're now stuck with forever because of the binutils upstreaming. I'll file a ticket on riscv-isa-manual so that it gets documented.

from riscv-binutils-gdb.

I feel you are being evasive to my questions.

Everything I can find says that SLT is a base instruction only. It is not a pseudoinstruction as defined by the spec. The spec should be the controlling document - not how MIPS implemented their binutils. Binutils and other software tools need traceability back to the original intent aka the spec.

As a practicing engineer - I think it is always good to go back and review the requirements.
I think the rational requirements for the list file output should be the following.

1. produce machine code that matches a base instruction.

2. or produce machine code that matches the corresponding pseudoinstruction (e.g. RET).

The list file could publish a mnemonic from a pseudosinstruction but the machine code is traceable back to base instruction(s). So you would look up the pseudoinstruction in the spec to find the base instruction and those base instructions would match the machine code.

What I have here for this issue is neither of the above. SLT is not defined as a pseudoinstruction. So the listing output for SLT is wrong. And I don't think this is a documentation change but a bug.

I think what has happened is that the assembly implementation freelances some when it comes to the SLT instruction that has 2 register and 1 immediate operands. A strict interpretation of the RiscV spec requires SLT to have all register operands. But the assembler implementation internally converts it to a SLTI instruction. The high level operation of the SLTI instruction with the same operands will be as intended. BUT the listing file - something I believe is critical to core debugging - has to be correct - and it is not per the requirements I listed previously. BTW, I don't know for certain if the assembler is the issue here or 'objdump'.

Lastly, the unsigned version of SLT is SLTU. It operates as expected - it will convert a SLTU with 2 registers and 1 immediate to the SLTIU instruction. And the listing output shows SLTIU and the correct corresponding machine code. Now that I understand how this undocumented feature in the assembler works - I have no problems with how SLTU works with an immediate operand. Somewhere this operation should be noted. But it does not operate like SLT when it comes to the listing output.

test case below

.text
slt x0,x0,-1
sltu x0,x0,0

0000000000000000 <.text>:
0: fff02013 slt x0,x0,-1
4: 00003013 sltiu x0,x0,0

The machine code 00003013 is correct for SLTIU x0,x0,0 So, the SLTU instruction - because of the operands - was converted to the SLTIU instruction to save the programmer an error in operands. However, the mnemonic SLT does not match the machine code fff02013. So the utilities ('as' and 'objdump' ) handle these instructions differently. And these instructions differ only slightly in function - (signed and unsigned compares). So, by opening a new issue on documentation - are you proposing SLT be defined as a new pseudoinstruction (with the exact same mnemonics) but SLTU stay as a base instruction?

from riscv-binutils-gdb.

I have narrowed the problem down to something in 'objdump'.

cat testSLTI.s

# -------testSLTI.s-------------

.macro mSUBI rx,ry,imm

        li      x5,\imm
        sub     \rx,\ry,x5

.endm


.text
        slt     x0,x0,-1        # bug 
        sltu    x0,x0,0         # -> sltiu
        add     x0,x0,5         # -> addi
        xor     x0,x0,8         # -> xori
        or      x0,x0,12        # -> ori
        and     x0,x0,16        # -> andi
        sll     x0,x0,6         # -> slli
        srl     x0,x0,4         # -> srli
        sra     x0,x0,9         # -> srai
#       mSUBI   x10,x9,2        # macro

./riscv64-unknown-elf-as -warn testSLTI.s -o testSLTI.o

./riscv64-unknown-elf-objdump -l -M numeric -S -d testSLTI.o

testSLTI.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.text>:
   0:   fff02013                slti    x0,x0,-1
   4:   00003013                sltiu   x0,x0,0
   8:   00500013                li      x0,5
   c:   00804013                xori    x0,x0,8
  10:   00c06013                ori     x0,x0,12
  14:   01007013                andi    x0,x0,16
  18:   00601013                slli    x0,x0,0x6
  1c:   00405013                srli    x0,x0,0x4
  20:   40905013                srai    x0,x0,0x9

This is a correct disassembly of the first line or SLT -> SLTI

Change to 'no-aliases' which will expand the pseudoinstructions to base instructions

./riscv64-unknown-elf-objdump -l -M numeric,no-aliases -S -d testSLTI.o

testSLTI.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.text>:
   0:   fff02013                slt     x0,x0,-1
   4:   00003013                sltiu   x0,x0,0
   8:   00500013                addi    x0,x0,5
   c:   00804013                xori    x0,x0,8
  10:   00c06013                ori     x0,x0,12
  14:   01007013                andi    x0,x0,16
  18:   00601013                slli    x0,x0,0x6
  1c:   00405013                srli    x0,x0,0x4
  20:   40905013                srai    x0,x0,0x9

The first line is wrong. The machine code does not match SLT.

from riscv-binutils-gdb.

Thanks guys for your quick action on this issue. I'd like to propose a feature request for the RiscV assembler - how should that be done?

from riscv-binutils-gdb.

The main consideration is that gcc-7.1.0 needs to be supported, so we can't simply remove features (which is what I thought you were asking for above, sorry).

If the proposal doesn't cause problems for gcc-7.1.0 then it's fine to post an issue here.

from riscv-binutils-gdb.

If the feature is something that requires discussion then you should post of the sw-dev mailing list. We try to discuss anything that would be an interface change, specifically so the developers of other toolchains (LLVM) can weigh in. The goal here is to avoid having a bunch of wacky interfaces that differ between toolchains like you end up with in ARM land.

When you've worked it out well enough to be a concrete thing then open a new issue on the relevant github.com/riscv repository (which would be riscv-binutils-gdb if it's an assembler issue).

from riscv-binutils-gdb.

from riscv-binutils-gdb.

OK, well, this is the wrong place to discuss that feature. Can you bring it up on the sw-dev mailing list and see what everyone thinks?

from riscv-binutils-gdb.

from riscv-binutils-gdb.