RISC-V: More Than a Core

Re:RISC-V: More Than a Core by agalunar on Monday October 15, 2018 @07:18PM (#18224942)

I suppose “variants” is not an inaccurate description, but it feels misleading (although you could argue about intention vs reality). The spec calls them “extensions”. Support for an extension can be checked at runtime, and unsupported instructions can be trapped and emulated. The base ISA is frozen, and the common extensions (floating point, atomics, vectors) are standardized. The spec also defines a subset of the extensions that general purpose processors are expected to support.

It may be a hope born of bias (I’ve worked with the architects of RISC-V), but I don’t expect fragmentation to be one of the primary issues that RISC-V will face.

[ Parent | on HN ]

Re:RISC-V: More Than a Core by pdimitar on Tuesday October 16, 2018 @11:47AM (#18230295)

I am no expert but...

> Support for an extension can be checked at runtime, and unsupported instructions can be trapped and emulated.

...isn't that exactly fragmentation?

[ Parent | on HN ]

Re:RISC-V: More Than a Core by agalunar on Wednesday October 17, 2018 @10:05AM (#18239109)

I’m no expert either, and maybe there’s a precise definition of fragmentation that I’m not aware of. My understanding is that fragmentation is about software.

The extension scheme allows you to use the same binaries across all platforms. If you care about widespread compatibility, you simply compile-in software emulations of potentially unsupported instructions. If a platform ~does~ support the instructions, the emulation is never used and you get a performance bonus.

[ Parent | on HN ]