CODEWITHSUNDEEP
assemblyriscv
daveW
daveW

Reputation: 601

RiscV assembler - experimenting with the 'slli' command for RV32I

I have been testing the following code on RiscV with the RV32I and RV64I assembler.

The assembly source file is

.text
slli   x31,x31,63

When I assemble for 32 bit targets I obtain the following machine code output.

 03ff9f93                slli    x31,x31,0x3f

A warning is thrown but it appears the upper 7 bits of the instruction word are not 'reserved'. Doing a quick hand assembly I would expect 01ff9f93. I realize that it is incorrect to use the immediate operand value of 63 but the assembler will write the 63 value anyway. This does not seem like correct operation.

One way to avoid this potential problem is to set the assembler command line option of --fatal-warnings. And the build process will halt. But at a -warn level it appears the 7 upper bits of the 32 target for the 'slli' command can be overwritten and you can create a legitimate RV64I instruction.

To keep the build simple for this test, I did the following.

  1. Created source file - "test.s"

  2. Copied source file to the bin directory of the RiscV 32 bit build. Then,

    ./riscv32-unknown-elf-as -L --fatal-warnings test.s

or

 ./riscv32-unknown-elf-as -L -warn test.s

  1. Create list file

    ./riscv32-unknown-elf-objdump -h -l -M numeric,no-aliases -S -d -EL a.out

The lower lines of output will look something like this below if you set -warn level in the assembler. 

Disassembly of section .text:

00000000 <.text>:
   0:   03ff9f93                slli    x31,x31,0x3f

I am wondering why the assembler takes this approach and shouldn't the upper 7 bits for 'slii' with RV32I always be stuck-at 0?

Upvotes: 3

Views: 2694

Answers (2)

Joachim Lusiardi
Joachim Lusiardi

Reputation: 151

Just a short remark:

I can see from the spec (Version 20190608-Base-Ratified ) on pages 130 for RV32I and 131 for RV64I that there should be a difference in the encoding of the SLLI instruction.

RV32I for the shift amount is limited to 5 bits and for RV64I this is extended to 6 bits. So depending on the used assembler, there should be differences in the binary that results and in the displayed warnings or errors.

Greets Joachim

Upvotes: 1

daveW
daveW

Reputation: 601

This problem was considered a bug and the assembler code has been changed and merged. You can see details at GitHub riscv/riscv-binutils-gdb on the riscv-next branch. In 'gas' (the assembler) the severity level was changed from 'warn' to 'error' - preventing any illegal RV32I machine code to be created (03ff9f93 is not legal machine code for the slli command on RV32I).

For osgx - I am still intrigued by your comment that there are no separate 32/64 bit encoders. Can you please clarify?

Upvotes: 1

Related Questions