3 ms·

IIRC the Shakti family didn't include the C extension, which would make it incompatible with most Linux distros who have chosen to require it. Is this still th

by jabl 4y ago

IIRC the Shakti family didn't include the C extension, which would make it incompatible with most Linux distros who have chosen to require it. Is this still the case?

jayp1418 4y ago
Shakti website mentions using Ada language which is better for embedded development. Govt.'s focus right now seems Agriculture and similar industries
- zozbot234 4y ago
  Then they should totally make an Ada extension for RISC-V and replace all those clunky outdated iAPX 432's.
sanxiyn 4y ago
I don't know whether Shakti didn't support C extension in the past, but it certainly supports it now. I just checked the decoder source code right now.
kragen 4y ago
Even if that were the case, recompiling Debian with different compiler options is not rocket science—thanks to decades of tireless work by thousands of volunteers. Probably someone will read your comment and think "the C extension" means "support for the programming language C", but that is not the case. Standard RISC-V instruction set extensions are identified by letters: M for multiply (and unfortunately divide), F for floating point, D for double-precision floating point, A for atomic memory operations (necessary for SMP), V for vector operations, and so on. The C extension is the "compressed" extension, which represents the most common instructions in 16 bits instead of the usual 32. Without the C extension, RISC-V code is relatively bulky, which is a disadvantage not only for limited-memory microcontrollers but also because, if you have an instruction cache, less code fits into it, so most software runs slower. With the C extension, RISC-V code density is at least competitive with the best alternatives like Thumb2, and in most cases slightly better. This is particularly interesting in the 64-bit space, because arm64 (aarch64) has abandoned the Thumb2-style compressed instruction approach.
brucehoult 4y ago
The very first Skakti test chip didn't support C. All their following ones do. Vega doesn't seem to be supporting C extension. A very bad decision, if true. C is not expensive to support, and certainly cheaper than building larger icache to make up for not supporting it -- let alone the cost of compiling your own Linux distro if you don't support C. I'm not aware of a single commercially-produced RISC-V microcontroller that doesn't support the C extension, so there's no reason at all that something with MMU and FPU wouldn't. Leaving it out is just something that is possible for student projects and to simplify early teaching, not something that is a good idea to do in real life.

by jabl 4y ago

IIRC the Shakti family didn't include the C extension, which would make it incompatible with most Linux distros who have chosen to require it. Is this still the case?

jayp1418 4y ago

Shakti website mentions using Ada language which is better for embedded development. Govt.'s focus right now seems Agriculture and similar industries

zozbot234 4y ago
Then they should totally make an Ada extension for RISC-V and replace all those clunky outdated iAPX 432's.

sanxiyn 4y ago

I don't know whether Shakti didn't support C extension in the past, but it certainly supports it now. I just checked the decoder source code right now.

kragen 4y ago

Even if that were the case, recompiling Debian with different compiler options is not rocket science—thanks to decades of tireless work by thousands of volunteers. Probably someone will read your comment and think "the C extension" means "support for the programming language C", but that is not the case. Standard RISC-V instruction set extensions are identified by letters: M for multiply (and unfortunately divide), F for floating point, D for double-precision floating point, A for atomic memory operations (necessary for SMP), V for vector operations, and so on. The C extension is the "compressed" extension, which represents the most common instructions in 16 bits instead of the usual 32. Without the C extension, RISC-V code is relatively bulky, which is a disadvantage not only for limited-memory microcontrollers but also because, if you have an instruction cache, less code fits into it, so most software runs slower. With the C extension, RISC-V code density is at least competitive with the best alternatives like Thumb2, and in most cases slightly better. This is particularly interesting in the 64-bit space, because arm64 (aarch64) has abandoned the Thumb2-style compressed instruction approach.

brucehoult 4y ago

The very first Skakti test chip didn't support C. All their following ones do. Vega doesn't seem to be supporting C extension. A very bad decision, if true. C is not expensive to support, and certainly cheaper than building larger icache to make up for not supporting it -- let alone the cost of compiling your own Linux distro if you don't support C. I'm not aware of a single commercially-produced RISC-V microcontroller that doesn't support the C extension, so there's no reason at all that something with MMU and FPU wouldn't. Leaving it out is just something that is possible for student projects and to simplify early teaching, not something that is a good idea to do in real life.