Jeffrey Bosboom jbosboom

RISC-V Vector Extension for Integer Workloads: An Informal Gap Analysis

Note: To verify my RVI membership and idenity on this otherwise semi anonymous account: I'm Olaf Bernstein, you should be able to view my sig-vector profile, if you are a member of the vector SIG.

The goal of this document is to explore gaps in the current RISC-V Vector extensions (standard V, Zvbb, Zvbc, Zvkg, Zvkn, Zvks), and suggest instructions to fill these gaps. My focus lies on application class processors, with the expectation that suggested instructions would be suitable to become mandatory or optional instructions in future profiles.

I'll assume you are already familiar with RVV, if not, here is a great introduction and here the latest RISC-V ISA manual.

ARM’s Scalable Vector Extensions: A Critical Look at SVE2 For Integer Workloads

Scalable Vector Extensions (SVE) is ARM’s latest SIMD extension to their instruction set, which was announced back in 2016. A follow-up SVE2 extension was announced in 2019, designed to incorporate all functionality from ARM’s current primary SIMD extension, NEON (aka ASIMD).

Despite being announced 5 years ago, there is currently no generally available CPU which supports any form of SVE (which excludes the [Fugaku supercomputer](https://www.fujitsu.com/global/about/innovation/

As tested on Linux:

An SCM_RIGHTS ancillary message is "attached" to the range of data bytes sent in the same sendmsg() call.
However, as always, recvmsg() calls on the receiving end don't necessarily map 1:1 to sendmsg() calls. Messages can be coalesced or split.
The recvmsg() call that receives the first byte of the ancillary message's byte range also receives the ancillary message itself.
To prevent multiple ancillary messages being delivered

	# Trying to use the following command and recieving:
	# Error: GDBus.Error:System.Error.ENXIO: No such device or address

	# StartTransientUnit(in s arg_0,
	# in s arg_1,
	# in a(sv) arg_2,
	# in a(sa(sv)) arg_3,
	# out o arg_4);

	gdbus call \