The Blog

On August 15, we announced that regarded industry veteran Naveed Sherwani has joined SiFive as CEO. We invited him to share his vision for the company and his optimism for fomenting a revolution in the semiconductor industry.

Last week's blog entry discussed relocations and how they apply to the RISC-V toolchain. This week we'll be delving a bit deeper into the RISC-V linker to discuss linker relaxation, a concept so important it has greatly shaped the design of the RISC-V ISA. Linker relaxation is a mechanism for optimizing programs at link-time, as opposed to traditional program optimization which happens at compile-time. This blog will follow an example linker relaxation through the toolchain, demonstrate an example of how linker relaxations meaningfully improve the performance of a real program and introduce a new RISC-V relocation. We'll shy away from discussing the impact of linker relaxations on the RISC-V ISA, until another blog entry.

As we continue to expand our product offerings to better serve the rapidly growing RISC-V and SiFive community, we are always looking to work with companies (big and small) who share our vision.

Our first stop on our exploration of the RISC-V toolchain will be an overview of ELF relocations and how they are used by the RISC-V toolchain. We'll shy away from discussing linker relaxations and their impact on performance for a follow-up blog post so this doesn't get too long. The example has been carefully constructed to be unrelaxable as to avoid confusion. Additionally, we're only going to discuss the relocations used by statically linked executables, avoid discussing position independent executables and forget about thread local storage -- like linker relaxation, all of those warrant a whole post on their own. There will be a lot more to come about relocations in later blog posts.

Before we can board the RISC-V train, we'll have to take a stop at the metaphorical ticket office: our machine-specific GCC command-line arguments. These arguments all begin with -m, and are all specific to the RISC-V architecture port. In general, we've tried to match existing conventions for these arguments, but like pretty much everything else there are enough quirks to warrant a blog post. This blog discusses the arguments most fundamental to the RISC-V ISA: the -march, -mabi, and -mtune arguments.

I'm Palmer Dabbelt, a software engineer at SiFive and a maintainer of various RISC-V ports. I've been working with the RISC-V ISA for a few years, and it's finally starting to get ready for prime-time. We're not yet upstream in Linux or glibc, but hopefully by the end of the year we'll have the core set of system software in the relevant upstream repositories -- at which point distributions can begin porting to RISC-V and users can begin using our software. I started working with RISC-V before the user ISA had been finalized (at least v2 of the user ISA, the real one :)) and it's almost a bit scary how real things have gotten over the last few years.