riscv-non-isa / riscv-asm-manual Goto Github PK

maybe the 1st one was stale.

Hello Everyone
I compiled a C program with -O2 flag enabled. On inspecting the assembly file generated by the compiler (-S flag) I noticed a couple of tail pseudo instruction. But in the object dump file generated, I noticed that the tail pseudo instruction gets converted to j instruction.
My doubt is, in the explanation given in the manual, it is specified that tail pseudo instruction gets transformed to jalr. Is this not followed always?

Thank you so much
Sai

Currently, even if .option norvc is in effect, the assembler still generates relaxable instructions and R_RISCV_RELAX relocations, which may end up getting turned into compressed instructions by the linker anyway:

    .section .text

test1:
    .option push
    .option norvc
    lui a0, %hi(data)
    addi a0, a0, %lo(data)
    .option pop

test2:
1:
    .option push
    .option norvc
    jump 1b, t0
    .option pop

    .section .rodata
data:
    .quad 42

If we assemble and link it:

$ riscv64-unknown-linux-gnu-gcc -c -o norvc.o norvc.s
$ riscv64-unknown-linux-gnu-ld -nostdlib -o norvc norvc.o
# This warning is expected
riscv64-unknown-linux-gnu-ld: warning: cannot find entry symbol _start; defaulting to 00000000000100b0
$ riscv64-unknown-linux-gnu-objdump -Mno-aliases -dr norvc

norvc:     file format elf64-littleriscv


Disassembly of section .text:

00000000000100b0 <test1>:
   100b0:       6541                    c.lui   a0,0x10
   100b2:       0b850513                addi    a0,a0,184 # 100b8 <data>

00000000000100b6 <test2>:
   100b6:       a001                    c.j     100b6 <test2>

The generated relaxations can be seen in the intermediate object file:

$ riscv64-unknown-linux-gnu-objdump -Mno-aliases -dr norvc.o

norvc.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <test1>:
   0:   00000537                lui     a0,0x0
                        0: R_RISCV_HI20 data
                        0: R_RISCV_RELAX        *ABS*
   4:   00050513                addi    a0,a0,0 # 0 <test1>
                        4: R_RISCV_LO12_I       data
                        4: R_RISCV_RELAX        *ABS*

0000000000000008 <test2>:
   8:   00000297                auipc   t0,0x0
                        8: R_RISCV_CALL .L1^B1
                        8: R_RISCV_RELAX        *ABS*
   c:   00028067                jalr    zero,0(t0) # 8 <test2>

I'm not sure how big of a deal this is. It is certainly unexpected at first glance, but it this even worth doing anything about?

I'm also not sure whether to post it here or post it at https://github.com/riscv-non-isa/riscv-elf-psabi-doc (where linker relaxation is specified), but my idea is that this kind of temporary .option norvc is probably rare enough that this case might not be worth the trouble getting the linker to handle this.

hi,
why c.lwsp x0, 0x40(sp) will cause Error: illegal operands `c.lwsp x0,0x40(sp)'?
thanks
Peter

It would be useful to have a section explaining how to run the code, possibly in the form of a "Getting Started" subsection.

hi
Gas assemble jal x2,0x12 as 0000016f, i think it is wrong. May be gas is try to optimizing the output bytes, possible to turn this feature off?
thanks

.section .text
.globl _start
_start:
	    jal x2,0x12

a.out:     file format elf64-littleriscv

Contents of section .text:
 0000 6f010000                             o...            
Contents of section .riscv.attributes:
 0000 412d0000 00726973 63760001 23000000  A-...riscv..#...
 0010 05727636 34693270 305f6d32 70305f61  .rv64i2p0_m2p0_a
 0020 3270305f 66327030 5f643270 3000      2p0_f2p0_d2p0.  

Disassembly of section .text:

0000000000000000 <_start>:
   0:	0000016f          	jal	sp,0 <_start>

I would like to suggest two improvements to the table with pseudo instructions:

1. For pseudo instructions that maps to more than one real instruction, put the real instructions on separate lines. Today the real instructions are separated with ';', and the second instruction is wrapped half way onto the next line. This makes it quite hard to see the real instructions and their operands, fields.

2. Somewhere, either before or after the table explain 'myriad sequences', an expression which only appears in the table. For non-native English speakers, this short expression may be hard to understand what it implies.

Hi
When i compile these, i got error:

.section .text
.global _start
_start:
    lui     a1, %hi(msg)
    addi    a1,a1,%lo(msg)
    jalr    ra, puts
2:  j 2b

.section .rodata
msg:
    .string "Hello World\n"

/root/workspace/riscv>riscv-none-embed-as a.s
a.s: Assembler messages:
a.s:6: Error: illegal operands `jalr ra,puts'

/root/workspace/riscv>riscv-none-embed-as -v
GNU assembler version 2.32 (riscv-none-embed) using BFD version (xPack GNU RISC-V Embedded GCC, 64-bit) 2.32

thanks
Peter

This issue riscv/riscv-isa-manual#540 suggested to supersede the section on pseudoinstructions inside RISC-V ISA manual with riscv-asm-manual. We can cover more pseudoinstructions than we do now in this repository - I can't see any mention of fence, no mention of "branch" pseudoinstructions. Shouldn't we just add the table from the ISA manual 2.2 to the markdown?

(Moved from riscv/riscv-isa-manual#825 at suggestion of @nick-knight; added section on alternative solutions)

The sheer number of RISC-V registers can make it hard to keep track of what has been assigned where when coding assembler by hand. Some assemblers allow the creation of synonyms -- "renaming" -- for the ABI names of the registers via .equ, .eqv or a similar statement, which can help. Such synonyms can also reduce the chance that a single typo -- say, from t0 to t1 -- remains unnoticed by coder and assembler.

However, there is currently no standard or recommended best practice for this that I am aware of. Providing such a recommendation or standard could cut down on the number of variants in the wild, aiding readability and supporting debugging of hand-written code.

This issue proposes adding a simple, short recommendation for a "common convention" or "best practices" for creating synonyms for ABI register names when hand-coding assembler, for inclusion in The RISC-V Instruction Set Manual Volume I: Unprivileged ISA, presumably in Chapter 25. The assumption is that this is going to happen anyway, so an attempt should be made to nudge coders towards a common format.

Criteria

To keep it simple, there are three criteria for this scheme:

1. Synonyms should only be created if many registers are in use at the same time and only for registers that are used for a longer time. In no way should "renaming" become the default practice.
2. The original ABI register name should be conserved to aid debugging. The idea is to add information, accepting the inherent redundancy for the sake of human readers and error detection.
3. In addition, an indicator of the type of data stored in the register or its intended use may be included for the same reason.

Syntax

The original register ABI name is kept, but followed by an underscore; then an optional single letter for the type or use, followed by a second underscore; finally the user-chosen name.

Examples:

    .eqv t0_n_cats t0      # current number of cats
    .eqv s1_p_catname s1   # pointer to the beginning of a string
    .eqv s2_f_havetuna s2  # flag to bool if goal achieved 

As an initial suggestion for the type indicators:

• c counter
• f flag
• l loop counter
• n number of
• p pointer

Important: The original ABI name of the register remains untouched and fully functional. Any new definition creates a synonym, not a replacement.

Example: The Battle of the Four Armies

Consider as a toy example a battle between hobbits, orcs, elves, and dragons, whose numbers are stored in s0, s1, s2, and s3 respectively. A code snippet to decide the winner could look like this:

        bgtz s3, dragons_win
        bgt s1, s2, orcs_win
        bgt s2, s1, elves_win
        j hobbits_win

Since these registers are used heavily in the rest of the code as well, we create synonyms following the scheme proposed:

.eqv s0_n_hobbits s0  # number of hobbitses
.eqv s1_n_orcs s1     # number of orcs
.eqv s2_n_elves s2    # number of elves
.eqv s3_n_dragons s3  # number of dragons

Our code snippet then becomes:

        bgtz s3_n_dragons, dragons_win
        bgt s1_n_orcs, s2_n_elves, orcs_win
        bgt s2_n_elves, s1_n_orcs, elves_win
        j hobbits_win

The additional information makes the code more readable and the logic easier to follow while preserving all original information. Also, a typo such as t2_n_elves will now be caught by the assembler because this name is not defined.

Drawbacks

• Creating synonyms for register names or renaming registers is uncommon, since most processors simply do not have enough of them for these problems to occur. Any such change could cause confusion when readers first are confronted with code that contains renamed registers. Some people will object on principle.
• There is currently no assembler-level support for this; some assemblers might even refuse creating register synonyms; possibly this might break some compiler/assembler level checks. This is a chicken-or-egg problem, as a convention for register synonyms would provide a basis for assembler writers to implement this function.
• Register renaming might start to be considered a must or best practice in itself for hand-coding assembler, not a tool to be used sparingly in situations where a large number of registers in use becomes unwieldy.
• There is currently no way to take back or delete synonyms once stated.

Alternatives

It seems that some people are currently using #define statements to implement this functionality. However, RISC-V should not be dependent on a single high-level language for this. Given the (slow) rise of Rust as a C alternative, this current solution seems especially problematic.

Open questions

• A suggestion for the scope of using these modified names should be included, possibly on a per-subroutine or segment basis.

In the manual,I found:

ld      a1, 0(a0)
...
sd      a1, 0(a0)

I know that ld will load the information from memory to register. And the sd is the opposite.

But what's the meaning of 0(a0)? I can't understand this syntax.

Another question:

pass:
        la a0, pass_msg
        jal puts
        j shutdown

fail:
        la a0, fail_msg
        jal puts
        j shutdown

What's the meaning of "puts" and "shutdown"?

It would be helpful to have a bit in here describing specifying ordering for atomic instructions. I've looked around, and while I've determined that you can set the rl bit by adding a .rl on an atomic instruction, and the aq bit by adding a .aq, I can't figure out how one requests both. The specification seems to indicate that this is possible in section 7.2:

Setting both aq and rl bits on the LR instruction, and setting the aq bit on the SC instruction makes the LR/SC sequence sequentially consistent with respect to other sequentially consistent atomic
operations.

I've tried the forms lr.d.aq.rl, lr.d.sc, and lr.d.sq (my best guesses for notation) and the assembler complained.

Hi
when my risc-v mcu start, the SP is 0. If run these two instructions:

8000000: 7179 addi sp,sp,-48
8000002: d622 sw s0,44(sp)

The first line will change the sp to -48, and then store s0 to -48+44 = -4 , but -4 is fffffffc, which is not an exist memory zone of the mcu, i can't explain this. Please help. Attached is the MCU i am using.

GD32VF103_User_Manual_EN_V1.0.pdf

In the elf i see the stack section pointing to ram, but in the code i don't see it stuck the memory address to sp

C:\workspace\riscv-simulator\src\test\resources\hk\quantr\riscv_simulator\example_code>riscv-none-embed-readelf -S a.elf
There are 8 section headers, starting at offset 0x215c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        08000000 001000 0000dc 00  AX  0   0  2
  [ 2] .data             PROGBITS        20000000 002000 000000 00  WA  0   0  1
  [ 3] .bss              NOBITS          20000000 002000 000000 00  WA  0   0  1
  [ 4] .stack            NOBITS          20007c00 002c00 000400 00  WA  0   0  1
  [ 5] .symtab           SYMTAB          00000000 002000 0000e0 10      6   7  4
  [ 6] .strtab           STRTAB          00000000 0020e0 000047 00      0   0  1
  [ 7] .shstrtab         STRTAB          00000000 002127 000033 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

Thanks
Peter

Hi. I have problems on comprehending the following example on relative addressing.

.section .text
.globl _start
_start:
1:	    auipc a0,     %pcrel_hi(msg) # load msg(hi)
	    addi  a0, a0, %pcrel_lo(1b)  # load msg(lo)
	    jal ra, puts
2:	    j 2b

.section .rodata
msg:
	    .string "Hello World\n"

As I understand it, %pcrel_hi(msg) computes the (msg - pc)[31:20] (the higher 20 bits of the offset). Why the next line is addi a0, a0, %pcrel_lo(1b), instead of something like %pcrel_lo(msg)?

Also, if my understanding was correct, then there would be another problem. The values of pc are different when auipc and addi get executed. So it seems to be incorrect to simply use %pcrel_lo(msg) in addi. Am I missing something here?

As a gentle reminder, the "Friendly Terminology" policy link which uses the "Inclusive Naming" community link includes the word "master" as a Tier 1: Replace Immediately word.

You can follow these steps to rename your branch: https://gist.github.com/danieldogeanu/739f88ea5312aaa23180e162e3ae89ab

Hi
We are trsting our RISC-V simulator, is there any very big assembly example code ?
thanks
Peter

Recently ratified code size reduction specification possibly causes a few problems on this manual and toolchains.

This is because C should be expanded following the conventional rule (where "contain" and "imply" are equivalent, just like that M implies Zmmul while Zmmul is a subset of M).

My branch on GNU Binutils implemented this expansion rule.

Should we stop implying Zca etc. from C?
Should we make any countermeasures or special rules?

I would like to hear your thoughts.

1. Example on arch

.option arch, -c # Disable compressed extension, we can't use any instruction in extension.
memcpy_norvc:

It will stop working since -c will not disable C extension subsets including relevant Zca, as warned on a NOTE on the .option arch description.

It seems no code on GitHub truly depends on .option arch, -c (except Binutils testcases).

2. .option norvc

2.1. .option norvc equivalents

.option push
.option arch, -c   # Alternative of .option norvc
.option pop

It will not be true either. The most robust solution is to use only +c unless we don't want any compressed instructions.

2.2. What should .option norvc disable?

In the .option rvc/norvc section,

Enable/disable the C-extension for the following code region.

It does not mention any C extension subsets.
IMO, it's natural to disable all C extension subsets: Zca, Zcd and Zcf by .option norvc (on my GNU Binutils branch, I implemented to do so, but not other compressed extensions like Zcb).

What do you think?

I'm just starting to look at RISC-V assembler programming (as a hobby, I do 6502/65816 stuff), and though it is easy to find lists of registers, explanations of what they do, what seems to be sorely missing are code snippets for common tasks -- say, simple loops, nested loops, jump tables, how to set up a stack when there is no hardware stack, how to copy a region of memory to another region of memory.

Since these common constructs (maybe "idioms" is a better word) are used over and over again, having them written down with detailed explanations would jump-start coding so people don't have to invent the, er, loop all over again. I'm also sure there are some sneaky tricks people don't think of at first; there usually are in assembler programming.

Also, just out of curiosity, is there any reason this is being written in markup and not as a wiki?

Thanks!

GNU assembler emits a pair of R_RISCV_ADD32 and R_RISCV_SUB32 for 32-bit label differences. This assembler construct is useful for metadata and the desired behavior should be documented somewhere.

.option push
.option norelax
.section .text,"ax",@progbits
lo:
  ret
hi:
.option pop

.data
.long hi - lo

Currently both GNU assembler and LLVM integrated assembler emit R_RISCV_ADD32 R_RISCV_SUB32 regardless of the relax/norelax state. I think it will be useful to have a way to emit a constant in the norelax case to make relocatable object files smaller. This will help clang -g:

.section        .debug_info,"",@progbits
...
.word   .Lfunc_end0-.Lfunc_begin0

If 32-bit label differences always lead to R_RISCV_ADD32 R_RISCV_SUB32, it will be cumbersome to get rid of the relocations in -mno-relax mode. An object file producer can do some hard work emitting a constant but this isn't feasible for an assembly file producer.

The documentation may specify:

• the symbols must be STB_LOCAL. Currently the assemblers don't report an error even if this output may not make sense as linked output.
• the behavior when the labels are not in a SHF_EXECINSTR section.

@compnerd

Providing a rounding mode alongside a floating point instruction seems to work for me when used in an inline assembly. For example:
fadd.s ft0, ft0, ft0, rtz
(reference: riscv/riscv-isa-manual#230)
It generates the same assembly code.

However, if I instead want to pass the rounding mode as an argument to inline assembly like so:

asm volatile (
                      "fcvt.s.w fa5, %[a];"  // convert int a to float in register fa5
                      "fcvt.s.w fa6, %[b];"
                      "fmul.s fa7, fa5, fa6, %[frm];"
                      "fcvt.w.s %[rf], fa7"
                      : [rf] "=r" (rf)
                      : [a]  "rm" (f[i]) ,
                        [b]  "rm" (f[j]) ,
                        [frm] "s" ("rtz")  // note the "s" constraint
);

There's an error:
Error: illegal operands fmul.s fa7,fa5,fa6,.LC4
(also tried "X", "S" instead of "s"; reference: https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html)

Is there a way to send in rounding mode as an argument in inline assembly?

Hi
Why c.addi x2,0b111111 gives us "a.s:17: Error: illegal operands `c.addi x2,0b110000'". The IMM of CI Type should have 6 bits.
Thanks
Peter

hi
i am using gas:

jal x0,0x00 -> give me 6f 00 00 00
jal x0,0x1234 -> give me 6f 10 40 23
jal x0,0x1f give me this error:

temp.o: in function _start': (.text+0x0): relocation truncated to fit: R_RISCV_JAL against UND'

why?

thanks
Peter

Inside the relative addressing example, you use '1b' inside the '%pcrel_lo' when I think it should be 'msg'.

addi  a1, a1, %pcrel_lo(1b)  # load msg(lo)

The manual lists signed loads, l{b|h|w|d} but not the unsigned variant, l{b|h|w}u. Suggest adding it.

in "GOT-indirect addressing"

1:
auipc a0, %got_pcrel_hi(msg + 1)
ld a0, %pcrel_lo(1b)(a0)

Which generates the following assembler output and relocations as seen by objdump:

0000000000000000 <.text>:
0: 00000517 auipc a0,0x0
0: R_RISCV_GOT_HI20 msg+0x1
4: 00050513 mv a0,a0
4: R_RISCV_PCREL_LO12_I .L1

ld should not expand into mv, looks like copypasted from section above

Hi there,

just beginning to look into risc-v implementation on fpga, so please be kind/patient.

I tried using firefox to print #riscv-asm.md however on my uptodate firefox 122.0

printing the table: Registers of the RV32I. Based on RISC-V documentation and Patterson and Waterman "The RISC-V Reader" (2017)

28 blank pages are inserted between

x8 s0 or fp saved register 0 or frame pointer yes

and

x9 s1 saved register 1 yes

quite likely a firefox bug, but....

anyway thanks for considering.

The project is missing a LICENSE file. Per RISC-V guidelines, documentation should be licensed CC-BY-4.0.

I propose adding a plain text LICENSE file like the one in the ISA manual project. This enables GitHub to automatically find it and recognize it.

I'm happy to add this into the project directly and will do so in the coming days. If anyone has concerns, please raise them.

Thanks,
-Jeff

In riscv-spec-v2.2,I see the usage of lw and sw:

l{b|h|w|d} rd, symbol           auipc rd, symbol[31:12]                                  Load global
                                           l{b|h|w|d} rd, symbol[11:0](rd)        
                              
s{b|h|w|d} rd, symbol, rt      auipc rt, symbol[31:12]                                   Store global
                                           s{b|h|w|d} rd, symbol[11:0](rt)

Can sw pseudoinstruction store the value of rd directly into a label instead of using rt?I want to be like this:

sw      x2, result 
...
result:
          .dword -1

I just wonder why there're symbol, rt and symbol[11:0](rt) instead of without rt.

I have a question about a line in riscv-asm-manual, what does .option | {rvc,norvc,pic,nopic,push,pop} | RISC-V options mean? and any documents about rvc, norvc, pic, nopic, push, pop?

The listing in this manual indicates that .half, .word, .dword imply alignment. I'm not seeing that behaviour in the current GNU assembler (i.e. .byte followed by .word results in the .word value being unaligned).

Is this a documentation bug or an assembler bug? It looks like LLVM's MC layer doesn't interpret .word etc as implying alignment on any current target, so the current gas behaviour is trivial to support, while I'd need to do a little more implementation work if .word and friends are naturally aligned.

[Sidenote: It looks like the GNU assembler accepts .short, .hword, .long and .quad in addition to the data directives listed here.]

I've seen this example:
https://github.com/riscv/riscv-asm-manual/blob/master/riscv-asm.md#constants

Whether the function of "puts" here is displaying string "Hello World\n"?I tried to build the program,but there seems no displaying.This example should work with UART?

Hi
c.addi should be nzimm (non zero imm), but when i use objdump to diassemble, i saw -16.

b: file format elf32-littleriscv

Disassembly of section .text:

00010074 :
10074: 1141 addi sp,sp,-16

Why?

Thanks
Peter

The examples shown for the LA and LI insructions only work for RV32.
For RV64, any address at an offset of > +/-2GB won't work with the example shown.
The LI case has the same issue, as does the absolute addressing example (though the LI example does mention it is for an RV32i)

In the section "A listing of standard RISC-V pseudoinstructions" the descriptions for call and tail specify x6. Should be x1?

I know that %hi(symbol) will get the high 20 bits of the symbols' address and then be as a immediate number in RISC-V 32. In short, take the [31:12] bits in RISC-V 32.

But in RISC-V 64, will it get the [31:12] bits, or just get the [63:44] bits?

Thanks for your help.

Following is a duplicate of @jrtc27's proposal from riscv/riscv-isa-manual#539.

This is useful for cases where compilers and/or assembly writers want to force the use of a GOT. For example, this could be used to address [1], but more generally it's a useful thing to have, and is a strange hole in the set of pseudoinstructions provided.

Whilst here, alter the description of "la" to not mention absolute. All addresses are absolute, but highlighting it for "la" specifically is confusing as it potentially implies that it's using an absolute lui/addi sequence rather than a PC-relative sequence.

[1] riscv-non-isa/riscv-elf-psabi-doc#126

I have not yet created patches against riscv-asm-manual and riscv-elf-psabi-doc. However, those are already outdated and only mention la without lla. Defining lga will also make it far less confusing to fix that; then, lla and lga can be documented individually, with la simply saying it's equivalent to the relevant one depending on -fPIC.

Hi
What is "-0xc0" means? and where i can find this information in elf?

Disassembly of section .text:

08000240 <__clz_tab-0xc0>:
 8000240:       500a                    0x500a
 8000242:       6f72                    flw     ft10,28(sp)
 8000244:       6d617267                0x6d617267
 8000248:       6820                    flw     fs0,80(s0)

I found the symbol clz_tab, but it should start in 0x8000300, but not 0x8000240

 101: 08000300   256 OBJECT  GLOBAL HIDDEN     3 __clz_tab

thanks
Peter

Currently, the requirement of zicsr for z*inx extensions is not enforced. Hence it will not be able to manipulate the floating point environment with z*inx if zicsr is not enabled.

I'm copying @asb's old issue here riscv/riscv-isa-manual#118

The current GNU tools accept sfence.vma and sfence.vma $rs1 as well as the usual sfence.vma $rs1, $rs2. It's useful for tool authors to know this form exists, and table 20.2 lists a number of pseudoinstruction forms (e.g. fence as shorthand for fence iorw, iorw).

The abbreviated sfence.vma forms aren't documented anywhere currently. Unfortunately it's not clear where that documentation should go, given that table 20.2 is part of the user-level ISA spec and sfence.vma is introduced only in the privileged spec.

hi
i am unable to stop relaxation using gnu gas

.option norelax
.section .text
.globl _start
label1:
_start:
	c.beqz	x8,label1
	c.beqz	x8,label2
lebal2:

riscv64-unknown-elf-as -march=rv32ifdc $? -o $@

output:

00000000 <_start>:
   0:   c001                    beqz    s0,0 <_start>
   2:   00041463           bnez    s0,a <lebal2>
   6:   ffbff06f                j       0 <_start>

Please help, why jump up (to label1) is ok, but jump down to label2 still has relaxation?

thanks
Peter

I might be doing this math wrong, but I think that maybe the "Load Immediate" example should use 0x33 as its LUI immediate instead of 0x32:

0000000000000000 <_start>:
   0:	00033537          	lui	    a0,0x33
   4:	bfb50513          	addi	a0,a0,-1029
   8:	00e51513          	slli	a0,a0,0xe
   c:	abe50513          	addi	a0,a0,-1346

Instead of:

0000000000000000 <_start>:
   0:	00032537          	lui	    a0,0x32
   4:	bfb50513          	addi	a0,a0,-1029
   8:	00e51513          	slli	a0,a0,0xe
   c:	abe50513          	addi	a0,a0,-1346

When I do the math with 0x32, I get 0xC6FEBABE, and I get the same result when I run ( ( ( ( 0x32 << 12 ) - 1029 ) << 0xE ) - 1346 ) in Python. But it's possible that I am misunderstanding how the sign-extension or LUI instruction works. Sorry that I can't verify this with an objdump, but this is what I get when I build the corresponding test code with GCC:

00000000 <_start>:
   0:	cafec537          	lui	a0,0xcafec
   4:	abe50513          	addi	a0,a0,-1346 # cafebabe <CONSTANT+0x0>

(Compiled with: riscv32-unknown-elf-gcc -x assembler-with-cpp -c -march=rv32i -o0 test.S -o test

Also, presented without judgement: I've gotten a few odd looks today for having CAFEBABE scribbled all over my notes when people come by to talk. Is it possible that something like FEEDFACE or DEC0FFEE might work just as well?

Discussion on riscv/riscv-isa-manual#740 concerned the following behaviors from the GNU assembler:

addi x0, x0, 0x800              # assembler error (illegal operand)
addi x0, x0, 0xfffff800         # assembles (immediate -2048) on RV32I but errors on RV64I
addi x0, x0, 0xfffffffffffff800 # assembles (immediate -2048) on both RV32I and RV64I

Can we explain this behavior? I'm happy to make a PR, but I'm not sure I fully understand the language rules myself.

The first case is apparently rejected because the GNU assembler constant syntax interprets 0x800 as 2048, which is outside the range of addi's immediate, a 12-bit signed integer, [-2048, 2047]. This behavior is arguably counterintuitive because 0x800 is a valid 12-bit imm field in an I-type instruction like addi. I think it's worth documenting this behavior (if it isn't already).

The second and third cases (and their decimal versions) are a bit more surprising.

The manual has an Instruction Set section but under Instructions there is no link to the instruction set manual. Instead there is some placeholder text that mentions the instruction manual link could be added.

where the RISC-V Assembly Programmer’s Manual?

Hi
When compile

.equ RTC_BASE,      0x40000000
.equ TIMER_BASE,    0x40004000

# setup machine trap vector
1:      auipc   t0, %pcrel_hi(mtvec)        # load mtvec(hi)
        addi    t0, t0, %pcrel_lo(1b)       # load mtvec(lo)
        csrrw   zero, mtvec, t0

# set mstatus.MIE=1 (enable M mode interrupt)
        li      t0, 8
        csrrs   zero, mstatus, t0

# set mie.MTIE=1 (enable M mode timer interrupts)
        li      t0, 128
        csrrs   zero, mie, t0

# read from mtime
        li      a0, RTC_BASE
        ld      a1, 0(a0)

# write to mtimecmp
        li      a0, TIMER_BASE
        li      t0, 1000000000
        add     a1, a1, t0
        sd      a1, 0(a0)

# loop
loop:
        wfi
        j loop

# break on interrupt
mtvec:
        csrrc  t0, mcause, zero
        bgez t0, fail       # interrupt causes are less than zero
        slli t0, t0, 1      # shift off high bit
        srli t0, t0, 1
        li t1, 7            # check this is an m_timer interrupt
        bne t0, t1, fail
        j pass

pass:
        la a0, pass_msg
        jal puts
        j shutdown

fail:
        la a0, fail_msg
        jal puts
        j shutdown

.section .rodata

pass_msg:
        .string "PASS\n"

fail_msg:
        .string "FAIL\n"

I got:

riscv-none-embed-as -march=rv32imac -mabi=ilp32 a.s -o a.o
a.s: Assembler messages:
a.s: Warning: end of file not at end of a line; newline inserted
a.s:19: Error: unrecognized opcode `ld a1,a0'
a.s:25: Error: unrecognized opcode `sd a1,0(a0)'
make: *** [a.elf] Error 1

Please help
Thanks