https://bellard.org/tinyemu/readme.txt :

> 4.1) 128 bit support

> The RISC-V specification does not define all the instruction encodings for the 128 bit integer and floating point operations. The missing ones were interpolated from the 32 and 64 ones.

> Unfortunately there is no RISC-V 128 bit toolchain nor OS now (volunteers for the Linux port ?), so rv128test.bin may be the first 128 bit code for RISC-V !

lol, that's a brave approach.

Although with my pedant hat on: that's extrapolation, not interpolation. That's because 128 is outside of the existing range.

See also "selfie": http://selfie.cs.uni-salzburg.at/

> An educational software system of a tiny self-compiling C compiler, a tiny self-executing RISC-V emulator, and a tiny self-hosting RISC-V hypervisor.

> Selfie is a project of the Computational Systems Group at the Department of Computer Sciences of the University of Salzburg in Austria.

To the risc-v folks: I am looking for a mini-board with a 64bits RISC-V core, USB-C (power+data), many(~30) available GPIOs, easy to flash or boot from a memory card. That for a keyboard firmware directly written in 64bits risc-v assembly.

The BL808 is actually a 32bits risc-v as a main core with a 64bits risc-v core on the side (convoluted hardware programming from the 64bits risc-v core).

The K210 does not seem to have a USB controller (only a UART<->USB dongle).

Then I am lurking on some mango boards, with a D1, the D1 being completely overkill.

Anything else?

The soon to be released VisionFive 2 board seems like a good match https://www.starfivetech.com/en/site/boards

Recent discussion: https://news.ycombinator.com/item?id=34339752

Super-early bird are out! If shipping is good.

I haven't been able to boot mine. But I have no UART adapter to see whats wrong.

That's significantly more overkill than the D1.

The D1 based miniboards seem to be the currently only alternative for what I would like to do. Only the mango pi board I guess, or any others?

I could not confirm if the k210 has a usb controller (not the UART<->USB dongle).

See the list of boards part of the D1 article[0] in linux-sunxi wiki. There are at least 5 options listed.

Lichee RV (with a breakout dock board) is the one I have.

https://linux-sunxi.org/D1

Thanks for the page. I guess I would have to go for the mangopi: usb-c device/power port and the GPIOs.

I'm still not 100% sure what exactly this is, even after reading the description thrice. Is it basically a RISC-V core in a system with standard x86 PC peripherals, i.e. a very odd but theoretically possible configuration to emulate, in the same way that QEMU (of the same author) lets you attach e.g. a classic VGA controller to an ARM core?

My reading is that it emulates either x86 or RISC-V CPU and can emulate various real x86 peripherals but it also includes the abstract VirtIO services for ... both?

I assume the RISC-V emulation is all VirtIO based and not real...

I think it’s both a a RISCV emulator and an x86 emulator. I think it’s both, presumably reusing some pieces allowing systems to be emulated like you say with weird configurations.

The riscv system is emulated in software whereas the x86 system is virtualized using kvm.

Nice!

The B extension never gets any love.

The RISC-V crowd hates bitwise anything.

B extension was ratified in 2021, near the end.

It is considerably newer than every extension this emulator implements, and thus reasonable it'd have these and not B.

Here's the ratified spec[1]. And some class slides[2]. And a list of other recent extensions[3].

[1] https://github.com/riscv/riscv-bitmanip/releases/download/1.... from https://github.com/riscv/riscv-bitmanip/releases . [2] https://courses.cs.washington.edu/courses/cse481a/20sp/notes... [3] https://wiki.riscv.org/display/HOME/Recently+Ratified+Extens...

Hopefully B becomes ubiquitous in the next generation of SoC's, or RISC-V is going to look bad in any benchmarks that happen to have a popcnt in the hot path.

I worry a bit that B is too ambitious with many instructions that no one is using yet which are difficult to prove their value as a result, while regular RISC-V is essentially hobbled compared to ordinary cpus due to the absence of popcnt/clz.

Most implementations announced recently (e.g. in RISC-V Summit last December) have B.

Even the newer revisions of cores that have been available for a while (like SiFive U74) have been updated with B support.

As such, I believe it to be a non-issue. Hardware simply takes time.

>which are difficult to prove their value as a result,

As with any RISC-V extensions, each instruction had to meet many criteria to be allowed in there.

Rationale accompany the instructions in the documentation.

> Most implementations announced recently (e.g. in RISC-V Summit last December) have B.

That's fantastic.

> Rationale accompany the instructions in the documentation.

I've read it-- I didn't personally need it to be convinced, but I'm surprised it convinced vendors. Glad to hear that it has.

At least Zba, Zbb and Zbs are in RVA22 iirc.

edit: Zbs.

Ah, you're right: https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

That's good to see. (Boy, it's really hard to find info about RISC-V profiles on Google. It just seems to ignore all the letters and numbers.)

Zbc (carryless multiply) seems to be needed to implement AES-GCM

It is required in Zkn (Scalar Crypto NIST Algorithms) and Zks (Scalar Crypto ShangMi Algorithms).

>Hopefully B becomes ubiquitous in the next generation of SoC's

Hopefully together with V.

B instructions are also recognized by the GNU bunutils assembler.