11 ms·

Ratifying the H-extension is a serious commitment not easily patched later. Putting something in the kernel is a commitment that's much easier to patch later. T

Ratifying the H-extension is a serious commitment not easily patched later. Putting something in the kernel is a commitment that's much easier to patch later. The linux RISC-V development policy that the extension must be frozen first is the part that seems excessive and unnecessary to me. Put it in now, and modify it later if the H-extension changes. Putting pressure on RISC-V to freeze the H-extension early would be IMHO a bad outcome if it's not frozen for a good reason. If it's not frozen for no known good reason and it's just vendors gaming the system then of course freezing it is a good idea, but that's quite an independent thing from linux.

Taniwha 5y ago
But in essence putting stuff like this in the kernel is putting pressure on freezing the extension. However it's a bit of a chicken and egg situation, you need serious testing before you can ratify and freeze but if you don't encourage people to code against the (moving) spec you wont get the testing you need. As a CPU designer it's particularly tough, wanting those changes frozen asap so you can implement them, but not wanting a broken one
snvzz 5y ago
Other ISAs do also go through revisions, often reinventing interfaces several times until they get it "right". Specific code needs to be written to support every revision. What matters is that hardware is out, and there should be a way to support this hardware. Putting pressure on RISC-V would be Linux abusing its market position to interfere on RISC-V processes. This is particularly wrong to do, as RISC-V processes being open (unlike most other ISAs) shouldn't be seen as an invitation to discriminate against them by not allowing them the possibility of making incompatible changes.
- FullyFunctional 5y ago
  Reality is more nuanced than that. Some private extensions or unratified extensions should really be frowned upon because they risk fragmenting the RISC-V ecosystem. Examples include the completely incompatible version 0.7 of the vector spec and T-head's assorted private extensions. The H extension is a little less clear cut as it doesn't affect user code (IIUC) and as such the damage is limited to OS kernelS (there's more than Linux out there). However it's a slippery slope into fragmentation hell and I actually think the current policy is correct and the blame lies with the H committee. EDIT: language
  - brucehoult 5y ago
    RVV 0.7.1 is not completely incompatible with the current 1.0 draft. The overall structure of code is the same, most instructions and opcodes have not changed at all, especially unmasked operations. I have demonstrated that at least memcpy() can be be binary compatible between 0.7.1 and the current draft. I will check others soon (once I get a Nezha board, hopefully before the end of the month). Many other things could be made compatible -- most simple code using 16 or 32 bit int or 32 bit FP -- by reverting a single small commit to the spec in June 2020 which tidied up the bit field format of the VTYPE CSR but did not introduce any functionality. There are things that are incompatible for very good reasons, but there is much that is either compatible now or that is incompatible for inessential reasons. Reverting the format change in the SEW and LMUL fields, and making 0 for the mask agnostic and tail agnostic bits match the (fixed) settings in 0.7.1 would go a long way towards increasing compatibility, at virtually zero cost.
  - pantalaimon 5y ago
    The Kendryte K210 with it's pre-standard MMU is another example. Because of that it can only run nommu-Linux on mainline.

Taniwha 5y ago

But in essence putting stuff like this in the kernel is putting pressure on freezing the extension. However it's a bit of a chicken and egg situation, you need serious testing before you can ratify and freeze but if you don't encourage people to code against the (moving) spec you wont get the testing you need. As a CPU designer it's particularly tough, wanting those changes frozen asap so you can implement them, but not wanting a broken one

snvzz 5y ago

Other ISAs do also go through revisions, often reinventing interfaces several times until they get it "right". Specific code needs to be written to support every revision. What matters is that hardware is out, and there should be a way to support this hardware. Putting pressure on RISC-V would be Linux abusing its market position to interfere on RISC-V processes. This is particularly wrong to do, as RISC-V processes being open (unlike most other ISAs) shouldn't be seen as an invitation to discriminate against them by not allowing them the possibility of making incompatible changes.

FullyFunctional 5y ago
Reality is more nuanced than that. Some private extensions or unratified extensions should really be frowned upon because they risk fragmenting the RISC-V ecosystem. Examples include the completely incompatible version 0.7 of the vector spec and T-head's assorted private extensions. The H extension is a little less clear cut as it doesn't affect user code (IIUC) and as such the damage is limited to OS kernelS (there's more than Linux out there). However it's a slippery slope into fragmentation hell and I actually think the current policy is correct and the blame lies with the H committee. EDIT: language
- brucehoult 5y ago
  RVV 0.7.1 is not completely incompatible with the current 1.0 draft. The overall structure of code is the same, most instructions and opcodes have not changed at all, especially unmasked operations. I have demonstrated that at least memcpy() can be be binary compatible between 0.7.1 and the current draft. I will check others soon (once I get a Nezha board, hopefully before the end of the month). Many other things could be made compatible -- most simple code using 16 or 32 bit int or 32 bit FP -- by reverting a single small commit to the spec in June 2020 which tidied up the bit field format of the VTYPE CSR but did not introduce any functionality. There are things that are incompatible for very good reasons, but there is much that is either compatible now or that is incompatible for inessential reasons. Reverting the format change in the SEW and LMUL fields, and making 0 for the mask agnostic and tail agnostic bits match the (fixed) settings in 0.7.1 would go a long way towards increasing compatibility, at virtually zero cost.
- pantalaimon 5y ago
  The Kendryte K210 with it's pre-standard MMU is another example. Because of that it can only run nommu-Linux on mainline.