3 ms·

> Or OS authors are going to have to rethink how they handle illegal instruction exceptions, by patching the calling program to call into an emulated version wh

> Or OS authors are going to have to rethink how they handle illegal instruction exceptions, by patching the calling program to call into an emulated version when running on hardware that lacks support; […] It can be done at the OS kernel level, but it does not have to. The usual place to do it in is libc – by virtue of weak symbols in dynamic libraries. At the linking time, the ld links the executable against a generic function, e.g. __mul512_xyz, and __mul512_xyz is a weak symbol that points to a generic fallback implementation of the 512-bit wide operation in libc.so. Now, at the process startup time, the libc initialisation code looks up the CPU revision, attempts to locate a CPU revision specific, optimised version of, e.g. __cpu_family_abc_123_mul512_xyz, and links the optimised version of the function in. I have made names up but, fundamentally, the idea is that. > […] this would allow program authors to choose whether to favor the least common denominator … and this is where I perceive a problem with RISC-V – based on my current knowledge of the ISA in question. Being an open source and a free ISA, RISC-V places no obligation on two (or three, or more) distinct CPU vendors to implement the same set of ISA extensions (other than the foundational one). Therefore, effectively we are talking about every possible permutation of all current and future, extra, ISA extensions that would have to be supported in libc, and it will make it the dynamic re-linking at the runtime either difficult or not possible (not easily, anyway), and the RISC-V specific optimisation effort(s) will go out of the window.

hajile 4y ago
The foundation releases profiles. For example, the RVA22S64 means it's a 64-bit application processor with supervisor mode complying with the 2022 recommendations. It has a bunch of specific requirements about RAM layout, cache instructions, being little-endian, and so on all specified so code is portable. Likewise M (mul/div), A (atomics) F (32-bit float), D (64-bit float), C (16-bit instructions), and some misc bit manipulation and other instructions MUST be implemented. At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff. If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark). If you want to enter the desktop ecosystem that is being started, you'd better support the extensions they specify in RVA22S64 (or newer standards) otherwise people aren't going to buy your chip. You can implement proprietary stuff provided it doesn't conflict with the standard, but normal software isn't going to use those features, so you are probably just wasting transistors. All the work on unifying stuff like UEFI is because the companies involved are serious about a compatible standard moving forward. It's in all the biggest player's best interests to stick to the spec which is all that matters for end users as it guarantees a consistent experience. https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc https://github.com/riscv/riscv-profiles/blob/main/profiles.a...
- inkyoto 4y ago
  > At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff. It is the optional extensions that concern me the most, not the foundational ones. Cryptographic functions, for example, can be optimised using a vector instruction set, a crypto accelarating instruction set, or via a combination of both. If something better comes along (hypothetically), it will become another, new, instruction extension in the future. The libc runtime now has to do significant guess work to support a permutation of all available instruction extensions (or fall back to a generic, unoptimised, version when none are available), not to mention the libc blowing out quite substantially for RISC-V – in size and in complexity. > If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark). I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture. Which has happened in the past with some ARMv7 (or ARMv8?) designs, and which we are nearly guaranteed to see in IoT devices (at the very least). I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it.
  - hajile 4y ago
    > I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture Who cares. Is HP going to buy a cheap Chinese chip that causes user software to randomly crash? If that company is going to compete, maybe they want a 5nm chip. They design the chip and get past sanctions, but now have to pay a half-billion to get everything ready for fabrication and then another 2B for that 100k wafer discount. Now they have huge quantities of chips that are too expensive for the Chinese market and too broken/incompatible for the American/European market. Sticking to the spec -- even if it's just microcoded -- is way better than the alternative. > It is the optional extensions that concern me the most, not the foundational ones. Crypto is optional because they believe scalar crypto probably isn't the way forward. They are working on vector crypto, but it's not finalized. Likewise, the vector extension was released too close to the 2022 deadline to force compliance. Look at web standards. Where backward compatibility matters, it's WAY better to be conservative than to mess up forever. RISC-V chips with decent performance likely won't be out until 2024. By that time, these extensions will be well-established. Companies will have had time to implement them and they will become required. > I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it. This is a particularly unlikely outcome because JS support requires double-precision. Even tiny ARM cores in phones over a decade ago had support for 64-bit floats. If you want to save area, cutting cache or wider SIMD gets you way more bang for your buck.

hajile 4y ago

The foundation releases profiles. For example, the RVA22S64 means it's a 64-bit application processor with supervisor mode complying with the 2022 recommendations. It has a bunch of specific requirements about RAM layout, cache instructions, being little-endian, and so on all specified so code is portable. Likewise M (mul/div), A (atomics) F (32-bit float), D (64-bit float), C (16-bit instructions), and some misc bit manipulation and other instructions MUST be implemented. At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff. If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark). If you want to enter the desktop ecosystem that is being started, you'd better support the extensions they specify in RVA22S64 (or newer standards) otherwise people aren't going to buy your chip. You can implement proprietary stuff provided it doesn't conflict with the standard, but normal software isn't going to use those features, so you are probably just wasting transistors. All the work on unifying stuff like UEFI is because the companies involved are serious about a compatible standard moving forward. It's in all the biggest player's best interests to stick to the spec which is all that matters for end users as it guarantees a consistent experience. https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc https://github.com/riscv/riscv-profiles/blob/main/profiles.a...

inkyoto 4y ago
> At the same time, it specifies optional extensions like V (vector), Zfh (16-bit floats), scalar crypto, H (hypervisor), and some optional supervisor stuff. It is the optional extensions that concern me the most, not the foundational ones. Cryptographic functions, for example, can be optimised using a vector instruction set, a crypto accelarating instruction set, or via a combination of both. If something better comes along (hypothetically), it will become another, new, instruction extension in the future. The libc runtime now has to do significant guess work to support a permutation of all available instruction extensions (or fall back to a generic, unoptimised, version when none are available), not to mention the libc blowing out quite substantially for RISC-V – in size and in complexity. > If you want to claim to be a RISC-V chip, you MUST implement the specs exactly (else be infringing on their trademark). I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture. Which has happened in the past with some ARMv7 (or ARMv8?) designs, and which we are nearly guaranteed to see in IoT devices (at the very least). I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it.
- hajile 4y ago
  > I admire your sense of optimism, but I can nearly guarantee you that a less diligent Chinese RISC-V vendor will not give a flying fig about the trademark and will even cut those extensions out that form the foundational set – if it makes the chip cheaper to design and manufacture Who cares. Is HP going to buy a cheap Chinese chip that causes user software to randomly crash? If that company is going to compete, maybe they want a 5nm chip. They design the chip and get past sanctions, but now have to pay a half-billion to get everything ready for fabrication and then another 2B for that 100k wafer discount. Now they have huge quantities of chips that are too expensive for the Chinese market and too broken/incompatible for the American/European market. Sticking to the spec -- even if it's just microcoded -- is way better than the alternative. > It is the optional extensions that concern me the most, not the foundational ones. Crypto is optional because they believe scalar crypto probably isn't the way forward. They are working on vector crypto, but it's not finalized. Likewise, the vector extension was released too close to the 2022 deadline to force compliance. Look at web standards. Where backward compatibility matters, it's WAY better to be conservative than to mess up forever. RISC-V chips with decent performance likely won't be out until 2024. By that time, these extensions will be well-established. Companies will have had time to implement them and they will become required. > I will not be surprised if a CPU vendor chooses to toss the D extension out and stick with the F extension only for niche case solutions, and it will not be possible to enforce it. This is a particularly unlikely outcome because JS support requires double-precision. Even tiny ARM cores in phones over a decade ago had support for 64-bit floats. If you want to save area, cutting cache or wider SIMD gets you way more bang for your buck.