It is if a byte is 16 bits.

> it was not designed for efficient execution by a software interpreter.

It's not bad at all for that. On my i9-13900HX laptop, if I take http://hoult.org/primes.txt and compile it for x86 and for RISC-V:

- 5.6 seconds for riscv64-linux-gnu-gcc -O primes.c -o prime run in QEMU [1]

- 3.8 seconds for gcc primes.c -o primes run natively

- 2.0 seconds for gcc -O primes.c -o primes run natively

Emulating RISC-V is worse than forgetting to compile with `-O`, but not much. It's far faster than Python or Ruby and comparable to Java, C#, JavaScript, or WebASM.

Also, QEMU is not the fastest emulator around, just the most flexible and complete. The experimental RV8 and the nearly-ready-for-prime-time RVVM [2] are much closer to native speeds.

Note that if I do exactly the same thing for arm64 (i.e. docker/QEMU) the primes program takes 14.4 seconds and the whole Ubuntu in docker experience just feels a lot more laggy. Running the x86_864 binary in qemu-x86_64 instead of natively takes 10.5 seconds.

RISC-V is a lot easier to emulate quickly than Aarch64 or x86.

[1] or if you have Docker Desktop (on Mac, Windows, or Linux) then you can just work like a native:

    bruce@i9:~$ docker run --platform linux/riscv64 -it riscv64/ubuntu
    Unable to find image 'riscv64/ubuntu:latest' locally
    latest: Pulling from riscv64/ubuntu
    53300d777b1a: Pull complete 
    Digest: sha256:6a392b2c64f4e0021bfcff62e58975ddce0f1eccc5a72708b114aeb50999ff22
    Status: Downloaded newer image for riscv64/ubuntu:latest
    root@5f2edc942403:/# apt update
    :
    root@5f2edc942403:/# apt install wget gcc
    :
    root@5f2edc942403:/# wget -q http://hoult.org/primes.txt
    root@5f2edc942403:/# mv primes.txt primes.c
    root@5f2edc942403:/# gcc -O primes.c -o primes
    root@5f2edc942403:/# ./primes
    Starting run
    3713160 primes found in 5609 ms
    216 bytes of code in countPrimes()
    root@5f2edc942403:/# 

> Bytecode (also called portable code or p-code) is a form of instruction set designed for efficient execution by a software interpreter.

It's not Bytecode.

I would define bytecode as:

- Closer to machine operations than something like an AST, which is where I think the "efficient execution" part of the wikipedia definition came from

- Not directly executable on any physical CPU, or at least not typically. There are some CPUs that can execute Java/Python bytecode (sort of) but they're in the minority.

While not strictly required, bytecode tends to have opcodes meant to be used with a virtual machine, such as dealing with objects instead of linear memory.

This is all to say, the proper terminology for RISC-V is an ISA, but the distinction is more about how it's being used than how it's designed.

> Bytecode (also called portable code or p-code) is a form of instruction set designed for efficient execution by a software interpreter.

It's not bytecode.