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

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod