Last Week in RISC-V: Sept 14, 2018

GNU Tools Cauldron Trip Report, Part 2

I was at the GNU tools cauldron last week. I summarized the two BoF sessions in last week's entry. While that was the extent of the RISC-V specific events at the cauldron, I attended the remainder of the cauldron where there were some great sessions.

Vector ABI

I attended the aarch64 BoF session, where one of the major issues at hand is to implement a system ABI that allows argument passing via SVE registers. This brought up a mirror in RISC-V land: a system ABI for the V extension. We had some discussions in person, which Richard Henderson has summarized on the GCC mailing list. Designing an ABI for the V extension will be a long and interesting project, but the nice thing here is that we get to co design the system ABI along with the V ISA extension in order to ensure we can build something solid.

16-bit Bytes

I ran into Simon Marchi at lunch on Sunday where he asked an off-the-wall question about building a RISC-V system that was 16-bit addressable. It turns out he was running an entire non-8-bit bytes BoF, where I learned that there are a whole bunch of out-of-tree ports of the GNU toolchains for architectures that aren't 8-bit addressable. Most of these architectures tend to be one-off DSPs and therefore aren't publicly discussed, which results in a lot of duplicated work: since there are no upstream architectures in GDB or GCC that have non-8-bit bytes everyone has to keep fixing the same bugs for every port.

The main headache here is that none of the companies with these proprietary DSPs are willing to share the ISA manuals or simulators, and that you usually can't even buy the hardware -- they're only for internal projects. Embecosm has explored creating a virtual architecture called AAP that was designed to be as wacky as possible, with the idea being that an upstream AAP port would allow the out-of-tree ports to publicly discuss their oddities without releasing the details of their internal ISAs, thus allowing the developers of these ports to ensure their patches remaining working.

At this point what had started as a silly discussion over lunch had turned into something more reasonable: rather that building a virtual ISA with 16-bit bytes, why not just create a custom RISC-V based ISA with 16-bit bytes? The advantage here is that the ISA is fairly easy to write down, which allows everyone to get on the same page -- the other concrete ISAs in this space are all secret, which is what's really driving the headache of supporting them in software in the first place. Of course, all the software would be horribly broken on such an ISA (and I don't know anyone who would have the time to make it work), but at least it's somewhere to start.

The result was a somewhat interesting discussion, and a possible place where having an open standard ISA could dramatically improve the state of the open source software ecosystem for everyone. It's also a big pile of work that I'm sure I'll regret having brought up in a decade :)

A CGEN-Based RISC-V Backend

One session that I missed (due to jet lag) but wanted to attend was the CGEN Tutorial, which is a tool designed to make writing backends for GNU tools easy. A prototype RISC-V backend based on CGEN was presented, which is a natural fit for the extendability of the RISC-V ISA.

Bay Area RISC-V Meetup

I presented at the Bay Area RISC-V Meetup at RAMBUS on Wednesday, which they did a great job of running. The interest in RISC-V has been rapidly growing, and it is always fun to see all the new things going on at every one of these meetups. There were video cameras at the event, so I assume there will eventually be videos posted. More information, as well as how to sign up for future meetups, can be found an the September Bay Area RISC-V Meetup Page.

Deprecating riscv-tools

Andrew opened a pull request for riscv-tools that marks it as deprecated in favor of the RISC-V tools being distributed by the various distributions. This is a pretty major event for the RISC-V ecosystem: riscv-tools is essentially a tiny distribution that we've been maintaining on our own for the better part of a decade, and deprecating it means that we're finally well enough supported in the software ecosystem that we can rely on others to maintain distributions of RISC-V tools.

If your favorite distribution doesn't ship RISC-V tools then now is the time to get those packages in!

Events

• September 21st: ORConf hosted by the Gdańsk University of Technology in Gdańsk, Poland.
• October 18: RISC-V Day Tokyo hosted by Keio University in Tokyo, Japan.
• October 22: RISC-V BoF at Embedded Linux Conference + IoT Summit Europe hosted by The Linux Foundation in Edinburgh, UK.
• November 13: RISC-V Microconference at Linux Plumbers Conference in Vancouver, Canada.
• December 3: RISC-V Summit in Santa Clara, CA.

Contributing to "Last Week in RISC-V"

Like everything else in the RISC-V ecosystem, this won't be possible as just a one-man effort. I'm hosting the sources at github.com/sifive/last-week-in-risc-v, so if you're comfortable editing them feel free to open a pull request. If you don't want to get involved in GitHub then you're also welcome to just mail me patches or blurbs for inclusion and I can merge them together.

I don't really have any specific criteria as to what will or won't be included. Part of the reason I'm doing this is that the RISC-V ecosystem has started to get big enough that there are huge sections of it that I know nothing about, so I think the starting criteria will be "anything I'm interested enough in to want to read" and we'll just go from there!