riscvarchive

riscv-v-spec

Assembly2018–2024

riscvarchive / riscv-v-spec · Archived

riscv-v-spec

Working draft of the proposed RISC-V V vector extension

Hardware & Embedded

Explore on GitHub Read Hacker News discussions

20Distinct people

24Mentions

0Explicit recommenders

1.1KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Working draft of the proposed RISC-V V vector extension

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

riscv/riscv-bitmanip · linked in 2 of the same discussions
riscv/riscv-crypto · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

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: 2018-11-20 21:16:46 UTC to 2024-06-30 14:54:41 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	0	1
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	4	0	4
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	4	1	3
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	8	1	7
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	3	0	3
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	4	1	3

What Hacker News says

24 sources

fellowmartian·Jun 30, 2024

Alright, Allwinner D1 - still requires vendor-provided components for almost everything, and its pre-ratified vector extension[1] required special compilers until very recently. [1] https://github.com/riscv/riscv-v-spec/issues/667

In Milk-V Reveals Technical Specs of Milk-V Jupiter RISC-V Mini-ITX PC

brucehoult·Mar 17, 2024

https://github.com/riscv/riscv-v-spec/commit/6f702a213f29520... The github is never the place to find ratified specs. It was used for the working draft of 1.0, and will be used for the working draft of 2.0. There have already been dozens of commits there post-ratification, mostly clarifications or corrections to the documentation, but in future there will be new functionality.

In Working draft of the proposed RISC-V V vector extension

tosh·Mar 16, 2024Submission

Working draft of the proposed RISC-V V vector extension

1 points · Open discussion

camel-cdr·Mar 4, 2024

Edit: sorry I missread, I though you were just interested in the vector extension (SIMD) for the genral assembly there isn't mutch to learn tbh, look at the isa reference card and maybe also look at the B (bit manipulation) extension: https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/... --- Here are some resources on RVV I can recommend: RVV spec (also look at the examples in the repo): https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado... RVV intrinsics viewer: https://dzaima.github.io/intrinsics-viewer Tutorial: RISC-V Vector Extension Demystified (3 hour video going over every instruction): https://youtu.be/oTaOd8qr53U RISC-V Vector extension in a nutshell: https://fprox.substack.com/p/risc-v-vector-extension-in-a-nu... If you want to see a more complex example/real world application, then you might also be intere

Read the rest

sted in my article about vectorizing unicode conversions: https://camel-cdr.github.io/rvv-bench-results/articles/vecto... In terms of development I'd recommend using qemu and a cross compiler, or if you want hardware try to get the kendryte k230 (currently the only sbc with rvv 1.0 support) or wait a bit for better hardware (BPI-F3 and sg2380 should release this year).

In Scaleway launches RISC-V servers

camel-cdr·Dec 25, 2023

> what do you even pass to vsetvl in this case as you don’t know your string length. To the maximum, of course, `vsetvl x<not 0>, x0, ...` will do that for you. You might read over a page boundery, but there is an instruction for that `vle8ff.v`, it's a fault-only-first uni-stride load. That is, it doesn't fault when one of the later elements goes outside our page, and adjusts the vector length accordingly. [0] > With the various simd extensions on x86 or arm, such a routine could be carefully written to align with cache lines and so avoid depending on reading the next line when the string ends before it. In practice, on current very early hardware, doing just that is faster, and definitely possible. [1] > I also worry about various simd tricks that seem to rely on the width. Eg I think there’s some instruction to interpret each half-byte

Read the rest

of one vector as an index into some vector of 16 things I'm not aware of such an instruction, but rvv has vrgather.vv and vrgatherei16.vv to do something similar. Note that you can always return to "fixed-size" implementations if you really need to, buy just setting the vl accordingly. But for the most part I don't think this will be necessary. Do you have any specific problem in mind that may seem hard to do without fixed size SIMD? > I guess part of my thinking here is that the ISA designers at intel, arm, aren’t stupid, but they ended up with fixed widths for sse, neon, knights landing, avx, avx-512. I mean, ARM now has something similar with SVE, and x86 has a metric ton of legacy to work with and the market size to get adoption of whatever new instruction prefix they add. Edit: Also, didn't AVX10/AVX512vl go into a similar direction as SVE? > Is there something reasonable written about why risc-v went with this design. I'm not quite sure, but I remember that it was one thing from very early in the design. I think it's to have a mostly unified ecosystem for the binary app market. It also makes working with mixed precision easier, because it allows for the LMUL model. But RISC-V is extendable, the P (Packed SIMD) extension is currently in the works and aimed at the embedded market, for in GPR SIMD operations for DSP type applications. [2] [0] https://github.com/riscv/riscv-v-spec/blob/master/example/st... [1] https://camel-cdr.github.io/rvv-bench-results/canmv_k230/str... [2] https://lists.riscv.org/g/tech-p-ext/topics

In Cray-1 vs Raspberry Pi

camel-cdr·Aug 13, 2023

The bit manipulation [0] extension has been ratified for a while now and is part of the RVA22 application extension profile [1]. You can already buy SOCs that support it, e.g. vision five 2 and star64. Interestingly the risc-v vector extension [2] has it's own popcount instructions for vector registers/register masks. This is needed, because the scalable architecture doesn't guarantee that a vector mask can fit into a 64 bit register, so vector masks are stored in a single LMUL=1 register. This works really well, because with LMUL=8 and SEW=8 you get 100% utilization of the single LMUL=1 vector register. Another interesting thing is that the vector crypto extension will likely introduce a element wise popcount instruction [3]. [0] https://github.com/riscv/riscv-bitmanip [1] https://github.com/riscv/riscv-profiles [2] https://github.com/ri

Read the rest

scv/riscv-v-spec [3] https://github.com/riscv/riscv-crypto/blob/master/doc/vector...

In Popcount CPU instruction (2019)

cbm-vic-20·Jul 23, 2023

I thought I had read somewhere that the Packed SIMD (P) extension was still going to be developed for implementations that don't need the full-blown Vector (V) extension, for example, embedded processors for digital signal processing. https://github.com/riscv/riscv-p-spec/ https://github.com/riscv/riscv-v-spec/

In riscv64 is now an official Debian architecture (rebootstrap in progress)

zozbot234·Dec 17, 2022

It's not "unusual"; using data registers for mask is a valid tradeoff especially for low-end implementations, whereas higher-end architectures can easily use shadow registers. Discussed in depth at https://github.com/riscv/riscv-v-spec/issues/811

In Fallacies about RISC-V

sparkie·Nov 16, 2022

The number of instructions is already becoming quite large if you consider the V and P extensions. Here's the vector instructions: https://github.com/riscv/riscv-v-spec/blob/master/inst-table... The set of RISC-V features that each CPU supports is going to be so widely varied that you will need dozens of compiler switches to make full use any processor, and since most software will be compiled for the lowest-common-denominator, some capabilities will go largely unused. This is already the case with x86 with AVX-512, the full capabilities are only leveraged in specific workloads. Either that or developers are going to rethink the way they distribute software. No longer as compiled binaries, but as an IR which is then compiled on each processor, since the best way to learn what features are supported by any CPU is to query them on it.

In RISC-V: The Last ISA?

sitkack·Jul 25, 2022

I think SIMD was a distraction to our conversation, most code doesn't use it and in the future the length agnostic, flexible vectors; https://github.com/WebAssembly/flexible-vectors/blob/master/... are a better solution. They are a lot like RVV; https://github.com/riscv/riscv-v-spec, research around vector processing is why RISC-V exists in the first place! I was trying to find the smallest Rust Wasm interpreters I could find, I should have read the source first, I only really use wasmtime, but this one looks very interesting, zero deps, zero unsafe. 16.5kloc of Rust https://github.com/rhysd/wain The most complete wasm env for small devices is wasm3 20kloc of C https://github.com/wasm3/wasm3 I get what you are saying as to be so small that there isn't a place of bugs to hide. > “There are two ways of constructing a software design: One w

Read the rest

ay is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” CAR Hoare Even a 100 line program can't be guaranteed to be free of bugs. These programs need embedded tests to ensure that the layer below them is functioning as intended. They cannot and should not run open loop. Speaking of 300+ reimplementations, I am sure that RISC-V has already exceeded that. The smallest readable implementation is like 200 lines of code; https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/... I don't think Wasm suffers from the base extension issue you bring up. It will get larger, but 1.0 has the right algebraic properties to be useful forever. Wasm does require an environment, for archival purposes that environment should be written in Wasm, with api for instantiating more envs passed into the first env. There are two solutions to the Wasm generating and calling Wasm problem. First would be a trampoline, where one returns Wasm from the first Wasm program which is then re-instantiated by the outer env. The other would be to pass in the api to create new Wasm envs over existing memory buffers. See, https://copy.sh/v86/ MS-DOS, NES or C64 are useful for archival purposes because they are dead, frozen in time along with a large corpus of software. But there is a ton of complexity in implementing those systems with enough fidelity to run software. Lua, Typed Assembly; https://en.wikipedia.org/wiki/Typed_assembly_language and Sector Lisp; https://github.com/jart/sectorlisp seem to have the right minimalism and compactness for archival purposes. Maybe it is sectorlisp+rv32+wasm. If there are directions you would like Wasm to go, I really recommend attending the Wasm CG meetings. https://github.com/WebAssembly/meetings When it comes to an archival system, I'd like it to be able to run anything from an era, not just specially crafted binaries. I think Wasm meets that goal. https://gist.github.com/dabeaz/7d8838b54dba5006c58a40fc28da9...

In Take more screenshots

gchadwick·Jul 11, 2022

Also worth reading this issue: https://github.com/riscv/riscv-v-spec/issues/617 I think it's a fascinating discussion. There's been some disquiet at this design choice amongst a minority for a while from what I can tell. Who will be proven right? Perhaps this will be one of the warts of RISC-V we're looking back at 10 years from now wishing it had been dealt with better. Perhaps instead it'll prove to be a sound design decision. All the established ISAs have various warts that make hardware implementation a pain or compiler writing harder than it should be. The decision making for those and their genesis has all been behind closed doors. Are we seeing a similar misstep now happen in the open?

In Concerns over mask register design in RISC-V Vector Extension v1.0

gchadwick·Jul 11, 2022Submission

Concerns over mask register design in RISC-V Vector Extension v1.0

1 points · Open discussion

AlbertoGP·Jul 11, 2022

That’s a great link, specially the (at the moment) single reply which gives some background about why it was done this way, and how it makes sense. Just scroll a bit down to read it: https://github.com/riscv/riscv-v-spec/issues/811#issuecommen... I don’t know much about this, I’m a programmer, but the explanation makes sense to me.

In The Problem with RISC-V V Mask Bits

dogleash·Jul 11, 2022

https://github.com/riscv/riscv-v-spec/issues/811 linked in the article.

In The Problem with RISC-V V Mask Bits

fyrn-·Jul 11, 2022

Github issue tracking this comment: https://github.com/riscv/riscv-v-spec/issues/811

In The Problem with RISC-V V Mask Bits

Showing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.