3 ms·

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

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.

flanked-evergl 2y ago
> 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?
- sylware 2y ago
  Is my english that bad or this is an AI bot?
  - mkl 2y ago
    Your comment above seems pretty incoherent and I didn't understand much of it. There is no sign of AI bots.
    - sylware 2y ago
      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).
  - flanked-evergl 2y ago
    https://en.wikipedia.org/wiki/Bytecode 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.
- brucehoult 2y ago
  > 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 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://github.com/LekKit/RVVM
  - flanked-evergl 2y ago
    https://en.wikipedia.org/wiki/Bytecode 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.
    - e_y_ 2y ago
      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.

flanked-evergl 2y ago

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

sylware 2y ago
Is my english that bad or this is an AI bot?
- mkl 2y ago
  Your comment above seems pretty incoherent and I didn't understand much of it. There is no sign of AI bots.
  - sylware 2y ago
    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).
- flanked-evergl 2y ago
  https://en.wikipedia.org/wiki/Bytecode 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.
brucehoult 2y ago
> 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 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://github.com/LekKit/RVVM
- flanked-evergl 2y ago
  https://en.wikipedia.org/wiki/Bytecode 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.
  - e_y_ 2y ago
    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.