9 ms·

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

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