CAcamel-cdr·Aug 15, 2026
In RISC-V: They Should Have Known Betterriscv
riscv-isa-manual
TeX2017–2026
riscv / riscv-isa-manual
riscv-isa-manual
RISC-V Instruction Set Manual
17Distinct people
24Mentions
0Explicit recommenders
4.9KGitHub stars
What to know before exploring
What it is
RISC-V Instruction Set Manual
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year24 dated mentions
Observed mentions: 2017-06-26 11:22:35 UTC to 2026-08-15 09:27:15 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
24 sources> E.g. you fetch 66 bytes instead of 64
Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.
> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.
This is very hard to quantify.
> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
I've liked the back and forth slides bellow.
Though I want to bring up to things regrading the Qualcomm slides:
> [RVC] Performance benefit is modest
> • Best case: 2-3% speedup
I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.
I also have no idea how they got those numbers. (not that they a
Read the rest
re wildly implausible, it's just not transparent)
> Improving Android Code Size
In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.
I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...
[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...
[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...
[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...
- Handling of misaligned loads/stores: RISC-V got itself into a weird middle ground, ops on misaligned pointers may work fine, may work "extremely slow", or cause fatal exceptions (yes, I know about Zicclsm, it's extremely new and only helps with the latter, also see https://github.com/llvm/llvm-project/issues/110454). Other platforms either guarantee "reasonable" performance for such operations, or forbid misaligned access with "aligned" loads/stores and provide separate misaligned instructions. Arguably, RISC-V should've done the latter (with misaligned instructions defined in a separate higher-end extension), since passing unaligned pointer into an aligned instruction signals correctness problems in software.
- The hardcoded page size. 4 KiB is a good default for RV32, but arguably a huge missed opportunity for RV64.
- The weird restri
Read the rest
ction in the forward progress guarantees for LR/SC sequences, which forces compilers to compile `compare_exchange` and `compare_exchange_weak` in the absolutely same way. See this issue for more information: https://github.com/riscv/riscv-isa-manual/issues/2047
- The `seed` CSR: it does not provide a good quality entropy (i.e. after you accumulated 256 bits of output, it may contain only 128 bits of randomness). You have to use a CSPRNG on top of it for any sensitive applications. Doing so may be inefficient and will bloat binary size (remember, the relaxed requirement was introduced for "low-powered" devices). Also, software developers may make mistake in this area (not everyone is a security expert). Similar alternatives like RDRAND (x86) and RNDR (ARM) guarantee proper randomness and we can use their output directly for cryptographic keys with very small code footprint.
- Extensions do not form hierarchies: it looks like the AVX-512 situation once again, but worse. Profiles help, but it's not a hierarchy, but a "packet". Also, there are annoyances like Zbkb not being a proper subset of Zbb.
- Detection of available extensions: we usually have to rely on OS to query available extensions since the `misa` register is accessible only in machine mode. This makes detection quite annoying for "universal" libraries which intend to support various OSes and embedded targets. The CPUID instruction (x86) is ideal in this regard. I totally disagree with the virtualization argument against it, nothing prevents VM from intercepting the read, no one excepts huge performance from such reads.
And this list is compiled after a pretty surface-level dive into the RISC-V spec. I heard about other issues (e.g. being unable to port tricky SIMD code to the V extension or underspecification around memory coherence important for writing drivers), but I can not confidently talk about those, so it's not part of my list.
P.S.: I would be interested to hear about other people gripes with RISC-V.
e.g. this is the guarantee in RISC-V: https://github.com/riscv/riscv-isa-manual/blob/70040578316b9...
In Solving the ABA Problem in Rust with Tagged PointersThere is ongoing work in addressing this.
For one, all of the specs are getting merged into a unified isa-manual, you can get the latest version from github: https://github.com/riscv/riscv-isa-manual/releases
The other project is the riscv-unified-db: https://github.com/riscv-software-src/riscv-unified-db
The goal is that this database will hold all specification information in a machine readable format.
That allows you to e.g. generate a manual for RVA22 including the ISA specifications: https://riscv-software-src.github.io/riscv-unified-db/pdfs/R...
Or a website were you can search for instructions, and get all of the relevant information about it: https://riscv-software-src.github.io/riscv-unified-db/exampl...
The above two links are still WIP, so there are still a lot of things missing.
In Memory64I'm porting a small C compiler to 64-bit RISC-V and just learned a quirk that uint32_t is represented in-register as sign extended to 64-bit. Without Zba extension the compiler has to insert a bit-clearing sequence every time the value is used for operations that cannot be agnostic in two's complement. The quirk has enough impact on benchmark scores, SiFive typedef'ed an u32 type to i32 in their Coremark repo[1]. The Coremark team later updated their rule to address this trick[2].
[1] https://github.com/sifive/benchmark-coremark/blob/4486de1f0a...
[2] https://github.com/riscv/riscv-isa-manual/issues/353
In RISC-V is currently slow compared to modern CPUsI totally get why you'd want mem-to-mem instructions, it just seemed more interesting in a blitting context (and others) to have the operation not be static but rather register-based. But perhaps in practice it matters not, been a long time since I wrote blitting code.
RISC-V already has what you want in terms of R-type instructions[1], ie "dest = src1 op src2" where "op" is effectively an immediate value, but being based on a load-store architecture it's only register-to-register of course.
Though I suppose ISA-wise there's nothing in the way of making an extension that introduces "M-type instructions" which act like the R-type instructions but are mem-to-mem instead. How much that messes with everything else I have no idea.
edit: ah, forgot about you wanting it to behave like movsb. Still, something that could be handled by the extensio
Read the rest
n instruction.
[1]: https://github.com/riscv/riscv-isa-manual/releases/download/... (section 2.4.2)
The handling of misaligned loads/stores in RISC-V is also can be considered a disappointing point: https://github.com/riscv/riscv-isa-manual/issues/1611 It oozes with preferring convenience of hardware developers and "flexibility" over making practical guarantees needed by software developers. It looks like the MIPS patent on misaligned load/store instructions has played its negative role. The patent expired in 2019, but it seems we are stuck with the current status quo nevertheless.
In Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V> x86 gets those instructions very wrong while RISC-V gets them very right
That is heavy over-exaggeration.
> An old ADD instruction was 2 bytes.
By "old" you mean.. 32-bit adds with 8 registers to choose from. Which are gonna be the majority of 'int' adds. Unfortunately, 64-bit, and thus pointer, 'add's do indeed require 3 bytes, but then you get a selection of 16 registers, for which RISC-V will need 4-byte instructions, and on x86 a good number of such 'add's can be "inlined" into the consumer ModR/M. (ok, for 'add' specifically RISC-V does have a special-cased compressed instruction with full 5-bit register fields (albeit destination still same as a source), but the only other such instruction is 'mv'. At least x86 doesn't blatantly special-case the encoding of regular 'add' :) )
> nearly 30 incompatible SIMD extensions
30, perhaps, b
Read the rest
ut incompatible? They're all compatible, most depend on the previous (exceptions being AMD's one-off attempts at making their own extensions, and AVX-512 though Intel is solving this with AVX10) and routinely used together (with the note of potentially getting bad performance when mixing legacy-prefix and VEX-prefix instruction forms, but that's trivial to do, so much so that an assembler can upgrade the instructions for you).
RISC-V isn't cheaping out on vector extensions either - besides the dozen subsets/supersets of 'v' with different minimum VLEN and supported element types (..and also 'p', which I've still heard about being supported on some hardware despite being approximately dead), it has a dozen vector extensions already: Zvfh, Zvfhmin, Zvfbfwma, Zvfbfmin, Zvbb, Zvkb, Zvbc, Zvkg, Zvkned, Zvknhb, Zvknha, Zvksed, Zvksh
> massive "fill X registers from the stack"
https://github.com/riscv/riscv-isa-manual/blob/176d10ada5d8c...
Granted, that's optional (though, within a rounding error, all of RISC-V is) and meant primarily for embedded, but it still is a specified extension in the main RISC-V spec document.
Now, all that said, I'd still say that RISC-V is pretty meaningfully better than x86, but not anywhere near the amount you're saying.
The Improved RISC-V Specification (latest WIP draft)
https://github.com/riscv/riscv-isa-manual/releases
Regarding the recent "How to improve the RISC-V specification" post [0], I just wanted to point out, that the latest draft manual is already a great improvement. (see link above)
It includes a lot of the newly ratified extensions: bitmanip,zicond,vector,vector crypto, ...
And there are a bunch of included SAIL definitions for bitmanip and zicond, but other instructions are still missing the SAIL code. Most notably, the SAIL definitions from the RV32I/RV64I base isa are also missing.
I asked for the further SAIL integration plans here: https://github.com/riscv/riscv-isa-manual/issues/1369
This is an example SAIL snippet from cpopw:
let bitcount = 0;
let val = X(rs);
foreach (i from 0 to 31 in inc)
if val[i] == 0b1 then bitcount = bitcount + 1 else ();
X[rd] = bitcou
Read the rest
nt
Seems pretty readable to me.
For anybody who wants to look at the RISC-V manual, and has low stakes, I'd encourage using the latest draft. I'm not working on it my self, but I imagine opening an issue if you come across a mistake/uncertain definition/... would be appreciated.
[0] https://news.ycombinator.com/item?id=40185065
I tried searching the spec [1] for "overflow" and here is what it says at page 17:
> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.
> For general signed addition, three additional instructions after the addition are required
Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is one of the most often used instructions and they suggest that we should replace each instruction with four?
Their "rationale" is not rational at all. It doesn't make sense.
Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do n
Read the rest
ot want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. And CPU designers do not want to implement traps because no language needs them. As a result, there will be errors and vulnerabilities. A vicious circle.
What also surprises me is that they added fused add-multiply instruction which can easily be replaced by 2 separate instructions, is not really needed in most applications (like a web browser), and is difficult to implement (if I am not mistaken, you need to read 3 registers instead of 2, which might require additional ports in register file only for this useless instruction).
[1] https://github.com/riscv/riscv-isa-manual/releases/download/...
If you already understand assembly-language programming for some other ISA then you'll have no trouble following straight from the RISC-V reference manual:
https://github.com/riscv/riscv-isa-manual/releases/download/...
Plus recently ratified extensions:
https://wiki.riscv.org/display/HOME/Recently+Ratified+Extens...
In NASA selects SiFive and makes RISC-V the go-to ecosystem for future missionsRISC-V instructions longer than 32 bits are just a theoretical possibility at this point. An extension escape hatch for the future.
No one has done it, no one seems to be keen to be the first to do it, and even how the instruction length encodings work is not a ratified part of the spec -- it's just a proposal at the moment, even for the next step of 48 bit instructions.
There has been discussion of encodings better than the one proposed in the current spec, especially around instruction length encoding schemes that would make more opcode bits available in 80 bit instructions than in the scheme in the spec, so as to have a possibility of encoding 64 bit literals in an 80 bit instruction.
https://github.com/riscv/riscv-isa-manual/issues/280
In The x86 architecture is the weirdo, part 2https://github.com/riscv/riscv-isa-manual/issues/348 suggests that the RISC-V folks are going to address this in the spec at some point.
In VRoom A high end RISC-V implementationThis comes up a lot and I'm sympathetic to your plea, really (I enjoy fantasizing about a different reality where CPUs weren't just "machines to run C programs"), but in computer architecture, what really matters for one application or a class of applications might not be important when viewed across millions of programs.
The fact is that integer operations and floating point are two completely different beasts, so much so that we have different benchmark suites for each.
Integer operations are critically latency sensitive and bagging on extra semantics doesn't come for free and for most code this would be a tax. The "overflow bit" represents an implicit result that would have to be threaded around (I'm assuming that you aren't asking for exceptions which literally nobody wants). For FP we do that, but the cost and latency of FP ops is
Read the rest
already high so it doesn't hurt quite as much.
The RISC-V spec [1] (which I assume you have seen) already discusses all these trade offs:
"We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. Overflow checking for unsigned addition requires only a single additional branch instruction after the addition:
add t0, t1, t2
bltu t0, t1, overflow
For signed addition, if one operand’s sign is known, overflow checking requires only a single branch after the addition:
addi t0, t1, +imm
blt t0, t1, overflow
This covers the common case of addition with an immediate operand.
For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative.
add t0, t1, t2
slti t3, t2, 0
slt t4, t0, t1
bne t3, t4, overflow
In RV64I, checks of 32-bit signed additions can be optimized further by comparing the results of ADD and ADDW on the operands."
I do think that it might have been worth adding an single instruction version for the last one (excluding the branch), but I'm not aware of it getting accepted.
[1] https://github.com/riscv/riscv-isa-manual
Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.