riscv-non-isa / riscv-asm-manual Goto Github PK
View Code? Open in Web Editor NEWRISC-V Assembly Programmer's Manual
Home Page: https://jira.riscv.org/browse/RVG-4
License: Creative Commons Attribution 4.0 International
RISC-V Assembly Programmer's Manual
Home Page: https://jira.riscv.org/browse/RVG-4
License: Creative Commons Attribution 4.0 International
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
maybe the 1st one was stale.
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 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)
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
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
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:
SHF_EXECINSTR
section.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
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>
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.
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.
In the section "A listing of standard RISC-V pseudoinstructions" the descriptions for call and tail specify x6. Should be x1?
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.]
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
I would like to suggest two improvements to the table with pseudo instructions:
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.
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.
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.
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
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
Hi
We are trsting our RISC-V simulator, is there any very big assembly example code ?
thanks
Peter
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?
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
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.
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"?
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, 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'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?
(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.
To keep it simple, there are three criteria for this scheme:
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:
Important: The original ABI name of the register remains untouched and fully functional. Any new definition creates a synonym, not a replacement.
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.
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.
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
).
Before | After Expansion |
---|---|
C |
C + Zca |
C + F |
C + Zca + Zcf + F (RV32) |
C + F |
C + Zca + F (RV64) |
C + F + D |
C + Zca + Zcf + Zcd + F + D (RV32) |
C + F + D |
C + Zca + Zcd + F + D (RV64) |
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.
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).
.option norvc
.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.
.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?
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
It would be useful to have a section explaining how to run the code, possibly in the form of a "Getting Started" subsection.
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.
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.
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?
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?
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!
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
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
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?
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
hi,
why c.lwsp x0, 0x40(sp) will cause Error: illegal operands `c.lwsp x0,0x40(sp)'?
thanks
Peter
The manual lists signed loads, l{b|h|w|d} but not the unsigned variant, l{b|h|w}u. Suggest adding it.
where the RISC-V Assembly Programmer’s Manual?
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.
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
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.