4 ms·
Will we see the rise of Libc shims soon like those for JavaScript? RISC V feature support looks notoriously fragmented.
by melony 5y ago
Will we see the rise of Libc shims soon like those for JavaScript? RISC V feature support looks notoriously fragmented.
- mhh__ 5y agoMaybe. The technology for "JIT" (i.e. AOT just prior to the program starting) is also relatively mature, so maybe it could go that way. However a lot of these are embedded targets so I don't think we are even close to needing to worry about at least some of these things yet.
- FullyFunctional 5y agoDoes it? It's something I constantly worry about, but so far distributions are holding steady to RV64GC which essentially all 64-bit RISC-V cores support. A few support some proprietary extensions, but those can be ignored by most. The Dubhe core claims to support some of the newly ratified extensions, which if true is great exactly because they are standard and thus doesn't represent fragmentation. I expect of course that libc eventually will start supporting these extensions _where they are present_ but not mandate them.
- marcodiego 5y agoExcept for proprietary extensions, I don't think it will be very different of the x86 world where processors can have a different number of cores, HT, MMX, 3dNow!, SSE(1,2,3,4...), AMX... These extensions didn't destroy x86. I don't think it will be different with RISCV.
- ncmncm 5y agoIt is very, very different. X86 extensions get added onto the sum total of almost all the previous extensions, so that the number of variations to support has grown about linearly with time. RISC-V extensions are more or less all independent, so that the number of variant targets explodes exponentially as they are added to.
- javajosh 5y ago>explodes exponentially Nit pick: it explodes factorially, which is worse than exponential. The superset of a set of N elts is N!. (If order is meaningful (unlikely here), it's slightly worse, which is all permutations of each member of the superset. But that's only ~exponential and is quickly swallowed by the factorial).
- deleted 5y ago[deleted]
- marcodiego 5y agoIt is not different in the sense that my compiler can generate code that runs on RISC-V and runs faster on RISC-V with specific extensions. Binary compatibility, in practice, is not lost.
- ncmncm 5y agoThere is no requirement to execute instructions defined in an extension not supported. So, it means building for RISC-V is necessarily complicated. Worse, if it traps and emulates instructions, then optimizations using extension instructions become radical pessimizations.
- avianes 5y agoWhatever the target processor is, when we need performance we recompile for that specific target. And whatever the target processor is, if you need portability you compile only with extensions widely used. It's the exact same problem with x86 or arm. So.. yes, currently RISC-V is mostly made of isolated extensions, but the goal is clearly to create groups of extensions that will be widely supported.
- nynx 5y agoMost risc-v cpus stick to the standards, so I'm not worried.
- snvzz 5y agoIf you're building a chip for a server, workstation, laptop, smartphone, then you'll want to adhere to a platform spec profile. RVA22[0] is the first such profile, and among other important things which go a long way to ease cross-vendor software compatibility, it does require RVA22U and RVA22S, which in turn require a set of extensions. [0]: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...