Systemd Now Supports The RISC-V CPU Architecture

[phoronix]

Phoronix: Systemd Now Supports The RISC-V CPU Architecture

For those fond of the open and free RISC-V instruction set architecture, the basic changes have been made so systemd now supports this CPU architecture...

http://www.phoronix.com/scan.php?pag...Systemd-RISC-V

[discordian]

What kinda CPU specific code is needed for handling jobs/events?
Or is this for displaying RISC-V in some Infos? (even that would fit better in the kernel)

[microcode]

What kinda CPU specific code is needed for handling jobs/events?
Or is this for displaying RISC-V in some Infos? (even that would fit better in the kernel)

Seems it sets a static pointer byte width, and lets systemd detect and display your architecture; yeah.

https://github.com/systemd/systemd/c...978f36a5c003d0

I'm a little concerned though, it seems like the kernel uname doesn't show you the family, just the base instruction set. RV64I (base integer instruction set) doesn't include float/double, multiplication/division, or atomics. At least for the i{3..6}86 families you can determine a base feature set which is reasonable for running things from the uname. The set you'll probably see on bigger microcontrollers, PCs, and servers is RV64GC.

[adler187]

Seems it sets a static pointer byte width, and lets systemd detect and display your architecture; yeah.

https://github.com/systemd/systemd/c...978f36a5c003d0

I'm a little concerned though, it seems like the kernel uname doesn't show you the family, just the base instruction set. RV64I (base integer instruction set) doesn't include float/double, multiplication/division, or atomics. At least for the i{3..6}86 families you can determine a base feature set which is reasonable for running things from the uname. The set you'll probably see on bigger microcontrollers, PCs, and servers is RV64GC.

As noted in the commit comment, that information will be available from /proc/cpuinfo. Just like SSE, AVX, etc... is done for x86 and other architectures. I'm not sure why you'd need (or want) that to be returned by uname. That's just a recipe for screwing up every uname detection script (configure, ...) every time a new slightly different variation of RISC-V is introduced.

[DrYak]

As noted in the commit comment, that information will be available from /proc/cpuinfo. Just like SSE, AVX, etc... is done for x86 and other architectures. I'm not sure why you'd need (or want) that to be returned by uname.

The thing with RISC processors is that even functionnality that is usually considered *basic* on other CPUs might be missing.

SSE, AVX, are nice extra fluff, but you can perfectly run a system without them (you'll get just less performance out of the box if you can't use vectors).

On ther other hand, missing floating point can start to get problematic (and even at uname level, distinction is made between "hf" (=hard float) and "el" (=emulated) type of "arm#xx" architectures. Same as between 386 generations (floats optional) and 586 (floats supported in all models without exception) )

And RISC-V can even be made *without* multiplication. (You have to manually shift-add to do your multiplications. There's no microcode (as in i386) or shift-adder-array (on modern x86 CPUs) doing it for you), you *definitely* need to consider these as completely separate architecture and compile accordingly. Even if in theory one could run the "software multiplication" code on "hardware multiplication" CPUs (with an atrocious speed penalty).

The situations is the same like in the Raspberry Pi 1, which had ARM6 instruction set *with* floating point support, whereas most distro target either "arm6el" or "arm7hf".
(Thus either wrong instructions set (and can't run). Or compatible instructions set but don't take advantage of the hardware float (and runs at a fraction of the speed). That's why people started "Raspian" which is basically "Debian but 'arm6hf' so it works full speed on the Pi 1" )

Usually the approach is :
- extra function that accelerate some tasks that a few software can profite : goes into /proc/cpuinfo.
- base functionnality that everything depends on and need to be software emulated : use a different arch name, visiable in "uname" already.

[microcode]

As noted in the commit comment, that information will be available from /proc/cpuinfo. Just like SSE, AVX, etc... is done for x86 and other architectures. I'm not sure why you'd need (or want) that to be returned by uname. That's just a recipe for screwing up every uname detection script (configure, ...) every time a new slightly different variation of RISC-V is introduced.

All of these variations are currently known, and it is a huge deal to differentiate between having atomics and not, or to differentiate between having hardware multipliers, or hardware float and not. Base instruction set variations of this nature change the compiler output by leaps and bounds, we're not talking about multimedia extensions or your hardware tanh() function for neural nets. Things which are taken for granted even in i386 are missing from some RISC-V variants, and most distros don't even distribute i386-compatible binaries anymore.

SSE, AVX, are nice extra fluff, but you can perfectly run a system without them (you'll get just less performance out of the box if you can't use vectors).

Btw, SSE is actually mandatory for AMD64.

[danieru]

Why support for this CPU architecture? Isn't it irrelevant?

[rtfazeberdee]

wow, a pleasant surprise - no "the sky is falling" comments, must be a first for an article mentioning systemd

[starshipeleven]

Why support for this CPU architecture? Isn't it irrelevant?

It is seen by most big companies as the future in embedded and controller space, India is making server-grade chips with that. There is a truckload of expectations on RISC-V from all sides and Linux is the OS that will run the show in there, so everything on Linux must be ready for when the hardware starts shipping.

[jacob]

wow, a pleasant surprise - no "the sky is falling" comments, must be a first for an article mentioning systemd

They are still chewing on it. Don't worry, it won't be long before we get flames about how RISC-V is evil for being able to run systemd, how terrible it is for systemd to have RISC-V support, how superior SysV init is, because even if it never ran on RISC-V at all, at least it's not systemd, how they will never buy a RISC-V machine if systemd can be compiled on it, etc...