6 ms·

> It’s a tradeoff: With RISC-V you get innovation, you can create new extensions, but you lost software compatibility. And more importantly, you lose the guaran

> It’s a tradeoff: With RISC-V you get innovation, you can create new extensions, but you lost software compatibility. And more importantly, you lose the guarantee of software compatibility,” he said. Arm’s founders made “that a key tenet, and that will serve us well going forward. I’m confident of that.” How long does it take until we have server-side Ubuntu Linux and staple applications like PostgreSQL humming nicely on RISC-V? It does not matter if RISC-V has less ported software today, as long as there is clear roadmap when this advantage of ARM will be gone.

MaKey 5y ago
If everyone implements their own custom extensions, you would have to compile your software for each RISC-V device. To be able to do that, the compiler needs to support those extensions. I think that is what was meant with "you lost software compatibility". Edit: I am mistaken, thanks everyone for educating me.
- geokon 5y ago
  I find it hard to believe there is no way to probe for extensions and provide a fallback It's a problem that already exists right now. If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented
  - rwmj 5y ago
    This is the standard FUD spread around by Arm apologists. Of course you can detect RISC-V extensions at both compile and run time. In fact it's the first widespread ISA that was designed with extension in mind (so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension). This is in stark contrast to x86 where extensions are basically hacks piled on hacks.
    - MaKey 5y ago
      Sorry, my post was not intended to be FUD. I tried to follow the original claim but apparently placed too much merit in it.
    - saagarjha 5y ago
      > so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.
      - tux3 5y ago
        It will be useful for disassemblers, among other things.
        saagarjha 5y ago
        Sure, it’s helpful but not really a requirement by any means. Normal x86 code tends to be self-synchronizing, for example.
  - ori_b 5y ago
    > If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? Yes. Or it leaves them unused on the machine with avx. For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.
  - rjsw 5y ago
    Plenty of open source packages probe for extensions when built for either X86_64 or ARM, then call fallback code if the extension isn't there. Things like OpenJDK, pixman, nss, ffmpeg.
- vbezhenar 5y ago
  Intel CPUs have plenty of optional extensions. Basically you're building two versions of machine code and choose correct one at runtime.
  - MaKey 5y ago
    How would that work if you have a hundred custom extensions?
    - rwmj 5y ago
      Apparently it works fine: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
      - MaKey 5y ago
        I wasn't aware that we already have so many extensions. But doesn't the binary get more bloated the more extensions you have?
        dzaima 5y ago
        In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension. There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
- makapuf 5y ago
  Isn't it the same with some ARM vendors ? Of course, a random foundry can't, but what's preventing Apple from including specific instructions on their core (not that it would make sense) or a specific coprocessor that may or may not be integrated ?
  - saagarjha 5y ago
    Apple does ship custom instructions on their code but does not expose it to third parties: their external compilers will not generate those instructions, and they remain in the kernel and system libraries where they can be hidden behind APIs without being directly exposed.
  - deleted 5y ago
    [deleted]
- fake-name 5y ago
  Something something gentoo is eating the world.
makapuf 5y ago
You could say the same with ARM wrt intel.
rwmj 5y ago
The Arm guy is talking nonsense as you'd expect. Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later. I just started a PostgreSQL server on one of my (four) RISC-V machines here: ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vend> Active: active (running) since Sun 2022-02-13 06:56:50 EST; 1s ago Process: 1861715 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgres> Main PID: 1861722 (postmaster) Tasks: 8 (limit: 9510) Memory: 15.6M CPU: 262ms CGroup: /system.slice/postgresql.service ├─1861722 /usr/bin/postmaster -D /var/lib/pgsql/data ├─1861746 postgres: logger ├─1861752 postgres: checkpointer ├─1861753 postgres: background writer ├─1861754 postgres: walwriter ├─1861755 postgres: autovacuum launcher ├─1861756 postgres: stats collector └─1861757 postgres: logical replication launcher Feb 13 06:56:50 five systemd[1]: Starting PostgreSQL database > Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> The biggest problem I had was remembering the name of the Fedora PostgreSQL package and that I had to initdb before starting the service. If the Arm CEO really believes software compatibility/availability is Arm's moat then I'm afraid he's in for a big shock.
- MaKey 5y ago
  Which RISC-V machines do you have?
  - geokon 5y ago
    While Intel is talking and investing the Chinese are already putting out chips and boards https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangopi-mq-tiny-4x4cm-linux-board-with-wifi/ https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangop... https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/ https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-ris... There are also the expensive dev boards from SiFive as well as the softcores from zepan. I think Alibaba and Rockchip will be available soon as well Jean-Luc's website is great for tracking this space: https://www.cnx-software.com/news/risc-v/ https://www.cnx-software.com/news/risc-v/
trasz 5y ago
Not Linux, but riscv64 FreeBSD works quite well.
- snvzz 5y ago
  So does the RISC-V Haiku port.
- throw0101a 5y ago
  * https://wiki.freebsd.org/riscv https://wiki.freebsd.org/riscv * https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/ https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/
- upofadown 5y ago
  OpenBSD has some support with 7.0: * https://www.openbsd.org/riscv64.html https://www.openbsd.org/riscv64.html
londons_explore 5y ago
ARM also has a good chunk of compatibility issues... There are plenty of times I've had ARM7 vs NEON vs thumb vs big endian/little endian issues... Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...
goodpoint 5y ago
> How long does it take until we have server-side Ubuntu Linux Debian is almost entirely ported to RISC-V and it's been the biggest early adopter. 96% of the packages are ported: https://wiki.debian.org/RISC-V#Progress https://wiki.debian.org/RISC-V#Progress What is missing is powerful and inexpensive CPUs. (Easier said than done)
ido 5y ago
Maybe this is naive - but why is software compatibility so important for servers (that mostly run open source software, like psql)? I assume none of it is written in ARM/x86 assembly language and all of it in higher level languages like c/c++/python/java/js/etc that can be compiled/run on RISC-V?
- pid-1 5y ago
  When rpi was a new thing writing Python in it was a pain in the ass. You had to compile a lot of stuff from source, which was a huge time sink. To this day writing ARM lambdas on AWS has its own gotchas. Idk, I think their CEO has a point, it's just that it might be a short lived one given how much money Chinese companies are throwing at risc V.
- NelsonMinar 5y ago
  Old timers remember when "compiling open source C code to this other platform" was a real chore. Ever run the old school GNU configure and watched the giant stream of compatibility tests for weird architectures that go by? It's for a reason, one nearly forgotten in our current amd64 monoculture. The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.
stefan_ 5y ago
This is just the peak of irony from the guys that couldn't be bothered to copy ACPI for 30 years plus requiring anything running on ARM to set up a bespoke firmware build. That's before you get into all the hard/soft-float, thumb, non-thumb mess and toolchains targeting ARMv6jwzufgka.

MaKey 5y ago

If everyone implements their own custom extensions, you would have to compile your software for each RISC-V device. To be able to do that, the compiler needs to support those extensions. I think that is what was meant with "you lost software compatibility". Edit: I am mistaken, thanks everyone for educating me.

geokon 5y ago
I find it hard to believe there is no way to probe for extensions and provide a fallback It's a problem that already exists right now. If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented
- rwmj 5y ago
  This is the standard FUD spread around by Arm apologists. Of course you can detect RISC-V extensions at both compile and run time. In fact it's the first widespread ISA that was designed with extension in mind (so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension). This is in stark contrast to x86 where extensions are basically hacks piled on hacks.
  - MaKey 5y ago
    Sorry, my post was not intended to be FUD. I tried to follow the original claim but apparently placed too much merit in it.
  - saagarjha 5y ago
    > so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.
    - tux3 5y ago
      It will be useful for disassemblers, among other things.
      - saagarjha 5y ago
        Sure, it’s helpful but not really a requirement by any means. Normal x86 code tends to be self-synchronizing, for example.
- ori_b 5y ago
  > If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? Yes. Or it leaves them unused on the machine with avx. For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.
- rjsw 5y ago
  Plenty of open source packages probe for extensions when built for either X86_64 or ARM, then call fallback code if the extension isn't there. Things like OpenJDK, pixman, nss, ffmpeg.
vbezhenar 5y ago
Intel CPUs have plenty of optional extensions. Basically you're building two versions of machine code and choose correct one at runtime.
- MaKey 5y ago
  How would that work if you have a hundred custom extensions?
  - rwmj 5y ago
    Apparently it works fine: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
    - MaKey 5y ago
      I wasn't aware that we already have so many extensions. But doesn't the binary get more bloated the more extensions you have?
      - dzaima 5y ago
        In practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension. There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
makapuf 5y ago
Isn't it the same with some ARM vendors ? Of course, a random foundry can't, but what's preventing Apple from including specific instructions on their core (not that it would make sense) or a specific coprocessor that may or may not be integrated ?
- saagarjha 5y ago
  Apple does ship custom instructions on their code but does not expose it to third parties: their external compilers will not generate those instructions, and they remain in the kernel and system libraries where they can be hidden behind APIs without being directly exposed.
- deleted 5y ago
  [deleted]
fake-name 5y ago
Something something gentoo is eating the world.

makapuf 5y ago

You could say the same with ARM wrt intel.

rwmj 5y ago

The Arm guy is talking nonsense as you'd expect. Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later. I just started a PostgreSQL server on one of my (four) RISC-V machines here: ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vend> Active: active (running) since Sun 2022-02-13 06:56:50 EST; 1s ago Process: 1861715 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgres> Main PID: 1861722 (postmaster) Tasks: 8 (limit: 9510) Memory: 15.6M CPU: 262ms CGroup: /system.slice/postgresql.service ├─1861722 /usr/bin/postmaster -D /var/lib/pgsql/data ├─1861746 postgres: logger ├─1861752 postgres: checkpointer ├─1861753 postgres: background writer ├─1861754 postgres: walwriter ├─1861755 postgres: autovacuum launcher ├─1861756 postgres: stats collector └─1861757 postgres: logical replication launcher Feb 13 06:56:50 five systemd[1]: Starting PostgreSQL database > Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> The biggest problem I had was remembering the name of the Fedora PostgreSQL package and that I had to initdb before starting the service. If the Arm CEO really believes software compatibility/availability is Arm's moat then I'm afraid he's in for a big shock.

MaKey 5y ago
Which RISC-V machines do you have?
- geokon 5y ago
  While Intel is talking and investing the Chinese are already putting out chips and boards https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangopi-mq-tiny-4x4cm-linux-board-with-wifi/ https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangop... https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/ https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-ris... There are also the expensive dev boards from SiFive as well as the softcores from zepan. I think Alibaba and Rockchip will be available soon as well Jean-Luc's website is great for tracking this space: https://www.cnx-software.com/news/risc-v/ https://www.cnx-software.com/news/risc-v/

trasz 5y ago

Not Linux, but riscv64 FreeBSD works quite well.

snvzz 5y ago
So does the RISC-V Haiku port.
throw0101a 5y ago
* https://wiki.freebsd.org/riscv https://wiki.freebsd.org/riscv * https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/ https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/
upofadown 5y ago
OpenBSD has some support with 7.0: * https://www.openbsd.org/riscv64.html https://www.openbsd.org/riscv64.html

londons_explore 5y ago

ARM also has a good chunk of compatibility issues... There are plenty of times I've had ARM7 vs NEON vs thumb vs big endian/little endian issues... Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...

goodpoint 5y ago

> How long does it take until we have server-side Ubuntu Linux Debian is almost entirely ported to RISC-V and it's been the biggest early adopter. 96% of the packages are ported: https://wiki.debian.org/RISC-V#Progress https://wiki.debian.org/RISC-V#Progress What is missing is powerful and inexpensive CPUs. (Easier said than done)

ido 5y ago

Maybe this is naive - but why is software compatibility so important for servers (that mostly run open source software, like psql)? I assume none of it is written in ARM/x86 assembly language and all of it in higher level languages like c/c++/python/java/js/etc that can be compiled/run on RISC-V?

pid-1 5y ago
When rpi was a new thing writing Python in it was a pain in the ass. You had to compile a lot of stuff from source, which was a huge time sink. To this day writing ARM lambdas on AWS has its own gotchas. Idk, I think their CEO has a point, it's just that it might be a short lived one given how much money Chinese companies are throwing at risc V.
NelsonMinar 5y ago
Old timers remember when "compiling open source C code to this other platform" was a real chore. Ever run the old school GNU configure and watched the giant stream of compatibility tests for weird architectures that go by? It's for a reason, one nearly forgotten in our current amd64 monoculture. The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.

stefan_ 5y ago

This is just the peak of irony from the guys that couldn't be bothered to copy ACPI for 30 years plus requiring anything running on ARM to set up a bespoke firmware build. That's before you get into all the hard/soft-float, thumb, non-thumb mess and toolchains targeting ARMv6jwzufgka.