7 ms·

So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly ent

by __d 1mo ago

So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly entrenched.

inigyou 1mo ago
You can't make a community-based ISA, it's not possible unless you have a community-based fab. He who makes the chips makes the rules.
- monocasa 1mo ago
  I mean, a shuttle run is pretty cheap these days. If you have silicon, and customers, scaling past a shuttle run that worked is pretty low additional cost.
  - inigyou 1mo ago
    It's not really a community though is it?
- __d 1mo ago
  Err … RISC-V is an ISA without a fab?
IshKebab 1mo ago
Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.
- NetMageSCW 1mo ago
  Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.
  - duskwuff 1mo ago
    The ARM ISAs are not free to implement. ARM holds patents relevant to the ISA.
    - phendrenad2 1mo ago
      Until the patents expire, which many have already.
      - monocasa 1mo ago
        The aarch64 stuff still has some time, particularly if you want stuff like virtualization.
  - IshKebab 1mo ago
    You're vastly underestimating the amount of work that has gone into RISC-V that would need to be redone. It's not just a spec. There's an absolute mountain of software and hardware supporting it.
    - __d 1mo ago
      Sure. But … so was Linux, or Firefox, or GNOME or KDE, etc. Even RISC-V itself was adopted by volunteers and supported by toolchains, and then kernels, and applications. The amount of work is less a problem than the motivation. And motivation really just depends on recognizing that the status quo sucks, but is fixable.
- __d 1mo ago
  And yet, new ISAs arise fairly regularly, for various reasons. RISC-V itself succeeded largely because it is gratis, I think.
- hajile 1mo ago
  How about EPIC-esque packet-based instructions? 64-bit instructions with 4 bits indicating instruction formats (60-bit, two 40+20-bit variants, 30+30-bit, 20+20+20-bit, three 30+15+15-bit variants, and 15+15+15+15-bit). Have each larger instruction type be a strict superset of the smaller instructions, but with larger immediates, more registers, and maybe additional instruction formats (eg, for SIMD). Something like that would be even easier to decode (converting short instructions to long is simply a bit of wiring). Instruction density should increase due to 20-bit instruction type. Having properly-aligned instructions would help with fetching performance. Larger instructions means you can jump 4x further with the same immediate and 16-bit offsets. No need to have some of the V extension workarounds (from not wanting to add 48-bit instructions).
  - renox 1mo ago
    So a VLIW, interesting but usually compressed instructions are at most two-registers..
    - hajile 1mo ago
      Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary. 2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density. Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks. The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.

by __d 1mo ago

So … use RISC-V as the strawman, and create a community-based RISC-6 that doesn’t have these weaknesses? Better to get in now before it becomes too solidly entrenched.

inigyou 1mo ago

You can't make a community-based ISA, it's not possible unless you have a community-based fab. He who makes the chips makes the rules.

monocasa 1mo ago
I mean, a shuttle run is pretty cheap these days. If you have silicon, and customers, scaling past a shuttle run that worked is pretty low additional cost.
- inigyou 1mo ago
  It's not really a community though is it?
__d 1mo ago
Err … RISC-V is an ISA without a fab?

IshKebab 1mo ago

Likely impossible unless you somehow come up with something vastly better (unlikely). None of these things are remotely bad enough to make the downsides of using another ISA palatable.

NetMageSCW 1mo ago
Anther ISA like ARM? It seems pretty palatable to just about everyone not academic.
- duskwuff 1mo ago
  The ARM ISAs are not free to implement. ARM holds patents relevant to the ISA.
  - phendrenad2 1mo ago
    Until the patents expire, which many have already.
    - monocasa 1mo ago
      The aarch64 stuff still has some time, particularly if you want stuff like virtualization.
- IshKebab 1mo ago
  You're vastly underestimating the amount of work that has gone into RISC-V that would need to be redone. It's not just a spec. There's an absolute mountain of software and hardware supporting it.
  - __d 1mo ago
    Sure. But … so was Linux, or Firefox, or GNOME or KDE, etc. Even RISC-V itself was adopted by volunteers and supported by toolchains, and then kernels, and applications. The amount of work is less a problem than the motivation. And motivation really just depends on recognizing that the status quo sucks, but is fixable.
__d 1mo ago
And yet, new ISAs arise fairly regularly, for various reasons. RISC-V itself succeeded largely because it is gratis, I think.
hajile 1mo ago
How about EPIC-esque packet-based instructions? 64-bit instructions with 4 bits indicating instruction formats (60-bit, two 40+20-bit variants, 30+30-bit, 20+20+20-bit, three 30+15+15-bit variants, and 15+15+15+15-bit). Have each larger instruction type be a strict superset of the smaller instructions, but with larger immediates, more registers, and maybe additional instruction formats (eg, for SIMD). Something like that would be even easier to decode (converting short instructions to long is simply a bit of wiring). Instruction density should increase due to 20-bit instruction type. Having properly-aligned instructions would help with fetching performance. Larger instructions means you can jump 4x further with the same immediate and 16-bit offsets. No need to have some of the V extension workarounds (from not wanting to add 48-bit instructions).
- renox 1mo ago
  So a VLIW, interesting but usually compressed instructions are at most two-registers..
  - hajile 1mo ago
    Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary. 2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density. Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks. The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.