Comment by sylware | Hacker News Reader

Comment by sylware | Hacker News Reader

RISC-V moving forwards. Transition will be hard, and will be costly: large RISC-V implementations on latest silicon process (for server/mobile/desktop).

I wish it to be successful. Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there.

They have to be very careful about what they put in RVxx profiles: advanced application developers know already they will have to query the hardware in order to install proper (this must not be part of any file format to avoid toxic complexity: it must stay in full control of the application) machine code.

Currently I do personally code my "core" RISC-V own little applications, which I do interpret on x86_64/linux and using another executable file format than elf (of my own) but with transparent binary compatibility (aka no need to patch the kernel).

And guess what, to be not dependent on those horrible compilers like gcc/clang or ultra complex syntax languages (all full of planned obsolesence even on the medium run), or those completely PI locked hardware ISAs... is just a breeze of fresh air.

Ofc, this is a compromise as it is impossible to run a reasonable (interpretation may vary a LOT here) linux desktop without some of the worst software or dependency out there... but this is moving forwards, and it feels good.

> Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there.

RISC-V is not byte code though, it was not designed for efficient execution by a software interpreter.

And by what metric would it be less toxic than any higher level computer language out there?

Is my english that bad or this is an AI bot?

Your comment above seems pretty incoherent and I didn't understand much of it. There is no sign of AI bots.

I don't have an army of AI bots to support obviously incoherent and significant experience lacking many posts (i.e. missing the point from light years away).

https://en.wikipedia.org/wiki/Bytecode

> 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.

> RISC-V is not byte code though

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:/#

[2] https://github.com/LekKit/RVVM

https://en.wikipedia.org/wiki/Bytecode

> 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 agree that bytecode is different from machine code, but "efficient execution by a software interpreter" seems like a bad delineation considering that some virtual machines treat bytecode as simply an intermediate representation for JIT. WASM bytecode is very similar to machine code and meant to be translated to machine code rather than interpreted.

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.

Reply on news.ycombinator.com