Jeremy Bennett

The Open Hardware Group (https://www.openhwgroup.org/) is a large industry/academic consortium developing a family of fully open source, commercial grade RISC-V cores, branded as CORE-V. These are supported by a full software ecosystem.

In this talk we will look at the challenges of developing a vendor specific software ecosystem, how this ecosystem relates to the official upstream projects, and particularly the technical challenges in developing, maintaining and upstreaming vendor specific software.

Although CORE-V is a completely standard RISC-V architecture, it supports a large number of custom ISA extensions, and it is the support of these extensions that creates most of the challenge. Many of these extensions come from the PULP research group at ETH Zürich, but some are pre-freeze versions of what will become standard RISC-V extensions.

The upstream projects generally provide mechanisms to support vendor specific variants, for example by use of the vendor field in the target triplet. Thus rather than the generic riscv32-unknown-elf-gcc compiler, we can have the riscv32-corev-elf-gcc compiler. However this requires modifications to the code to use this information to control when CORE-V specific functionality is to be enabled, and this talk will explore these. In one specific case (vendor specific relocations), we are waiting on standardization from the RISC-V psabi committee, but otherwise this is all using well proven existing technology.

The work has also served to expose gaps in the upstream projects. For example, while versioning of ISA extensions is standardized, the code base for the GNU assembler lacks the infrastructure to handle this. Similarly many ISA extensions require builtin (intrinsic) function support, but the upstream tools have only a handful of builtin functions, and the infrastructure for RISC-V builtins is very small.

The talk cannot cover detail of every tool and operating system being developed, so will concentrate particularly on the CORE-V GCC tool chain. However we will draw parallels with the work going on in CORE-V specific simulators and in CORE-V specific operating systems.

At the GNU Tools Cauldron we held a panel discussion on how GCC and LLVM can work together. The video of that discussion can be seen at https://www.youtube.com/watch?v=PnbJOSZXynA. We proposed a similar discussion to be held at the LLVM Developers Meeting, but the reviewers suggested that such a discussion would be better held as part of the FOSDEM LLVM Devroom, since that was more likely to attract GNU developers as well.

We wish to explore how Clang/LLVM and the GCC can work together effectively.

The participants will explore opportunities for co-operation between the projects. Areas to be covered include:

• collaboration on issues related to language standards, changes to existing standards or implementing new ones;
• maintaining ABI compatibility between the compilers;
• interoperability between tools and libraries e.g. building with clang and libstdc++ or building with gcc and linking with lld; and
• communication channels for developers via bugzilla or mailing lists.

The compilers are part of wider projects providing all the components of the tool chain, and we anticipate the discussion will roam to low level utilities, source code debuggers and libraries as well. We hope the output of the discussion will inform future work between the two communities.

The panelists are

• Arnaud de Grandmaison is a Director of the Linux Foundation, currently working at Arm. He has been developing with LLVM for his last 10+ years, to support custom architecture or enable architecture exploration.
• Pedro Alves is a global mainainer and major contributor to the GNU Debugger (GDB)
• Tom Tromey is a long-time GNU maintainer. He wrote Automake, worked on gcj and Classpath, and now is a GDB maintainer.

Dhrystone and Coremark have been the defacto standard microcontroller benchmark suites for the last thirty years, but these benchmarks no longer reflect the needs of modern embedded systems. Embench™ was explicitly designed to meet the requirements of modern connected embedded systems. The benchmarks are free, relevant, portable, and well implemented.

In this talk we will present the results of benchmarking Clang/LLVM for various IoT class architectures using Embench. We shall look at - how code size and speed varies across architectures when compiling with Clang/LLVM. - how Clang/LLVM performance has evolved over time - how Clang/LLVM compares against other compilers, notably GCC - the effectiveness of various compilation techniques (LTO, Combined Elimination, Profile Guided Optimization)

The aim is not to show which architecture or compiler is best, but to gain insight into the detail of the compilation process, so that all compilers and architectures can learn from each other.

RISC-V is an increasingly popular architecture for embedded systems. For such systems, compiled code density is a critical factor, particularly for deeply embedded and low power systems, where memory may be very constrained. Architectures in this space are often designed to improve code density. Thus ARM has its Thumb-2 instructions and RISC-V has its compressed instructions.

If compiler tool chains are to generate compact code, we need to be able to measure how well we are doing. In this talk I shall present measurements of code density for 32-bit RISC-V, ARM and ARC architectures using the GCC and Clang/LLVM compiler tool chains using the BEEBS benchmark suite for deeply embedded systems (http://beebs.eu/). I shall show how confounding factors (such as emulation library implementation and C run-time startup) can be eliminated from such measurements, to ensure the results are meaningful.

The purpose of this exercise is not to show that any one architecture is "best" but to provide insight which will drive compiler optimization for code density. I shall use the data to highlight areas where the RISC-V compiler tool chain can be improved, drawing on customer work carried out by Embecosm during 2018.

In this talk we describe our experience of bringing up embedded FreeBSD for a heterogeneous 32/64-bit RISC-V system using LLVM, which was more difficult than you might expect. We look at the practical engineering steps needed to bring up an embedded operating system where many of the key components are not fully mature. The result is a reference embedded FreeBSD implementation for RISC-V, freely available to the community.

We were tasked with bringing up and testing embedded FreeBSD on a custom five-core 32/64-bit RISC-V processor using LLVM. Given FreeBSD has already been ported to RISC-V and LLVM is the standard BSD C/C++ compiler surely this should be easy.

But it wasn't. LLVM for RISC-V is still relatively immature, particularly for 64-bit. FreeBSD runs on symmetric multi-core 64-bit QEMU RISC-V, but not on embedded systems and not on heterogeneous multicore systems.

In this talk we'll go through the steps needed to bring up a functioning embedded FreeBSD system on multi-core heterogeneous RISC-V system. Our target hardware was not available at the start of the project, so we used the generally available HiFive Freedom Unleashed board. The result is a reference embedded FreeBSD implementation for RISC-V, freely available to the community.

This is not a talk about the deep internals of FreeBSD, but about the practical engineering steps needed to bring up an embedded operating system where many of the key components are not yet fully mature.

Security is an every increasing concern across the computing industry, most recently in the emerging Internet of Things market. The compiler is the one tool that sees just about every piece of code, and is a position to both check for security and improve security. LLVM cannot magically write secure code, but it can help a professional programmer write really good secure code.

In this talk we will introduce our joint research program with Bristol University to add such features to LLVM. This project is still in its early stages, but we will present our initial work and discuss our future plans. A particular goal is community feedback on the priorities for this research program.

Security is an every increasing concern across the computing industry, most recently in the emerging Internet of Things market. LLVM cannot magically write secure code, but it can help a good programmer write secure code.

The Leakage Aware Design Automation project is an EPSRC funded programme running over four years at Bristol University led by Elizabeth Oswald and Dan Page. It is looking at how all aspects of software tooling can improve security of systems, particularly by minimizing information leakage. An important part of this project is extending compiler technology, and the programme includes a postdoctoral post to research this area.

Embecosm are the "industrial supporters" of this project. Our role is to take the research ideas and make them work in real compilers - including LLVM. Some of this will be about guiding the programmer - warning of coding styles that are insecure. The other part of the project is providing assistance to the programmer in implementing advanced cryptographic techniques.

Many of the areas the compiler can warn about are related to information leakage which can be detected by variation in power usage, program timing or memory access. Where we see control flow, cycle times or memory accesses which depend on critical variables (such as cryptographic keys). Such variables can be marked with a "sensitive" attribute and the compiler warn if they or their aliases are involved in control flow, impact cycle timing or affect memory access.

There are a great many techniques that users can adopt to make their code more secure. Some of these are straightforward for the compiler to implement. For example ensuring that critical functions clear their stack frame on return or longjmp.

It is not difficult to slice the top off a memory chip and use a scanning electron microscope to read values. A (relatively) easy way to scan for candidate cryptographic keys. Bit-splitting defends against this, but scattering individual bits of critical values throughout memory, combining them on the fly for a calculation and scattering them back out to memory. By hand this is laborious in the extreme, but the compiler can reduce this to a simple "bit-split" attribute on a variable.

Other attacks use intense radiation to disrupt a processor or memory. The hope is that a critical variable will be impacted. To fix this, code will often repeat important operations. A standard compiler optimizer will promptly remove such operations, so such code is used unoptimized. But it would be much better to tell the compiler which bits of code to leave in place. Or even better to identify code at danger and let the compiler insert the duplicate operations automatically.

There are many other techniques which we hope to explore in this project, including - atomicity - balancing control flow paths to minimize information leakdave - shuffling - varying the time at which particular instructions are executed - algorithmic variation - using different algorithms at random to perform operations. - machine learning and superoptimization to minimize information leakage? - automated identification of instruction set extensions to improve cryptographic robustness?

Some of these techniques are not new, but none are yet in mainstream compilers. We plan to add these features and new ideas which our academic colleagues are researching. The project is still in its early stages and the purpose of this talk is to raise awareness and get community feedback on some of the areas we will be working on, and suggestions for other areas to consider.

Bring along your applications and have their energy consumption measured on a pre-instrumented Arduino, Raspberry Pi or BeagleBone. Alternatively, bring along your own design on a breadboard and we'll hook up a PowerSense shield to measure the energy usage.

This introductory talk will set the context for the day. It will take a look at how energy efficiency is the major challenge for systems developers, and will then provide an overview of a number of open source projects that demonstrate how the energy efficiency of the entire system can be significantly improved.

Energy efficiency of systems - hardware and software - matters. For the smallest energy scavenging systems it is a matter of eking out the picowatts. For handheld consumer electronics it is battery life that is a key product differentiator. Even for mains powered consumer devices, energy efficiency affects utility bills. And for datacenters run by the Googles and Facebooks of this world, more efficient systems mean fewer new power stations need to be built.

This dev room is dedicated to the whole subject of energy efficiency in computer systems. This introductory talk provides an overview of all the approaches being taken to address this issue, particularly looking at how free and open source hardware and software is taking a leading role. It will provide a guide to the remaining sessions of the day, including the hands-on workshop where participants will have the opportunity to work with energy measurement hardware for themselves.

Despite a decade of innovative development, and despite improvements in battery technology, a modern smartphone needs recharging far more often than its turn-of-the-century predecessor. Yet the blame cannot be laid at the door of hardware engineers; the problem lies in the software. Fortunately free and open source technology is racing to the rescue. With this talk we aim to promote energy efficiency to a first class software design goal.

Modern silicon chips are able use very little power. Multiple clock domains, clock gating and dynamic voltage and frequency control have all served to make modern hardware highly energy efficient. Yet all that can be destroyed by the software running on the chip. In this presentation we will look at how the entire software design process needs reworking to bring the software engineering team into low power design from day one. Central to this is the availability of good software development tool support, debug functionality, and energy transparency from hardware to software. We will explain why developers should consider energy consumption as a primary design goal for software, give an insight into how energy consumption of code can be measured and present some of the tools we are currently working on to enable more energy efficient software development.

Open source is playing a central role in giving developers access to tools that enable energy efficient design. We will present details of MAGEEC, a UK government funded project to build the next generation of open source machine learning compilers, which will optimize for energy efficiency. We will present the compiler framework, and the energy measurement hardware, both of which are fully open source. We will also introduce the EU ENTRA project, which aims to promote energy aware system development by enabling energy transparency from the hardware to the software in a computer system. This will be achieved using advanced energy modelling and program analysis techniques to make predictions of energy usage available to the system developer and to the software engineering tool chain. We will present energy consumption analysis tools developed in the ENTRA project.

The talk leads into the Energy Efficient Computing devroom happening on Sunday.