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
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod