Risc-v and the birth of the new computer architecture ecosystem

RISC-V AND THE BIRTH OF THE NEW COMPUTER ARCHITECTURE ECOSYSTEM

Hard ware Enablement: Software Makes Hardware Useful

It is not often you get to watch the birth of a new computer architecture ecosystem unfold. Announced in 2010, RISC-V has recently seen an increase in momentum as measured in the public development activity of software required to make RISC-V useful. This may seem like an odd way to measure momentum (sorry physicists!), but these are necessary steps for wider adoption of the new open instruction set architecture. As these tools mature they will form the basis for enabling more exotic variants and implementations of the RISC-V architecture. Note that there is already shipping RISC-V hardware in the form of a development kit from SiFive.

RISC-V Hello World and Instruction Trace

To add new hardware support to an existing toolchain or operating system simply pick a recent snapshot of the codebase, make a local development copy, make the required changes, and release a toolchain and OS. If you would like to follow along with the early RISC-V software you can see the work in progress here in the RISC-V git repos.

Upstreaming in Open Source: Reducing the Maintenance Burden

As the RISC-V software tools mature and stabilize, they are very likely to be submitted upstream so they become part of the mainline development for that particular tool or OS. Upstream acceptance is important because maintaining these codebases out-of-tree is more work than maintaining the codebase upstream.

The upstream public codebase changes over time and new releases are made. The out-of-tree tools team is then forced to bring all of the new public codebase changes into the out-of-tree codebase to keep the tool current with bug fixes and other desirable changes. Over time, this can get very hard or even impossible if the interfaces change or go away.

New hardware doesn’t do anything without software. The shortest path to making a new architecture useful is not to write new assemblers, compilers and related software tools but instead extend existing software tools like binutils and gcc so that they support the new architecture. Extending these tools to support a new architecture is called adding a backend port.

If instead your changes are accepted upstream, maintenance is now everyone’s responsibility: Proposed changes to that codebase must go through code review and testing to make sure that they do not break things. Not only is this less work overall, ideally the maintenance workload is distributed on all the volunteers maintaining the project, not just the team responsible for your part of it.

If instead your changes are accepted upstream, maintenance is now everyone’s responsibility: Proposed changes to that codebase must go through code review and testing to make sure that they do not break things. Not only is this less work overall, ideally the maintenance workload is distributed on all the volunteers maintaining the project, not just the team responsible for your part of it.

Other open source tool and OS efforts have failed to get their changes accepted upstream because, while the work required is highly technical, it also involves understanding how to work with the existing codebase and the existing development community. Essentially you want to understand and adhere to the existing norms of the project’s development community and make your case that your implementation is also technically sound. To paraphrase an old friend, you want to make it easy for the existing project maintainers to give you an “A” and accept your proposed changes.

Адрес публикации: https://www.prodlenka.org/metodicheskie-razrabotki/324409-risc-v-and-the-birth-of-the-new-computer-arch