| General > General Technical Chat |
| RISC-V Technology Conference: Nerds Talking to Nerds About RISC V |
| << < (5/5) |
| SiliconWizard:
--- Quote from: anotherlin on April 20, 2023, 11:15:41 am ---So I've taken a quick look at RISC-V's spec. It should be possible to use only the "C" extension 16-bit encoding. All ALU functions are available, ADD, SUB, AND, OR, XOR, various shifts, along with load/store, and branching. There would be limitations for offsets, but nothing that can't be addressed (no pun intended) by using multiple/indirect loads. The other big issue is that we would be limited to 8 registers, notably the ALU instructions can access only 8 registers. However, x86 long lived with only 7 (user visible) general purpose registers. The 2 big issues are rather that it would be 1) non standard (RV32E mandates 16 registers, we would be limited to 8 here). And 2) the compilers would have to be modified to generate that non-standard 8 registers limited 16-bit C encodings. So, not trivial, but no huge difficulties. --- End quote --- So, you did it! ;D --- Quote from: anotherlin on April 20, 2023, 11:15:41 am ---The big question would be: is it worth it? --- End quote --- Probably not. As you mentioned, the big plus of RISC-V it its specs and the traction it got - so you have high-quality toolchains for it. If you're deriving something from RISC-V that is not RISC-V, you'll lose most of this, and while the RISC-V ISA itself is pretty sane, I don't think it would make the best basis for a 16-bit architecture. |
| SiliconWizard:
--- Quote from: asmi on April 20, 2023, 06:16:17 pm --- --- Quote from: TomS_ on April 20, 2023, 05:22:04 pm ---I dont know if any of them meet your exact specs, but check out Explaining Computers on YouTube. He does a yearly run down of RISC-V based SBCs, and there are certainly some Linux capable SBCs out there. --- End quote --- I want chips, not SBC boards. I like designing stuff myself. --- End quote --- At the moment, I personally don't much care for neither chips nor SBC boards, as, just as a fact, available ARM-based solutions are just better at this point both in terms of performance and power consumption. Now I like having alternatives, and the future probably holds a lot of cool stuff for RISC-V, but right now, not particularly interested in off-the-shelf solutions. But "designing stuff" is precisely what got me interested in RISC-V actually. RISC-V has made it easy to design your own CPUs with a decent ISA, while having access to quality toolchains for free. So, that's the part I've been interested in. |
| anotherlin:
--- Quote from: SiliconWizard on April 20, 2023, 07:43:41 pm ---So, you did it! ;D --- End quote --- No, I did not. In retrospect, it's just that I start getting old :) and couldn't envision a microcontroller or low power embedded CPU, as something 32-bit. There's most probably already quite some work done targeting ultra-low power/battery powered, super efficient, microcontroller class type of implementation. One example was the RV32E with internal 16-bit datapath designed in China. In fact, there's a proposal (https://github.com/riscv/riscv-code-size-reduction) regarding code reduction which is well on its way to become ratified as standard. It does not intend to provide an extension with all instructions being 16-bit, but rather just have more compact code. Which can be beneficial even to huge high-performance RV64 CPU with vector extension (code cache is still a scarce and valuable resource). It's just that we probably don't get as much as presentation of ucontroller types of implementations. Maybe less "sexy" than high performance ones. With RISC-V's well designed and very clean architecture, I'm pretty much sure we can obtain something even more efficient than ARM M0. |
| Navigation |
| Message Index |
| Previous page |