title: RiscV assembler - experimenting with the 'slli' command for RV32I
body: <p>I have been testing the following code on RiscV with the RV32I and RV64I assembler.</p>
  
  <p>The assembly source file is</p>
  
  <pre><code>.text
  slli   x31,x31,63
  </code></pre>
  
  <p>When I assemble for 32 bit targets I obtain the following machine code output.</p>
  
  <pre><code> 03ff9f93                slli    x31,x31,0x3f
  </code></pre>
  
  <p>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 <code>01ff9f93</code>. 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. </p>
  
  <p>One way to avoid this potential problem is to set the assembler command line option of <code>--fatal-warnings</code>. And the build process will halt.  But at a <code>-warn</code> 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. </p>
  
  <p>To keep the build simple for this test, I did the following.</p>
  
  <ol>
  <li>Created source file - "test.s"</li>
  <li><p>Copied source file to the bin directory of the RiscV 32 bit build. 
  Then,</p>
  
  <p><code>./riscv32-unknown-elf-as -L --fatal-warnings  test.s</code></p></li>
  </ol>
  
  <p>or</p>
  
  <pre><code> ./riscv32-unknown-elf-as -L -warn test.s
  </code></pre>
  
  <ol start="3">
  <li><p>Create list file </p>
  
  <p>./riscv32-unknown-elf-objdump -h -l -M numeric,no-aliases -S -d -EL a.out</p></li>
  </ol>
  
  <p>The lower lines of output will look something like this below if you set
  -warn level in the assembler. </p>
  
  <pre><code>Disassembly of section .text:
  
  00000000 &lt;.text&gt;:
     0:   03ff9f93                slli    x31,x31,0x3f
  </code></pre>
  
  <p>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?</p>