Instruction Sets Want to be Free
June 10, 2017 10:48 AM   Subscribe

RISC-V (pronounced "risk five") is a open instruction set architecture ("ISA") originally developed at UC Berkeley for research and education that has been seeing a lot of exciting developments lately. You can buy a RISV-V based microcontroller right now. It is officially supported by GCC. The lowRISC project, founded by some of the same people responsible for Raspberry Pi, aims to provide a fully open source Linux system-on-a-chip. UC Berkeley has developed a (relatively) high performance, super-scalar, out-of-order RISC-V core.

An ISA defines the interface between software and hardware. The two ISAs that dominate the space today are the x86 ISA developed by Intel, and the ARM ISA developed by ARM Holdings. With few exceptions, x86 dominates the desktop, laptop, and server segments, whereas ARM dominates the smartphone, tablet, and embedded segments. RISC-V's open nature is intended to make it a better platform for research, attractive to those concerned with privacy, and a lower cost option for commercial users who otherwise would have to license a core from ARM.

The 6th RISC-V Workshop recently wrapped up in Shanghai. Slides and video available at the link, but here are a few highlights: If you're hungry for more RISC-V info, the RISC-V workshops page has links to the proceedings of past workshops with slides and video for almost all talks.
posted by jcreigh (40 comments total) 28 users marked this as a favorite
 
"RISC architecture is going to change everything."
-- Acid Burn

"Yeah. RISC is good."
-- Crash Override (née Zero Cool)
posted by radwolf76 at 11:04 AM on June 10 [14 favorites]


RISC-V (pronounced "risk five")

when can we get oh ess ecks running on risk vee?
posted by indubitable at 11:26 AM on June 10 [4 favorites]


RISC-V's open nature is intended to make it a better platform for research, attractive to those concerned with privacy, and a lower cost option for commercial users who otherwise would have to license a core from ARM.

Or from MIPS, which is still limping on as part of Imagination. Skimming the RISC-V ISA spec, it does feel like it has quite a lot of MIPS flavor -- although thankfully without the MIPS' annoying branch delay slots.

(Also, vendor support is pretty important to commercial licensees of IP cores; that might be a major sticking point in adoption of RISC-V cores in commercial products. Hardware is a different world to software, in which we all happily depend on open-source tools like gcc. Software is patchable, but if your chip's tapeout goes bad you've just burned $1M on a batch of coasters.)
posted by We had a deal, Kyle at 11:43 AM on June 10 [1 favorite]


Is there a list of hobbyist projects one could do with one of these boards?
posted by codacorolla at 11:46 AM on June 10 [1 favorite]


Yes, but will it run AIX?
posted by jferg at 12:41 PM on June 10 [5 favorites]


Also, vendor support is pretty important to commercial licensees of IP cores

Hell yes it is. I've been faced with choosing SoCs from a number of major companies, and I've been burned once too many by a vendors that promise a great feature set but have zero software support ready. If I need to spend 18 months writing drivers for the basic things, then it's not going to happen.

Right now that means I go with Freescale and TI over anyone else. They at least have solid kernel trees on their Github servers and you can build a filesystem in a few hours.

RISC-V got me excited until I realized that the ISA core isn't really what makes or breaks a product anymore, but the hardware blocks around it that do. A super-cheap RISC-V SoC means jack squat if nobody is willing to build up a software base around it.
posted by JoeZydeco at 1:54 PM on June 10 [5 favorites]


Online video will still chug even on RISC-V, tho.
posted by slater at 1:57 PM on June 10


Why bother? The ISA is the least important part of a working product. CPU performance isn't an issue for most IoT "things". Sales come from low power consumption, good sensors, security, and a useable UI.

It does look good for research, though.
posted by monotreme at 2:03 PM on June 10 [1 favorite]


Interesting thing I learned from when this came up on HN, SPARC is already fully open. Kinda neat.
posted by yeahwhatever at 2:49 PM on June 10


Why bother? [...] It does look good for research, though.

Pretty much my thoughts on the matter. Having an entirely open stack is going to be great for computer architecture experimentation, but it's hard to imagine a commercial user wanting to save the ARM license fee so badly that they would take on the risk of an unproven platform with (one assumes) worse software tooling. Maybe that equation will change as RISC-V matures.

The main non-research interest I see is the (and I say this with love) tinfoil hat crowd who is worried that their processor has a backdoor from a three letter agency in it.
posted by jcreigh at 3:13 PM on June 10 [1 favorite]


I really want to get one of these Linux SoC's. It would be nice to not to have to run a full laptop to get some of the functionality on my LAN I use day to day (like Pihole and an external hard drive host/semi, but not really, NAS device.)
posted by Samizdata at 3:19 PM on June 10 [1 favorite]


It does make me sad to see that even though we now have a full compiler stack with umpteen languages at the top and LLVM at the bottom, which should mean that one should be able to compile anything and get it to run on anything, [*] we;re effectively stuck with ARM or 86. Coke or Pepsi.

So I do hope this takes off, along with OpenSPARC

[*] albeit only some processor stacks would run it well.
posted by ocschwar at 4:01 PM on June 10 [2 favorites]


Or from MIPS, which is still limping on as part of Imagination.

By "limping along" you mean massive widespread adoption in the embedded market. Hell, PowerPC is even doing well enough to float another Amiga platform.

Oracle's ruthless oversight managed to allow SPARC to finally find its legs as a firebreathing monster, and POWER has always been bad-ass.

This is something different than merely the marvel that is RISC. This is a modern microprocessor architecture that is open-source, and tuned to run Linux. It's aimed at the embedded market... to begin with, sure. But RISC has this marvelous ability to scale.

MIPS lives in cable modems and home wireless routers and set-top boxes, sure, but the same architecture was powering some of the most advanced and fast workstations, servers and supercomputers of the '90s. Only some corporate shenanigans involving Microsoft not worth retelling here unseated it from it's lofty place. (And even it wasn't jobbed as hard as the Alpha architecture was...)
posted by Slap*Happy at 4:26 PM on June 10 [2 favorites]


(like Pihole and an external hard drive host/semi, but not really, NAS device.)

Wait, you're using a laptop to run Pi-hole, instead of e.g. a Raspberry Pi which it was originally designed for? :-)
posted by effbot at 4:26 PM on June 10


By "limping along" you mean massive widespread adoption in the embedded market.

Yes, that was harsh; they lost workstation and never got into mobile, but a lot of the unglamorous invisible embedded stuff is MIPS-based.
posted by We had a deal, Kyle at 4:42 PM on June 10


I'm just excited to be able to play with an instruction set that makes sense again. I don't know if you've all taken a look at x86 lately, but the "instructions" are almost programs at this point. It's like someone just said "fuck it, this is hard, let's just let the compilers write the microcode".
posted by phooky at 4:59 PM on June 10 [2 favorites]


(like Pihole and an external hard drive host/semi, but not really, NAS device.)

Wait, you're using a laptop to run Pi-hole, instead of e.g. a Raspberry Pi which it was originally designed for? :-)


Yeah. As I do NOT have a Pi, but I wanted the security features of Pihole. It's an old Core 2 Duo 32bit ThinkPad running Debian Stable. Works fine, FWIW, and also does World Community Grid (which we need more people for the MetaFilter team in, but)...
posted by Samizdata at 5:05 PM on June 10 [1 favorite]


(Also, the screen has issues, so she is of limited use to me for normal use. Thank goodness TeamViewer is cross platform!)
posted by Samizdata at 5:06 PM on June 10


I'm just excited to be able to play with an instruction set that makes sense again. I don't know if you've all taken a look at x86 lately, but the "instructions" are almost programs at this point. It's like someone just said "fuck it, this is hard, let's just let the compilers write the microcode".

SCASQ representin'!
posted by Talez at 5:13 PM on June 10


It is officially supported by GCC

What about LLVM? That's probably as relevant, if not more, these days.
posted by acb at 5:17 PM on June 10


But does it support Plan 9?
posted by sammyo at 5:18 PM on June 10 [1 favorite]


But does it support Plan 9?

Yeah, I am not exactly seeing that as a real deal breaker. Just sayin'.
posted by Samizdata at 5:40 PM on June 10


It's like someone just said "fuck it, this is hard, let's just let the compilers write the microcode".

I think Alan Kay takes it one step further, and says that the programmer should have access to add microcode :) That's a single comment from this larger back and fourth which brings up RISC-V. While I felt qualified to say this recently, I certainly don't feel qualified to comment at that much, much deeper level. That conversation seems to suggest that letting programmers control microcode is a bit dated, even just thinking performance wise?

Turning the view over to OSs instead of CPUs for a second.. As a Windows power user and an engineer, I just remember back in the day being able to make QNX to do exactly what I wanted easily vs. how frustrated I am with Linux distros and Linux thinking every time I touch that stuff (examples omitted). Linux is a wonderful thing, to be sure! But, if all that work had been done around a micro-kernel, wouldn't we have even more utility from it today?

Of course one of the main arguments pro Micro Kernel (I assume, I'm not up on the turf war) is security--only run the stuff you need, prove it's secure, profit. Exposing microcode to the programmer must have exactly the opposite effect, to wit some of the recent Intel vulnerabilities.

Already well into the TLDR territory here of course, and it is feeling a little scattered and in need of editing too--If I had more time, I'd write a shorter post. I guess that's what happens when you try to take a deep vertical view of a big subject.. My point here is, I hope RISC-V people are thinking about this in an appropriately deep way to ensure that their contribution has maximal positive impact--as mentioned up thread, bad tapeout, $1 million etc.--any discussion at that level would be welcome!
posted by Chuckles at 6:01 PM on June 10 [2 favorites]


I really want to get one of these Linux SoC's

Seriously, get a BeagleBone. Black, Green, or the new Black Wireless or one of the many derivatives showing up. They're great systems and yeah, they're going to cost a little more than an RPi but they're serious pieces of hardware. You can get all the documentation and source code you want from TI unlike some of those other vendors (cough cough Broadcom)
posted by JoeZydeco at 7:02 PM on June 10 [1 favorite]


Ditto on the BeagleBone.

I have one in my house. All it's doing right now is getting my consumer NAS boxes to sync with each other and dedupe.

BUt when I travel, I turn on a TOR-based SSH server, and despite having no static public IP, I can back up to those NAS boxes from anywhere.
posted by ocschwar at 7:22 PM on June 10 [4 favorites]


Is that via hidden services? I've been looking at those as an alternative to dynamic DNS...

Been enjoying this thread - open vs closed, RISC vs CISC, microkernel vs kernel... ah, who says the state of the art in computer science moves quickly.

One of the abiding memories I have from the dawn of ARM is the explicit recognition by the architects that they were offloading a lot of the hard work onto the compiler - and that they thought this was the right thing to do. The hardware/software demarcation line is really interesting - in the old days, that was microcode, and now in DSP/FPGA-land it's much broader - and has anyone attempted a formal description of that? I'm not aware of anything. You can't respin hardwired silicon in the field, but hardwired silicon can be enormously more efficient than reconfigurable. Where do you decide to decide?

RISC-V is a really interesting experiment, not so much as some new ISA but in exploring what part an ISA plays in all the interlocking parts generating a complete stack worth developing on these days. Are there the right abstractions that enable the development of all the components in an SoC such that they're open enough to be safe but still create enough value for their creators that work will continue?
posted by Devonian at 8:01 PM on June 10 [1 favorite]


What about LLVM? That's probably as relevant, if not more, these days.

There is an LLVM backend that you can use, but my understanding is that the gcc-based tooling is more complete at the moment. But my impression was definitely that LLVM is something they're working on.
posted by jcreigh at 10:16 PM on June 10


I really want to get one of these Linux SoC's. It would be nice to not to have to run a full laptop to get some of the functionality on my LAN I use day to day

For the last three years my home router has been a Beaglebone Black running Debian Testing, and it is indeed a lovely thing.

I also have a couple of Raspberry Pis running OSMC, and I've recently acquired an ODROID-XU4 whose inbuilt gigabit Ethernet and USB-3 ports will let me turn it into a moderately high performance NAS some time soon.

These little machines are a lot of fun, and seeing new generations of them come out with fully detailed hardware documentation and at even lower cost because unencumbered by proprietary CPU core licensing can only be a good thing.
posted by flabdablet at 10:26 PM on June 10 [1 favorite]


Linux is a wonderful thing, to be sure! But, if all that work had been done around a micro-kernel, wouldn't we have even more utility from it today?

GNU Hurd
will be ready for prime time Real Soon Now.
posted by flabdablet at 10:31 PM on June 10 [1 favorite]


Why bother? The ISA is the least important part of a working product. CPU performance isn't an issue for most IoT "things". Sales come from low power consumption, good sensors, security, and a useable UI.

That very question is addressed on page 14 of the User-Level ISA Specification:
A question we have been repeatedly asked is “Why develop a new ISA?” The biggest obvious benefit of using an existing commercial ISA is the large and widely supported software ecosystem, both development tools and ported applications, which can be leveraged in research and teaching. Other benefits include the existence of large amounts of documentation and tutorial examples. However, our experience of using commercial instruction sets for research and teaching is that these benefits are smaller in practice, and do not outweigh the disadvantages:

• Commercial ISAs are proprietary. Except for SPARC V8, which is an open IEEE standard [2], most owners of commercial ISAs carefully guard their intellectual property and do not welcome freely available competitive implementations. This is much less of an issue for academic research and teaching using only software simulators, but has been a major concern for groups wishing to share actual RTL implementations. It is also a major concern for entities who do not want to trust the few sources of commercial ISA implementations, but who are prohibited from creating their own clean room implementations. We cannot guarantee that all RISC-V implementations will be free of third-party patent infringements, but we can guarantee we will not attempt to sue a RISC-V implementor.

• Commercial ISAs are only popular in certain market domains. The most obvious examples at time of writing are that the ARM architecture is not well supported in the server space, and the Intel x86 architecture (or for that matter, almost every other architecture) is not well supported in the mobile space, though both Intel and ARM are attempting to enter each other’s market segments. Another example is ARC and Tensilica, which provide extensible cores but are focused on the embedded space. This market segmentation dilutes the benefit of supporting a particular commercial ISA as in practice the software ecosystem only exists for certain domains, and has to be built for others.

• Commercial ISAs come and go. Previous research infrastructures have been built around commercial ISAs that are no longer popular (SPARC, MIPS) or even no longer in production (Alpha). These lose the benefit of an active software ecosystem, and the lingering intellectual property issues around the ISA and supporting tools interfere with the ability of interested third parties to continue supporting the ISA. An open ISA might also lose popularity, but any interested party can continue using and developing the ecosystem.

• Popular commercial ISAs are complex. The dominant commercial ISAs (x86 and ARM) are both very complex to implement in hardware to the level of supporting common software stacks and operating systems. Worse, nearly all the complexity is due to bad, or at least outdated, ISA design decisions rather than features that truly improve efficiency.

• Commercial ISAs alone are not enough to bring up applications. Even if we expend the effort to implement a commercial ISA, this is not enough to run existing applications for that ISA. Most applications need a complete ABI (application binary interface) to run, not just the user-level ISA. Most ABIs rely on libraries, which in turn rely on operating system support. To run an existing operating system requires implementing the supervisor-level ISA and device interfaces expected by the OS. These are usually much less well-specified and considerably more complex to implement than the user-level ISA.

• Popular commercial ISAs were not designed for extensibility. The dominant commercial ISAs were not particularly designed for extensibility, and as a consequence have added considerable instruction encoding complexity as their instruction sets have grown. Companies such as Tensilica (acquired by Cadence) and ARC (acquired by Synopsys) have built ISAs and toolchains around extensibility, but have focused on embedded applications rather than general-purpose computing systems.

• A modified commercial ISA is a new ISA. One of our main goals is to support architecture research, including major ISA extensions. Even small extensions diminish the benefit of using a standard ISA, as compilers have to be modified and applications rebuilt from source code to use the extension. Larger extensions that introduce new architectural state also require modifications to the operating system. Ultimately, the modified commercial ISA becomes a new ISA, but carries along all the legacy baggage of the base ISA. Our position is that the ISA is perhaps the most important interface in a computing system, and there is no reason that such an important interface should be proprietary. The dominant commercial ISAs are based on instruction set concepts that were already well known over 30 years ago. Software developers should be able to target an open standard hardware target, and commercial processor designers should compete on implementation quality.
It's tempting to dismiss all that as essentially this, but RISC-V is, to the best of my knowledge, the first fully open architecture that actually has the potential to better x86 on performance and ARM on power efficiency at a lower build cost than either.

x86 is the clear winner among currently available CPU designs on brute performance, but that's despite the ISA, not because of it. There's a hell of a lot of lipstick on the modern x86 pig, and putting some of that on a face that's rather more attractive to begin with might well yield quite a large win.
posted by flabdablet at 10:57 PM on June 10 [6 favorites]


If you want to mess about with real RISC V hardware now, there's the HiFive1. True, it's a very limited µc-class SOC.

  BeagleBone … serious pieces of hardware

While the inbuilt PRUs are neat, the “¼ the speed, 2× the price” BeagleBone as compared to the Raspberry Pi makes it a really tough sell. That, and the BB licence preventing commercial use makes it a non-starter, open or not. The new BB Blue robotics platform looks pretty cool, though.

All the cool ARM kids are on 96Boards these days.
posted by scruss at 6:59 AM on June 11


Any of these ARM boards come with enough SATA interfaces to build a nice NAS?

I can scavenge 86 hardware to do it, but the power bills make it unattractive.
posted by ocschwar at 7:13 AM on June 11 [1 favorite]


Seriously, get a BeagleBone. Black, Green, or the new Black Wireless or one of the many derivatives showing up. They're great systems and yeah, they're going to cost a little more than an RPi but they're serious pieces of hardware. You can get all the documentation and source code you want from TI unlike some of those other vendors (cough cough Broadcom)

I bought a few Cubieboards (the original one, and later the CubieTruck). They're based on Allwinner A-series SOCs, with generous sets of I/O pins and also SATA ports.

The last point was particularly critical for me; I was looking for something to attach a SSD full of MP3s to and use as a tiny, power-sipping music server running MPD on Linux. With a SATA-less board like the Pi or BeagleBoard, I'd have been stuck with the extra layer of jankiness of a USB interface for my disk.

The Cubieboard-based music box served me well for a few years, sitting in a corner, powered by the power brick from my old Sony PSP, but got replaced by a CubieTruck, largely because of its SPDIF audio output.
posted by acb at 7:16 AM on June 11


Any of these ARM boards come with enough SATA interfaces to build a nice NAS?

No but they're starting to come with M.2 interfaces where you can plug in an M.2 to four port SATA RAID adapter and run a NAS from that.
posted by Talez at 7:26 AM on June 11 [1 favorite]


I really want to get one of these Linux SoC's

Why not a Pine64? 2 gig of dram @ under $30. $99 for a laptop. $1.99 for a 1/2 gig postage stamp sized device. On github there is what purports to be netboot code for the pine64.

And the Pine64 is a tier 1 target for FreeBSD.

If you want faster - there is the hardkernel 8 way processor for $60ish and it has a USB 3.0 port.
posted by rough ashlar at 8:12 AM on June 11 [2 favorites]


Linux is a wonderful thing, to be sure! .... GNU Hurd will be ready for prime time Real Soon Now.

GNU/Linux may be nice but FreeBSD is the software stack for Playstation 4 and what powers Netflix along with being part of Apple's UNIX offering so that's alota bits being pushed by something that is not "a wonderful thing". It is also where a number of the developers of ZFS are using as a base and there is nothing better than a NAS where your data can auto-heal bad checksums AND do remote replications.

The limiting DRAM factor for these SoCs seems to be Microsoft's $0 cost IoT Windows 10 offering.
posted by rough ashlar at 8:19 AM on June 11


Why not a Pine64?

As I recall, the Allwinner A64 that Pine uses is not well documented, and ends up depending on a lot of binary blobage. It's the sort of thing that can lead to sadness in short order.
posted by wotsac at 8:31 AM on June 11


I bought a few Cubieboards (the original one, and later the CubieTruck). They're based on Allwinner A-series SOCs, with generous sets of I/O pins and also SATA ports.

The last point was particularly critical for me; I was looking for something to attach a SSD full of MP3s to and use as a tiny, power-sipping music server running MPD on Linux. With a SATA-less board like the Pi or BeagleBoard, I'd have been stuck with the extra layer of jankiness of a USB interface for my disk.


I was pleased to find my CubieTruck as well, because I too wanted something small and cheap to make a little NAS out of and the CubieTruck, with both gigabit Ethernet and inbuilt SATA, looked like the business. However, the actual throughput of both those ports has proved extremely disappointing and even though I've got the supplied heatsink attached to the CubieTruck SoC and I'm not overclocking it, it still tends to lock up occasionally for no apparent reason.

My BeagleBone Black, by contrast, has always been rock solid as have both my Raspberry Pi 2 model Bs.

I haven't played with my ODROID-XU4 enough to get much of a feel for it yet.
posted by flabdablet at 10:31 AM on June 11


Commercial ISAs are proprietary. Except for SPARC V8

Not really true. The patents on the Hitachi Super-H ISA have expired and there is an open implementation in the J-Core project. They're up to the SH2 level of functionality and working on the SH4, which is a very interesting little chip (one value of interesting being 32-bit + MMU with current ports of open source OSes). I'm rooting for them.
posted by kjs3 at 7:25 AM on June 12


Regarding commercial uptake, I just noticed that NVIDIA is in the process of adopting RISC-V to replace a custom RISC architecture they've been shipping. (slides, video)

Apparently the commercial off-the-shelf options didn't quite do that they wanted, so they went with RISC-V. To me this seems like the exception rather than the rule, but maybe the commercial future of RISC-V is brighter than I thought.
posted by jcreigh at 11:44 PM on June 12


« Older No Pain to Infinite Pain   |   The gorgeous line art abstractions of Andrew G.... Newer »


You are not currently logged in. Log in or create a new account to post comments.