4 ms·

You can distribute a binary that uses "core", and then also uses extensions at runtime if they are available. That's completely fine and standard. It's already

by tux3 2y ago

You can distribute a binary that uses "core", and then also uses extensions at runtime if they are available. That's completely fine and standard. It's already what people do with x86 too, if you want to ship say AVX-512 code you have to deal with the fact that the latest Intel client CPUs don't yet have support (product segmentation issues), so at runtime you have to check if the extension is supported. The situation is not different with RISC-V. You compile your binary for the standard profile, and optionally if you want to use a specialized extension to optimize some hot loop, you check at runtime if it's available.

geokon 2y ago
Right, in the x86 example there are very few optional instructions and there aren't new instructions (at least of consequence) on the horizon. So you can compile with switches if you really want I guess. I think ARM is a better example of things being a mess where people compile for older/core instructions and new instructions are underutilized. I can never remember the whole ARM thing with all the code sequences.. it's highly confusing
- brucehoult 2y ago
  > there aren't new [x86] instructions (at least of consequence) on the horizon. Shirley you're joking? Did you miss APX, coming soon in Panther Cove? - expands x86_64 from 16 to 32 GPRs - adds 3-address instructions - updating flags is optional - push/pop 2 registers with one instruction - more conditional execution instructions, including loads & stores GCC 14 already supports 32 GPRs, 3-address, push2/pop2. GCC 15 (head) supports NF (No Flags).
geokon 2y ago
Looking at this again - the naming convention is a bit worrying... Does the 23 in RVA23 refer to 2023? Do you need annual recompilations of software..? Do you need codepaths for every year since .. whenever the first core was released?
- magicalhippo 2y ago
  > Does the 23 in RVA23 refer to 2023? Yes[1]. > Do you need annual recompilations of software..? The profiles is designed to provide guarantees of what's available. Just because RVA23 was released now, does not mean the RVA22 CPUs and the software that runs on those CPUs stop working. Also, at least for the foreseeable future, the profiles will be extensions of the previous ones[2]. Thus RVA22 should be a subset of RVA23, and any software targetting RVA22 should run fine on a CPU supporting RVA23. [1]: https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#31-profile-family https://github.com/riscv/riscv-profiles/blob/main/src/profil... [2]: https://github.com/riscv/riscv-profiles/blob/main/src/rva-profile-overview-body.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva-pr...
  - geokon 2y ago
    How does this work long term? So say ten years down the line.. RVA34 comes out. But you will compile for RV22 and then have have spaghetti of 10+ platform specific codepaths in the binary？ I feel at some point you're either going to have penalties from the all the platform check and jumps or you're going to only use these extension in critical hotpaths and they get underutilized (what you see with SSE in x64 and the whole mess on ARM)
    - magicalhippo 2y ago
      Time will tell. As they note in the page I linked to, they've decided to tackle that one when they get there. I'll agree it sounds like it could get messy. That said, I'm sort of imagining the core set of extensions to not grow significantly larger. Perhaps they'll add some granularity to the various profile levels, like embedded application CPUs like in set-top boxes might not need all the features of a full-blow desktop or server CPU.
    - brucehoult 2y ago
      It's not going to be every year! And each one runs all software from all previous profiles. Right now there is RVA20 (almost all shipping hardware), RVA22 (only Canaan K230 and SpacemiT K1/M1 shipping now, more coming next year e.g. SG2380), and RVA23 just ratified, hardware in probably 2-3 years. Worrying about multiplication of RISC-V profiles is ignoring the existing reality of every other platform. There are currently 17 different releases of ARMv8-A and ARMv9-A. Have you seen the extensions list on any recent x86? My laptop reports: 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 tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx 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 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause

by tux3 2y ago

geokon 2y ago

Right, in the x86 example there are very few optional instructions and there aren't new instructions (at least of consequence) on the horizon. So you can compile with switches if you really want I guess. I think ARM is a better example of things being a mess where people compile for older/core instructions and new instructions are underutilized. I can never remember the whole ARM thing with all the code sequences.. it's highly confusing

brucehoult 2y ago
> there aren't new [x86] instructions (at least of consequence) on the horizon. Shirley you're joking? Did you miss APX, coming soon in Panther Cove? - expands x86_64 from 16 to 32 GPRs - adds 3-address instructions - updating flags is optional - push/pop 2 registers with one instruction - more conditional execution instructions, including loads & stores GCC 14 already supports 32 GPRs, 3-address, push2/pop2. GCC 15 (head) supports NF (No Flags).

geokon 2y ago

Looking at this again - the naming convention is a bit worrying... Does the 23 in RVA23 refer to 2023? Do you need annual recompilations of software..? Do you need codepaths for every year since .. whenever the first core was released?

magicalhippo 2y ago
> Does the 23 in RVA23 refer to 2023? Yes[1]. > Do you need annual recompilations of software..? The profiles is designed to provide guarantees of what's available. Just because RVA23 was released now, does not mean the RVA22 CPUs and the software that runs on those CPUs stop working. Also, at least for the foreseeable future, the profiles will be extensions of the previous ones[2]. Thus RVA22 should be a subset of RVA23, and any software targetting RVA22 should run fine on a CPU supporting RVA23. [1]: https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#31-profile-family https://github.com/riscv/riscv-profiles/blob/main/src/profil... [2]: https://github.com/riscv/riscv-profiles/blob/main/src/rva-profile-overview-body.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva-pr...
- geokon 2y ago
  How does this work long term? So say ten years down the line.. RVA34 comes out. But you will compile for RV22 and then have have spaghetti of 10+ platform specific codepaths in the binary？ I feel at some point you're either going to have penalties from the all the platform check and jumps or you're going to only use these extension in critical hotpaths and they get underutilized (what you see with SSE in x64 and the whole mess on ARM)
  - magicalhippo 2y ago
    Time will tell. As they note in the page I linked to, they've decided to tackle that one when they get there. I'll agree it sounds like it could get messy. That said, I'm sort of imagining the core set of extensions to not grow significantly larger. Perhaps they'll add some granularity to the various profile levels, like embedded application CPUs like in set-top boxes might not need all the features of a full-blow desktop or server CPU.
  - brucehoult 2y ago
    It's not going to be every year! And each one runs all software from all previous profiles. Right now there is RVA20 (almost all shipping hardware), RVA22 (only Canaan K230 and SpacemiT K1/M1 shipping now, more coming next year e.g. SG2380), and RVA23 just ratified, hardware in probably 2-3 years. Worrying about multiplication of RISC-V profiles is ignoring the existing reality of every other platform. There are currently 17 different releases of ARMv8-A and ARMv9-A. Have you seen the extensions list on any recent x86? My laptop reports: 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 tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx 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 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect user_shstk avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi vnmi umip pku ospke waitpkg gfni vaes vpclmulqdq rdpid movdiri movdir64b fsrm md_clear serialize arch_lbr ibt flush_l1d arch_capabilities vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs ept_mode_based_exec tsc_scaling usr_wait_pause