DOCSLIB.ORG

1.5 the Rust Programming Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
1.5 the Rust Programming Language MASTER’S THESIS 2020 Transitioning from C to Rust in Media Streaming Development Samuel Johansson, Ludvig Rappe ISSN 1650-2884 LU-CS-EX: 2020-06 DEPARTMENT OF COMPUTER SCIENCE LTH j LUND UNIVERSITY EXAMENSARBETE Datavetenskap LU-CS-EX: 2020-06 Transitioning from C to Rust in Media Streaming Development Samuel Johansson, Ludvig Rappe Transitioning from C to Rust in Media Streaming Development (An Industrial Case Study) Samuel Johansson Ludvig Rappe [email protected] [email protected] February 25, 2020 Master’s thesis work carried out at Axis Communications AB. Supervisors: Elizabeth Bjarnason, [email protected] Jonathan Karlsson, [email protected] Srimanta Panda, [email protected] Examiner: Björn Regnell, [email protected] Abstract Rust uses static types, a strict compiler, and a unique ownership system, in order to make guarantees about memory safety without the use of a garbage col- lector and without sacricing performance. This paper presents a case study of evaluating a programming language tran- sition from C to Rust through the creation and usage of a Programming Language Transition Framework. We found the Programming Language Transition Framework to be a helpful tool for evaluating a programming language transition, but there is room for further improvements. We found Rust to provide a far superior developer experience, while still performing on par with C. However, Rust’s ownership system gives it a steep learning curve even for those with prior experience in programming. Given that the impact on performance is acceptable, and that build system integration can be done successfully, we deem it feasible to transition from C to Rust in this case. Keywords: Rust, C, Programming Language, Framework, Performance, Usability Acknowledgements First and foremost, we would like to thank Axis Communications AB for giving us the op- portunity and resources to conduct this Master’s Thesis. We would also like to thank our supervisors at Axis, Jonathan Karlsson and Srimanta Panda. They have provided us with invaluable help and feedback, mostly regarding Axis- specic tools and the build environment, but also concerning the report and the Program- ming Language Transition Framework. Last, but denitely not least, we would like to thank our supervisor at LTH, Elizabeth Bjarnason. She has helped us formalise the scope and methodology for this thesis and without her this thesis would not have been possible. In addition to this, she has also provided us with invaluable feedback regarding the report, how to conduct interviews, and much more. Contents 1 Introduction 1 1.1 Context . .1 1.2 Case description . .2 1.3 Purpose . .2 1.3.1 Research questions . .2 1.3.2 Approach . .3 1.4 The four levels aected by a programming language transition . .3 1.4.1 Execution level . .3 1.4.2 Programmer level . .3 1.4.3 Toolchain level . .3 1.4.4 Management level . .3 1.5 The Rust programming language . .4 1.5.1 Language features . .4 1.5.2 Cargo . .7 1.6 Contributions . .7 2 Related Work 9 2.1 Overview . .9 2.2 Impact on Execution level . 10 2.3 Impact on Programmer level . 11 2.4 Impact on Toolchain level . 12 2.5 Impact on Management level . 13 3 Research Method 15 3.1 Overview . 15 3.2 Literature study . 16 3.3 Programming Language Transition Framework . 16 3.4 Interviews . 17 3.5 Programming in Rust . 18 3.6 Focus Group . 19 CONTENTS 4 Programming Language Transition Framework (PLTF) 21 4.1 Factors . 21 4.1.1 Execution level . 21 4.1.2 Programmer level . 24 4.1.3 Toolchain level . 25 4.1.4 Management level . 27 4.2 Usage . 28 5 Results 29 5.1 Execution level . 29 5.1.1 Evaluation of performance . 29 5.1.2 Performance requirements . 37 5.1.3 Focus group insights . 38 5.2 Programmer level . 39 5.2.1 Evaluation of programming in Rust . 39 5.2.2 Developer perspective on programming languages . 46 5.2.3 Focus group insights . 49 5.3 Toolchain level . 49 5.3.1 Evaluation of Rust tools . 49 5.3.2 Common tools among developers . 50 5.3.3 Focus group insights . 51 5.4 Management level . 52 5.4.1 Evaluation of Rust’s impact on software projects . 52 5.4.2 The current impact on software projects . 54 5.4.3 Focus group insights . 56 6 Discussion 57 6.1 How to evaluate a transition from C to Rust (RQ1) . 57 6.1.1 Execution level . 58 6.1.2 Programmer level . 58 6.1.3 Toolchain level . 59 6.1.4 Management level . 59 6.2 Consequences of transitioning from C to Rust (RQ2) . 60 6.2.1 Execution level . 60 6.2.2 Programmer level . 61 6.2.3 Toolchain level . 63 6.2.4 Management level . 64 6.3 Challenges of transitioning from C to Rust (RQ3) . 65 6.3.1 Execution level . 65 6.3.2 Programmer level . 65 6.3.3 Toolchain level . 65 6.3.4 Management level . 66 6.4 Threats to validity . 66 6.4.1 Construct validity . 66 6.4.2 External validity . 66 6.4.3 Reliability . 67 CONTENTS 7 Conclusions 69 7.1 Summary . 69 7.2 Future research . 70 Bibliography 73 Appendix A Interview Guide 79 Appendix B Focus Group Guide 83 Appendix C Summary of the nal Programming Language Transition Framework 85 CONTENTS List of Figures 1.1 Hello, world! in Rust[37]. .4 3.1 An overview of the case study. 16 5.1 The execution times for the C and Rust version of the element, for dierent input sets. The execution times for each input set are the average of 100 runs. O and X mark the average execution time for C and Rust, respectively. 31 5.2 The execution times for the C and Rust version of an element written by the developers behind the framework, for dierent input sets. The execution times for each input set are the average of 100 runs. O and X mark the average execution time for C and Rust, respectively. 32 5.3 The latencies for the C and Rust version of the element for dierent input sets. The latencies for each input set are the average of 1000 runs. O and X mark the average latency for C and Rust, respectively. 33 5.4 The latencies for the C and Rust version of an element written by the devel- opers behind the framework, for dierent input sets. The execution times for each input set are the average of 1000 runs. O and X mark the average latency for C and Rust, respectively. 34 5.5 The maximum memory usage (maximum resident set size) for the C and Rust version of the element for dierent input sets. The memory usage for each input set is the average of 100 runs. The average maximum memory usage of each version has been rounded to the nearest integer. O and X mark the average memory usage for C and Rust, respectively. 35 5.6 The maximum memory usage (maximum resident set size) for the C and Rust version of an element written by the developers of the framework, for dierent input sets. The memory usage for each input set is the average of 100 runs. The average maximum memory usage of each version has been rounded to the nearest integer. O and X mark the average memory usage for C and Rust, respectively. 36 5.7 Attempting to mutably borrow two elds from a struct that is protected by a mutex. This code does not compile (see error message in Figure 5.8). 40 LIST OF FIGURES 5.8 The error message that is produced when attempting to compile the code in Figure 5.7. 41 5.9 A working version of the code in Figure 5.7. 41 5.10 The output from rustc when compiling a program containing a function that tries to return an integer value despite being declared to not return anything. 43 5.11 The output from GCC when compiling a program containing a function that tries to return an integer value despite being declared to not return anything. 43 List of Tables 4.1 A summary of the factors in the PLTF. 22 5.1 An overview of which methods yielded results for the dierent factors. 30 C.1 A summary of the factors in the Programming Language Transition Frame- work, including changes suggested by the focus group. The changes are in italic. 86 LIST OF TABLES List of Acronyms API Application Programming Interface PLTF Programming Language Transition Framework IDE Integrated Development Environment OSS Open Source Software RAII Resource Acquisition Is Initialisation LIST OF TABLES Chapter 1 Introduction Today, there exist more programming languages than you can shake a stick at, and their number continues to rise. Choosing which languages to use can be a dicult task, as dierent languages oer dierent features. That task is also made more dicult due to the fact that one language is seldom strictly better than another. Instead, languages are often better in some areas and worse in others. After having used a certain programming language for some time, a new language could be released that may be better suited for your application. How do you determine whether or not you should transition to this new language? In this chapter we present the context of the thesis, and briey describe Axis Communi- cations AB and its Streaming department. In addition, this chapter also gives a short intro- duction to the.
Load more

Recommended publications
  • Toolchains Instructor: Prabal Dutta Date: October 2, 2012
    EECS 373: Design of Microprocessor-Based Systems Fall 2012 Lecture 3: Toolchains Instructor: Prabal Dutta Date: October 2, 2012 Note: Unless otherwise specified, these notes assume: (i) an ARM Cortex-M3 processor operating in little endian mode; (ii) the ARM EABI application binary interface; and (iii) the GNU GCC toolchain. Toolchains A complete software toolchain includes programs to convert source code into binary machine code, link together separately assembled/compiled code modules, disassemble the binaries, and convert their formats. Binary program file (.bin) Assembly Object Executable files (.s) files (.o) image file objcopy ld (linker) as objdump (assembler) Memory layout Disassembled Linker code (.lst) script (.ld) Figure 0.1: Assembler Toolchain. A typical GNU (GNU's Not Unix) assembler toolchain includes several programs that interact as shown in Figure 0.1 and perform the following functions: • as is the assembler and it converts human-readable assembly language programs into binary machine language code. It typically takes as input .s assembly files and outputs .o object files. • ld is the linker and it is used to combine multiple object files by resolving their external symbol references and relocating their data sections, and outputting a single executable file. It typically takes as input .o object files and .ld linker scripts and outputs .out executable files. • objcopy is a translation utility that copies and converts the contents of an object file from one format (e.g. .out) another (e.g. .bin). • objdump is a disassembler but it can also display various other information about object files. It is often used to disassemble binary files (e.g.
    [Show full text]
  • Linux from Scratch Version 6.2
    Linux From Scratch Version 6.2 Gerard Beekmans Linux From Scratch: Version 6.2 by Gerard Beekmans Copyright © 1999–2006 Gerard Beekmans Copyright (c) 1999–2006, Gerard Beekmans All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: • Redistributions in any form must retain the above copyright notice, this list of conditions and the following disclaimer • Neither the name of “Linux From Scratch” nor the names of its contributors may be used to endorse or promote products derived from this material without specific prior written permission • Any material derived from Linux From Scratch must contain a reference to the “Linux From Scratch” project THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Linux From Scratch - Version 6.2 Table of Contents Preface
    [Show full text]
  • Anatomy of Cross-Compilation Toolchains
    Embedded Linux Conference Europe 2016 Anatomy of cross-compilation toolchains Thomas Petazzoni free electrons [email protected] Artwork and Photography by Jason Freeny free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 1/1 Thomas Petazzoni I CTO and Embedded Linux engineer at Free Electrons I Embedded Linux specialists. I Development, consulting and training. I http://free-electrons.com I Contributions I Kernel support for the Marvell Armada ARM SoCs from Marvell I Major contributor to Buildroot, an open-source, simple and fast embedded Linux build system I Living in Toulouse, south west of France Drawing from Frank Tizzoni, at Kernel Recipes 2016 free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 2/1 Disclaimer I I am not a toolchain developer. Not pretending to know everything about toolchains. I Experience gained from building simple toolchains in the context of Buildroot I Purpose of the talk is to give an introduction, not in-depth information. I Focused on simple gcc-based toolchains, and for a number of examples, on ARM specific details. I Will not cover advanced use cases, such as LTO, GRAPHITE optimizations, etc. I Will not cover LLVM free electrons - Embedded Linux, kernel, drivers - Development, consulting, training and support. http://free-electrons.com 3/1 What is a cross-compiling toolchain? I A set of tools that allows to build source code into binary code for
    [Show full text]
  • GCC Toolchain Eclipse Setup Guide
    !"#$ % '#((#()*!+,-.#)/$01234 GCC Toolchain Eclipse Setup Guide WP0001 Version 5 September 23, 2020 Copyright © 2017-2020 JBLopen Inc. All rights reserved. No part of this document and any associated software may be reproduced, distributed or transmitted in any form or by any means without the prior written consent of JBLopen Inc. Disclaimer While JBLopen Inc. has made every attempt to ensure the accuracy of the information contained in this publication, JBLopen Inc. cannot warrant the accuracy of completeness of such information. JBLopen Inc. may change, add or remove any content in this publication at any time without notice. All the information contained in this publication as well as any associated material, including software, scripts, and examples are provided “as is”. JBLopen Inc. makes no express or implied warranty of any kind, including warranty of merchantability, noninfringement of intellectual property, or fitness for a particular purpose. In no event shall JBLopen Inc. be held liable for any damage resulting from the use or inability to use the information contained therein or any other associated material. Trademark JBLopen, the JBLopen logo, TREEspanTM and BASEplatformTM are trademarks of JBLopen Inc. All other trademarks are trademarks or registered trademarks of their respective owners. Contents 1 Overview 1 1.1 About Eclipse ............................................. 1 2 Eclipse Setup Guide (Windows) 2 2.1 MSYS2 Installation .......................................... 2 2.2 Eclipse Installation .......................................... 11 2.3 Toolchain Installation ......................................... 16 2.4 Environment Variable Setup ..................................... 17 2.4.1 PATH Environnement Variable Setup ........................... 17 3 Eclipse Setup Guide (Linux) 22 3.1 Eclipse Installation .......................................... 22 3.2 Toolchain Installation ......................................... 27 3.3 GNU Make Installation .......................................
    [Show full text]
  • The GNU Toolchain for ARM Targets HOWTO Wookey Chris Rutter Jeff Sutherland Paul Webb
    This chapter contains information on building a GNU toolchain for ARM targets. The GNU Toolchain for ARM targets HOWTO Wookey Chris Rutter Jeff Sutherland Paul Webb This document contains information on setting up a GNU toolchain for ARM targets. It details both some pre-compiled toolchains which you can install, and how to compile your own toolchain, as either a native or a cross-compiler. 1. Credits This document is based on the work of Chris Rutter (now, sadly, deceased) who’s ’Building the GNU toolchain for ARM targets’ document was gospel for some time. It eventually became out of date so Wookey (<[email protected]>) updated it and gave it a substantion rewrite, adding the pre-built toolchain info at the same time. Paul Webb (<[email protected]>) did the initial conversion to DocBook, Phil 1 The GNU Toolchain for ARM targets HOWTO Blundell (<[email protected]>) provided info on the current state of the art and comments on the draft. Jeff Sutherland (<[email protected]>) then fixed the bits that were still wrong, and now maintains the doc, along with Wookey. Thanx to all. As well as being on-line as a stand-alone HOWTO, this document is also available as a chapter of the book: A ’Guide to ARMLinux for Developers’ (http://www.aleph1.co.uk/armlinux/thebook.html) 2 This chapter contains information on building a GNU toolchain for ARM targets. 1. Toolchain overview The toolchain actually consists of a number of components. The main one is the compiler itself gcc, which can be native to the host or a cross-compiler.
    [Show full text]
  • Exploring the Construction of a Domain-Aware Toolchain for High-Performance Computing
    Exploring the Construction of a Domain-Aware Toolchain for High-Performance Computing Patrick McCormick, Christine Sweeney, Nick Moss, Dean Prichard, Samuel K. Gutierrez, Kei Davis, Jamaludin Mohd-Yusof Los Alamos National Laboratory Los Alamos, NM, USA Abstract—The push towards exascale computing has sparked in such a way that we can maintain the benefits of a general- a new set of explorations for providing new productive pro- purpose toolchain but also maintain a domain awareness within gramming environments. While many efforts are focusing on the entire toolchain. Scout is a strict superset of the C and the design and development of domain-specific languages (DSLs), C++ languages and extends the general-purpose toolchain few have addressed the need for providing a fully domain-aware to maintain this domain context throughout the compilation toolchain. Without such domain awareness critical features for process. This step is critical to enable support for a produc- achieving acceptance and adoption, such as debugger support, pose a long-term risk to the overall success of the DSL approach. tive and complete, domain-aware environment for developing, In this paper we explore the use of language extensions to debugging, and profiling applications. design and implement the Scout DSL and a supporting toolchain infrastructure. We highlight how language features and the A. Domain-Specific Languages software design methodologies used within the toolchain play a significant role in providing a suitable environment for DSL Although domain-specific languages have only recently development. become popular in the high-performance computing (HPC) research community, they have been a common part of com- Keywords—Domain Specific Language, Compiler, Debugging, puting for decades [2].
    [Show full text]
  • Migrating to Swift from Flash and Actionscript
    ©Radoslava Leseva Adams & Hristo Lesev Migrating to Swift from Flash and ActionScript Radoslava Leseva Adams Hristo Lesev ©Radoslava Leseva Adams & Hristo Lesev Contents at a Glance About the Authors ...................................................................................................xxi About the Technical Reviewer ..............................................................................xxiii Acknowledgments .................................................................................................xxv Preface ................................................................................................................xxvii ■ Part I: Tool Migration ..........................................................................1 ■ Chapter 1: Setting Up Your Environment ............................................................... 3 ■ Chapter 2: Hello, Xcode! ...................................................................................... 15 ■ Chapter 3: Introducing the Xcode Debugger ....................................................... 39 ■ Chapter 4: Additional Development Tools ............................................................51 ■ Part II: Workfl ow Migration .............................................................. 69 ■ Chapter 5: “Hello, Swift!”—A Tutorial for Building an iOS App ...........................71 ■ Chapter 6: Adding a More Complex UI ...............................................................105 ■ Chapter 7: Concurrency .....................................................................................171
    [Show full text]
  • LFS-BOOK.Pdf
    Linux From Scratch Версия 7.3 Автор Gerard Beekmans Редакторы Matthew Burgess и Bruce Dubbs Перевод Иван Лабутин Linux From Scratch: Версия 7.3 by Автор Gerard Beekmans, Редакторы Matthew Burgess и Bruce Dubbs, Перевод Иван Лабутин Copyright © 1999-2013 Gerard Beekmans Copyright © 1999-2013, Gerard Beekmans Все права защищены. Эта книга выпущена под лицензией Creative Commons License. Команды для компьютера могут быть извлечены из книги под лицензией MIT License. Linux® зарегистрированная торговая марка Linus Torvalds. Linux From Scratch - Версия 7.3 Содержание Пролог ......................................................................................................................... viii i. Предисловие ........................................................................................................ viii ii. Кому адресована эта книга? ............................................................................... ix iii. Целевые архитектуры LFS .................................................................................. x iv. LFS и стандарты .................................................................................................. x v. Пояснения к выбранным пакетам ..................................................................... xii vi. Необходимые знания ....................................................................................... xvii vii. Требования к хост-системе ........................................................................... xviii viii. Соглашения, используемые в книге .............................................................
    [Show full text]
  • Entertainment Software Association
    Long Comment Regarding a Proposed Exemption Under 17 U.S.C. 1201 [ ] Check here if multimedia evidence is being provided in connection with this comment Item 1. Commenter Information The Entertainment Software Association (“ESA”) represents all of the major platform providers and nearly all of the major video game publishers in the United States.1 It is the U.S. association exclusively dedicated to serving the business and public affairs needs of companies that publish computer and video games for video game consoles, personal computers, and the Internet. Any questions regarding these comments should be directed to: Cory Fox Simon J. Frankel Ehren Reynolds Lindsey L. Tonsager ENTERTAINMENT SOFTWARE ASSOCIATION COVINGTON & BURLING LLP 575 7th Street, NW One Front Street Suite 300 35th Floor Washington, DC 20004 San Francisco, CA 94111 Telephone: (202) 223-2400 Telephone: (415) 591-6000 Facsimile: (202) 223-2401 Facsimile: (415) 591-6091 Item 2. Proposed Class Addressed Proposed Class 19: Jailbreaking—Video Game Consoles Item 3. Overview A. Executive Summary Proposed Class 19 is virtually identical to the video game console “jailbreaking” exemption that the Librarian denied in the last rulemaking proceeding. As in the last proceeding, “the evidentiary record fail[s] to support a finding that the inability to circumvent access controls on video game consoles has, or over the course of the next three years likely would have, a substantial adverse impact on the ability to make noninfringing uses.”2 Proponents offer no more than the same de minimis, hypothetical, 1 See http://www.theesa.com/about-esa/members/ (listing ESA’s members).
    [Show full text]
  • RISC-V Software Ecosystem
    RISC-V Software Ecosystem Andrew Waterman UC Berkeley [email protected]! Tethered vs. Standalone Systems § Tethered systems are those that cannot stand alone - They depend on a host system to boot - They may not have complete I/O facilities § RISC-V HW implementations at Berkeley are test chips and so are tethered § Working on software infrastructure for both kinds of systems 2 Tethered RISC-V Systems RISC-V Target x86 Host (runs proxy kernel) HTIF (runs frontend server) § Proxy Kernel runs on RISC-V target machine - Supports a single user process - I/O-related system calls are forwarded to host - Implements subset of Linux ABI § Frontend Server runs on host machine - Executes I/O syscalls on behalf of proxy kernel - Serves as boot loader (loads kernel ELF image into target memory) § Host-Target Interface (HTIF) - Simple protocol for host to interact with target state 3 Software Implementations of RISC-V ISA Spike ISA Simulator § ISA interpreter; models tethered RISC-V systems § Named for golden spike that marked completion of transcontinental railroad - Designed to be the golden model for functional correctness § Reasonably fast but designed to be very easy to modify § Github: https://github.com/ucb-bar/riscv-isa-sim 5 ANGEL JavaScript-based ISA Simulator § Simulates an RV64IMA system § Boots Linux § Implemented purely client-side in JavaScript § Designed for education & outreach § Challenging to implement when only numeric type is 64-bit IEEE float! § 13 MIPS & rising on Chrome 39.0 § riscv.org/angel 6 QEMU Full-System Simulator § RV64G port of popular full-system simulator § Device support - 8250 UART console - Virtio for network, disks, etc.
    [Show full text]
  • A Compiler Toolchain for Data Intensive Scientific Workflows
    A COMPILER TOOLCHAIN FOR DISTRIBUTED DATA INTENSIVE SCIENTIFIC WORKFLOWS A Dissertation Submitted to the Graduate School of the University of Notre Dame in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Peter Bui Dr. Douglas Thain, Director Graduate Program in Computer Science and Engineering Notre Dame, Indiana June 2012 © Copyright by Peter Bui 2012 All Rights Reserved A COMPILER TOOLCHAIN FOR DISTRIBUTED DATA INTENSIVE SCIENTIFIC WORKFLOWS Abstract by Peter Bui With the growing amount of computational resources available to researchers today and the explosion of scientific data in modern research, it is imperative that scientists be able to construct data processing applications that harness these vast computing systems. To address this need, I propose applying concepts from tradi- tional compilers, linkers, and profilers to the construction of distributed workflows and evaluate this approach by implementing a compiler toolchain that allows users to compose scientific workflows in a high-level programming language. In this dissertation, I describe the execution and programming model of this compiler toolchain. Next, I examine four compiler optimizations and evaluate their effectiveness at improving the performance of various distributed workflows. Afterwards, I present a set of linking utilities for packaging workflows and a group of profiling tools for analyzing and debugging workflows. Finally, I discuss modifi- cations made to the run-time system to support features such as enhanced prove- nance information and garbage collection. Altogether, these components form a compiler toolchain that demonstrates the effectiveness of applying traditional compiler techniques to the challenges of constructing distributed data intensive scientific workflows. CONTENTS FIGURES .
    [Show full text]
  • Getting the Renesas Synergy™ Platform Toolchain up and Running
    BASICS OF THE RENESAS SYNERGY TM PLATFORM Richard Oed 2020.04 02 CHAPTER 4 GETTING THE RENESAS SYNERGY™ PLATFORM TOOLCHAIN UP AND RUNNING CONTENTS 4 GETTING THE RENESAS SYNERGY™ PLATFORM TOOLCHAIN UP AND RUNNING 03 4.1 Introduction to the Synergy Solutions Gallery 03 4.2 Downloading and Installing e2 studio and the Synergy Software Package 04 4.2.1 Download of e2 studio and the SSP 04 4.2.2 Installing the Tools Using the Platform Installer 05 4.2.3 Installing the Tools Using the Standalone Installers 07 4.2.4 Starting for the First Time 10 4.2.5 Keeping Your Installation Up-To-Date 11 4.3 Downloading and Installing the IAR Embedded Workbench® for Renesas Synergy™ 12 4.3.1 Download of the Various Installers 12 4.3.2 Installing the Toolchain Using the Platform Installer 13 4.3.3 Installing the Toolchain Using the Standalone Installers 15 4.3.4 Starting for the First Time 17 4.3.5 Keeping Your Installation Up-To-Date 20 4.4 Installing the IAR Compiler into e2 studio™ 20 4.5 Summary 20 Disclaimer 21 03 4 GETTING THE RENESAS SYNERGY™ PLATFORM TOOLCHAIN UP AND RUNNING What you will learn in this chapter: ¡ Where to get and how to install the toolchain(s) for the Synergy Platform. ¡ Steps to be performed during the first startup of the Integrated Solutions Development Environment (ISDE). In this chapter we will download and install the tools necessary to work on software projects for the Synergy Platform. You have the choice between two different toolchains: The e 2 studio ISDE with the Synergy Software Package (SSP) or the IAR Embedded Workbench® for Renesas Synergy™ (IAR EW for Synergy) together with the Synergy Standalone Configurator (SSC) and the SSP.
    [Show full text]