DOCSLIB.ORG

Forth 7 Cross Compiler with VFX Code Generation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Forth 7 Cross Compiler with VFX Code Generation Forth 7 Cross Compiler with VFX code generation Microprocessor Engineering Limited Copyright c 1998-2010, 2011, 2012, 2013, 2015, 2016 Microprocessor Engineering Limited Published by Microprocessor Engineering MPE VFX Forth Cross Compiler User manual Manual revision 7.5 1 October 2016 Software Software version 7.5 For technical support Please contact your supplier For further information MicroProcessor Engineering Limited 133 Hill Lane Southampton SO15 5AF UK Tel: +44 (0)23 8063 1441 Fax: +44 (0)23 8033 9691 e-mail: [email protected] [email protected] web: www.mpeforth.com i Table of Contents 1 Licence terms :::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.1 Distribution of application programs ::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Evaluation and Lite compilers ::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.3 Warranties and support:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2 Installing the system :::::::::::::::::::::::::::::::::::::::::: 3 2.1 System requirements :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.2 Installation and configuration :::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.2.1 Windows ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 2.2.2 Linux and Mac OS X ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 2.3 Release notes :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 3 System components ::::::::::::::::::::::::::::::::::::::::::: 9 3.1 MPE Forth cross-compiler :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 10 3.2 Standalone target Forth :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 10 3.3 Umbilical Forth :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 3.4 Documentation directory ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 3.5 Control files :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 3.6 Compiler versions :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 11 3.7 Learning Forth ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 12 4 How Forth is documented ::::::::::::::::::::::::::::::::::: 13 4.1 Forth words :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 13 4.2 Stack notation ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 14 4.3 Input text :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 15 4.4 Other markers:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 16 5 Configuring with macros::::::::::::::::::::::::::::::::::::: 17 5.1 Text macros:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 17 5.2 Directory structures :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 18 6 Generating a target Forth kernel ::::::::::::::::::::::::::: 19 6.1 Is your target already supported? ::::::::::::::::::::::::::::::::::::::::::::::::: 19 6.2 The control file ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 19 6.3 Memory map::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 19 6.3.1 Setting the memory map :::::::::::::::::::::::::::::::::::::::::::::::::::: 19 6.3.2 Start and end of Flash::::::::::::::::::::::::::::::::::::::::::::::::::::::: 20 6.3.3 Start and end of initialised RAM :::::::::::::::::::::::::::::::::::::::::::: 20 6.3.4 Start and end of uninitialised RAM :::::::::::::::::::::::::::::::::::::::::: 20 6.3.5 Setting the compilation areas :::::::::::::::::::::::::::::::::::::::::::::::: 21 6.4 Modifying the serial line drivers :::::::::::::::::::::::::::::::::::::::::::::::::: 21 6.4.1 Interrupt driven ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 21 6.4.2 Polled ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 22 6.4.3 Initialising the serial line::::::::::::::::::::::::::::::::::::::::::::::::::::: 22 6.4.4 Sending a character to the host :::::::::::::::::::::::::::::::::::::::::::::: 22 6.4.5 Receiving a character from the host :::::::::::::::::::::::::::::::::::::::::: 22 ii Forth 7 Cross Compiler 6.4.6 Generic I/O device table::::::::::::::::::::::::::::::::::::::::::::::::::::: 23 6.5 Setting up the system :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 23 6.5.1 Setting up the hardware ::::::::::::::::::::::::::::::::::::::::::::::::::::: 23 6.5.2 Setting up the software :::::::::::::::::::::::::::::::::::::::::::::::::::::: 24 6.6 Cross-compiling :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 24 6.6.1 Creating an image ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 24 6.6.2 Log display :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 24 6.6.3 Turning the log on and off ::::::::::::::::::::::::::::::::::::::::::::::::::: 25 6.6.4 Log to file or printer ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 25 6.6.5 Compilation summary ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 25 6.6.6 The created image ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 25 6.6.7 Problems, problems ... ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 26 6.7 Downloading the compiled image ::::::::::::::::::::::::::::::::::::::::::::::::: 26 6.7.1 Downloading to Flash ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 27 6.7.2 Downloading to an emulator or programmer ::::::::::::::::::::::::::::::::: 27 6.8 Running the target Forth ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 27 6.8.1 Switching to target mode :::::::::::::::::::::::::::::::::::::::::::::::::::: 27 6.8.2 Resetting the target board ::::::::::::::::::::::::::::::::::::::::::::::::::: 27 6.8.3 The sign-on ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 27 6.9 Cross-compiling an application ::::::::::::::::::::::::::::::::::::::::::::::::::: 29 6.9.1 Modifying the control file :::::::::::::::::::::::::::::::::::::::::::::::::::: 29 6.9.2 Running your application :::::::::::::::::::::::::::::::::::::::::::::::::::: 29 6.10 Generating a turnkey application :::::::::::::::::::::::::::::::::::::::::::::::: 29 6.10.1 Using MAKE-TURNKEY :::::::::::::::::::::::::::::::::::::::::::::::::: 30 6.10.2 Using ATCOLD :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 31 6.11 Umbilical Forth ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 32 6.11.1 Comms links ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 32 6.11.2 Serial line configuration :::::::::::::::::::::::::::::::::::::::::::::::::::: 34 6.11.3 Memory drivers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 35 6.11.4 Downloading to Flash :::::::::::::::::::::::::::::::::::::::::::::::::::::: 36 6.11.5 Using In-Application-Programming (IAP)::::::::::::::::::::::::::::::::::: 36 6.11.6 Interactive debugging::::::::::::::::::::::::::::::::::::::::::::::::::::::: 37 6.11.7 Problems, problems :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 37 6.12 Serial port problems::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 38 6.12.1 Windows USB serial devices :::::::::::::::::::::::::::::::::::::::::::::::: 39 6.12.2 Windows terminal emulators:::::::::::::::::::::::::::::::::::::::::::::::: 39 6.12.3 Mac OS X USB serial devices::::::::::::::::::::::::::::::::::::::::::::::: 39 6.12.4 Linux USB serial devices ::::::::::::::::::::::::::::::::::::::::::::::::::: 40 7 Optimising the target Forth ::::::::::::::::::::::::::::::::: 41 7.1 Reducing the image size :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 41 7.2 Removing headers :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 41 7.2.1 Removing all headers :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 41 7.2.2 Selectively removing headers ::::::::::::::::::::::::::::::::::::::::::::::::: 41 7.3 Factoring your code :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 41 7.4 Removing excess code :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 42 7.5 Using equates instead of constants :::::::::::::::::::::::::::::::::::::::::::::::: 42 7.6 Removing forward references ::::::::::::::::::::::::::::::::::::::::::::::::::::: 43 7.7 Using Umbilical Forth :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 43 7.8 Speeding up your code ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 43 iii 8 Generic I/O::::::::::::::::::::::::::::::::::::::::::::::::::: 45 8.1 About Generic I/O ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 45 8.2 Creating a new device :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 45 8.3 Selecting a device :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 46 9 Multitasker ::::::::::::::::::::::::::::::::::::::::::::::::::: 47 9.1 Initialising the multitasker:::::::::::::::::::::::::::::::::::::::::::::::::::::::: 47 9.1.1 Selecting the multi-tasker :::::::::::::::::::::::::::::::::::::::::::::::::::: 47 9.1.2 Starting the multitasker ::::::::::::::::::::::::::::::::::::::::::::::::::::: 47 9.1.3 Stopping the multitasker::::::::::::::::::::::::::::::::::::::::::::::::::::: 47 9.2 Writing a task:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 48 9.2.1 Using the scheduler :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 48 9.2.2 An example task :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 48 9.2.3 Task dependent variables :::::::::::::::::::::::::::::::::::::::::::::::::::: 48 9.2.4 Controlling tasks ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Load more

Recommended publications
  • Sensors: Sensing and Data Acquisidon
    Sensors: Sensing and Data Acquisi3on Prof. Yan Luo For UMass Lowell 16.480/552 Sensors: Sensing and Data Acquisi3on 1 Prof. Yan Luo, UMass Lowell Outline • Sensors • Sensor interfacing • Sensor data conversion and acquisi3on • PIC microcontroller programming • Lab 1: Sensor design and data acquisi3on (a light intensity sensor) Sensors: Sensing and Data Acquisi3on 2 Prof. Yan Luo, UMass Lowell Basic Principle of Sensors • Transducer: a device that converts energy from one form to another • Sensor: converts a physical parameter to an electric output – Electric output is desirable as it enables further signal processing. • Actuator: coverts an electric signal to a physical output Sensors: Sensing and Data Acquisi3on 3 Prof. Yan Luo, UMass Lowell Sensors • Cameras • Analog sensors • Accelerometer - Con3nuously varying output • Rate gyro • Digital sensors • Strain gauge - on/off • Microphone - Pulse trains (freq convey measurement) • Magnetometer • Chemical sensors • Op3cal sensors Sensors: Sensing and Data Acquisi3on 4 Prof. Yan Luo, UMass Lowell Example: Photoresistor • Or Light Dependent Resistor (LDR) – Resistance decreases with increasing light intensity – Made of semiconductor – Photons absorbed cause electrons to jump into conduc3on band Sensors: Sensing and Data Acquisi3on 5 Prof. Yan Luo, UMass Lowell Interfacing with Sensors • Interface circuitry • ADC • Interfaces of the embedded system • SoVware drivers and APIs Sensors: Sensing and Data Acquisi3on 6 Prof. Yan Luo, UMass Lowell Example voltage divider circuit Vcc R2 V=Vcc x R1/(R1+R2) V R1 Sensors: Sensing and Data Acquisi3on 7 Prof. Yan Luo, UMass Lowell Analog-Digital Converter (ADC) • Types of ADC – Integrang ADC • Internal voltage controlled oscillator • slow – Successive approximaon ADC • Digital code driving the analog reference voltage – Flash ADC • A bank of comparators • Fast Sensors: Sensing and Data Acquisi3on 8 Prof.
    [Show full text]
  • Riscv-Software-Stack-Tutorial-Hpca2015
    Software Tools Bootcamp RISC-V ISA Tutorial — HPCA-21 08 February 2015 Albert Ou UC Berkeley [email protected] Preliminaries To follow along, download these slides at http://riscv.org/tutorial-hpca2015.html 2 Preliminaries . Shell commands are prefixed by a “$” prompt. Due to time constraints, we will not be building everything from source in real-time. - Binaries have been prepared for you in the VM image. - Detailed build steps are documented here for completeness but are not necessary if using the VM. Interactive portions of this tutorial are denoted with: $ echo 'Hello world' . Also as a reminder, these slides are marked with an icon in the upper-right corner: 3 Software Stack . Many possible combinations (and growing) . But here we will focus on the most common workflows for RISC-V software development 4 Agenda 1. riscv-tools infrastructure 2. First Steps 3. Spike + Proxy Kernel 4. QEMU + Linux 5. Advanced Cross-Compiling 6. Yocto/OpenEmbedded 5 riscv-tools — Overview “Meta-repository” with Git submodules for every stable component of the RISC-V software toolchain Submodule Contents riscv-fesvr RISC-V Frontend Server riscv-isa-sim Functional ISA simulator (“Spike”) riscv-qemu Higher-performance ISA simulator riscv-gnu-toolchain binutils, gcc, newlib, glibc, Linux UAPI headers riscv-llvm LLVM, riscv-clang submodule riscv-pk RISC-V Proxy Kernel (riscv-linux) Linux/RISC-V kernel port riscv-tests ISA assembly tests, benchmark suite All listed submodules are hosted under the riscv GitHub organization: https://github.com/riscv 6 riscv-tools — Installation . Build riscv-gnu-toolchain (riscv*-*-elf / newlib target), riscv-fesvr, riscv-isa-sim, and riscv-pk: (pre-installed in VM) $ git clone https://github.com/riscv/riscv-tools $ cd riscv-tools $ git submodule update --init --recursive $ export RISCV=<installation path> $ export PATH=${PATH}:${RISCV}/bin $ ./build.sh .
    [Show full text]
  • Operating Systems and Applications for Embedded Systems >>> Toolchains
    >>> Operating Systems And Applications For Embedded Systems >>> Toolchains Name: Mariusz Naumowicz Date: 31 sierpnia 2018 [~]$ _ [1/19] >>> Plan 1. Toolchain Toolchain Main component of GNU toolchain C library Finding a toolchain 2. crosstool-NG crosstool-NG Installing Anatomy of a toolchain Information about cross-compiler Configruation Most interesting features Sysroot Other tools POSIX functions AP [~]$ _ [2/19] >>> Toolchain A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes a compiler, a linker, and run-time libraries. [1. Toolchain]$ _ [3/19] >>> Main component of GNU toolchain * Binutils: A set of binary utilities including the assembler, and the linker, ld. It is available at http://www.gnu.org/software/binutils/. * GNU Compiler Collection (GCC): These are the compilers for C and other languages which, depending on the version of GCC, include C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. They all use a common back-end which produces assembler code which is fed to the GNU assembler. It is available at http://gcc.gnu.org/. * C library: A standardized API based on the POSIX specification which is the principle interface to the operating system kernel from applications. There are several C libraries to consider, see the following section. [1. Toolchain]$ _ [4/19] >>> C library * glibc: Available at http://www.gnu.org/software/libc. It is the standard GNU C library. It is big and, until recently, not very configurable, but it is the most complete implementation of the POSIX API. * eglibc: Available at http://www.eglibc.org/home.
    [Show full text]
  • "Firefly" Z80 General-Purpose Retro Computing Platform
    "FIREFLY" Z80 GENERAL-PURPOSE RETRO COMPUTING PLATFORM THREE FARTHING LABS http://www.threefarthing.com Page 1 of 13 PREFACE A project has to have a name and this one wound up being called "Firefly" as it©s the culmination of a wirewrap board begun several years ago while binge-watching the series of the same name. That board, in turn, was a redesign of a single board computer I created in 1998, creatively named the "SBCZ1." All three of these projects were begun as a chance to tinker with a processor I first met hands- on in 1984, the ZiLOG Z-80, though it was long-established by that time and dominated the business computer market. It was the CPU of preference behind most CP/M machines and CP/M was what I wanted to tinker with again, from the ground up ± not in some cozy emulator. When I began preparing to design the board I looked around on the Internet and found many excellent Z80 projects, including kit options. The choice was made to "roll my own" for numerous reasons. In the SBCZ1 I had most of a good design and wanted to retain a lot of hard work (done before I had Internet access, mind you). There were also specific reasons for wanting "to stay within ZiLOG canon" and work with a particular hardware configuration. I saw no kits that did just what I wanted in the way that I wanted. There was also a desire to maintain modularity and be extensible but not require a proliferation of modules for what I considered core functionality, yet great restraint was employed to keep "core functionality" spartan.
    [Show full text]
  • Linux Journal | February 2016 | Issue
    ™ A LOOK AT KDE’s KStars Astronomy Program Since 1994: The Original Magazine of the Linux Community FEBRUARY 2016 | ISSUE 262 | www.linuxjournal.com + Programming Working with Command How-Tos Arguments in Your Program a Shell Scripts BeagleBone Interview: Katerina Black Barone-Adesi on to Help Brew Beer Developing the Snabb Switch Network Write a Toolkit Short Script to Solve a WATCH: ISSUE Math Puzzle OVERVIEW V LJ262-February2016.indd 1 1/21/16 5:26 PM NEW! Agile Improve Product Business Development Processes with an Enterprise Practical books Author: Ted Schmidt Job Scheduler for the most technical Sponsor: IBM Author: Mike Diehl Sponsor: people on the planet. Skybot Finding Your DIY Way: Mapping Commerce Site Your Network Author: to Improve Reuven M. Lerner Manageability GEEK GUIDES Sponsor: GeoTrust Author: Bill Childers Sponsor: InterMapper Combating Get in the Infrastructure Fast Lane Sprawl with NVMe Author: Author: Bill Childers Mike Diehl Sponsor: Sponsor: Puppet Labs Silicon Mechanics & Intel Download books for free with a Take Control Linux in simple one-time registration. of Growing the Time Redis NoSQL of Malware http://geekguide.linuxjournal.com Server Clusters Author: Author: Federico Kereki Reuven M. Lerner Sponsor: Sponsor: IBM Bit9 + Carbon Black LJ262-February2016.indd 2 1/21/16 5:26 PM NEW! Agile Improve Product Business Development Processes with an Enterprise Practical books Author: Ted Schmidt Job Scheduler for the most technical Sponsor: IBM Author: Mike Diehl Sponsor: people on the planet. Skybot Finding Your DIY Way: Mapping Commerce Site Your Network Author: to Improve Reuven M. Lerner Manageability GEEK GUIDES Sponsor: GeoTrust Author: Bill Childers Sponsor: InterMapper Combating Get in the Infrastructure Fast Lane Sprawl with NVMe Author: Author: Bill Childers Mike Diehl Sponsor: Sponsor: Puppet Labs Silicon Mechanics & Intel Download books for free with a Take Control Linux in simple one-time registration.
    [Show full text]
  • Compiler Construction
    Compiler Construction Chapter 11 Compiler Construction Compiler Construction 1 A New Compiler • Perhaps a new source language • Perhaps a new target for an existing compiler • Perhaps both Compiler Construction Compiler Construction 2 Source Language • Larger, more complex languages generally require larger, more complex compilers • Is the source language expected to evolve? – E.g., Java 1.0 ! Java 1.1 ! . – A brand new language may undergo considerable change early on – A small working prototype may be in order – Compiler writers must anticipate some amount of change and their design must therefore be flexible – Lexer and parser generators (like Lex and Yacc) are therefore better than hand- coding the lexer and parser when change is inevitable Compiler Construction Compiler Construction 3 Target Language • The nature of the target language and run-time environment influence compiler construction considerably • A new processor and/or its assembler may be buggy Buggy targets make it difficult to debug compilers for that target! • A successful source language will persist over several target generations – E.g., 386 ! 486 ! Pentium ! . – Thus the design of the IR is important – Modularization of machine-specific details is also important Compiler Construction Compiler Construction 4 Compiler Performance Issues • Compiler speed • Generated code quality • Error diagnostics • Portability • Maintainability Compiler Construction Compiler Construction 5 Compiler Speed • Reduce the number of modules • Reduce the number of passes Perhaps generate machine
    [Show full text]
  • A Model-Driven Development and Verification Approach
    A MODEL-DRIVEN DEVELOPMENT AND VERIFICATION APPROACH FOR MEDICAL DEVICES by Jakub Jedryszek B.S., Wroclaw University of Technology, Poland, 2012 B.A., Wroclaw University of Economics, Poland, 2012 A THESIS submitted in partial fulfillment of the requirements for the degree MASTER OF SCIENCE Department of Computing and Information Sciences College of Engineering KANSAS STATE UNIVERSITY Manhattan, Kansas 2014 Approved by: Major Professor John Hatcliff Abstract Medical devices are safety-critical systems whose failure may put human life in danger. They are becoming more advanced and thus more complex. This leads to bigger and more complicated code-bases that are hard to maintain and verify. Model-driven development provides high-level and abstract description of the system in the form of models that omit details, which are not relevant during the design phase. This allows for certain types of verification and hazard analysis to be performed on the models. These models can then be translated into code. However, errors that do not exist in the models may be introduced during the implementation phase. Automated translation from verified models to code may prevent to some extent. This thesis proposes approach for model-driven development and verification of medi- cal devices. Models are created in AADL (Architecture Analysis & Design Language), a language for software and hardware architecture modeling. AADL models are translated to SPARK Ada, contract-based programming language, which is suitable for software veri- fication. Generated code base is further extended by developers to implement internals of specific devices. Created programs can be verified using SPARK tools. A PCA (Patient Controlled Analgesia) pump medical device is used to illustrate the primary artifacts and process steps.
    [Show full text]
  • Efficient Automated Code Partitioning for Microcontrollers with Switchable
    Efficient Automated Code Partitioning for Microcontrollers with Switchable Memory Banks MICHAL CISZEWSKI and KONRAD IWANICKI, University of Warsaw 114 Switching active memory banks at runtime allows a processor with a narrow address bus to access memory that exceeds ranges normally addressable via the bus. Switching code memory banks is regaining interest in microcontrollers for the Internet of Things (IoT), which have to run continuously growing software, while at the same time consuming ultra-small amounts of energy. To make use of bank switching, such software has to be partitioned among the available banks and augmented with bank-switching instructions. In contrast to the augmenting, which is done automatically by a compiler, today the partitioning is normally done manually by programmers. However, since IoT software is cross-compiled on much more powerful machines than its target microcontrollers, it becomes possible to partition it automatically during compilation. In this article, we thus study the problem of partitioning program code among banks such that the resulting runtime performance of the program is maximized. We prove that the problem is NP-hard and propose a heuristic algorithm with a low complexity, so that it enables fast compilation, and hence interactive software development. The algorithm decomposes the problem into three subproblems and introduces a heuristic for each of them: (1) Which pieces of code to partition? (2) Which of them to assign to permanently mapped banks? and (3) How to divide the remaining ones among switchable banks? We integrate the algorithm, together with earlier ones, in an open-source compiler and test the resulting solution on synthetic as well as actual commercial IoT software bases, thereby demonstrating its advantages and drawbacks.
    [Show full text]
  • Linux Everywhere a Look at Linux Outside the World of Desktops
    Linux Everywhere A look at Linux outside the world of desktops CIS 191 Spring 2012 – Guest Lecture by Philip Peng Lecture Outline 1. Introduction 2. Different Platforms 3. Reasons for Linux 4. Cross-compiling 5. Case Study: iPodLinux 6. Questions 2 What’s in common? 3 All your hardware are belong to us • Linux is everywhere – If its programmable, you can put Linux on it! – Yes, even a microwave CES 2010, microwave running Android: http://www.handlewithlinux.com/linux-washing-cooking 4 Servers • What servers use – Stability, security, free – Examples: ◦ CentOS ◦ Debian ◦ Red Hat 5 Desktop • What you use – Free Windows/Mac alternative – Examples: ◦ Ubuntu ◦ Fedora ◦ PCLinuxOS 6 Gaming Devices • What (white-hat) hackers do – To run “homebrew” software – Examples: ◦ PS3, Wii, XBOX ◦ PS2, GameCube ◦ Dreamcast ◦ PSP, DS ◦ Open Pandora, GP2X 7 Mobile Devices • What distributors are developing – Community contribution – Examples ◦ Android ◦ Maemo/MeeGo/Tizen ◦ Openmoko 8 Embedded Devices • What embedded hardware run – Small footprint, dev tools – Examples ◦ RTLinux (real-time) ◦ μClinux (no MMU) ◦ Ångström (everything) 9 Why? 10 Free! • Free! – As in freedom, i.e. open source – As in beer, i.e. vs paid upgrades 11 Homebrew! • Run own software – Your hardware your software? 12 Support! • Community contribution – “For the greater good” (i.e. users) – Everyone contributes ◦ Specialists from all over the world – Existing hardware support ◦ Many already supported computer architecture ◦ Modify existing drivers 13 Lots of support! 14 Why not? • Because we can – If its hackable, it can run Linux 15 How? • How do we get Linux running on XXX? • Port: A version of software modified to run on a different target platform – The PS3 port of Fedora is a modified build of Fedora compiled to run on the PS3 architecture – e.g.
    [Show full text]
  • Embedded Linux Device Driver Development Sébastien Bilavarn
    Embedded Linux Device driver development Sébastien Bilavarn Polytech’Nice Sophia - Département Electronique - Université de Nice Sophia Antipolis - S. Bilavarn - 1 - Outline Ch1 – Introduction to Linux Ch2 – Linux kernel overview Ch3 – Linux for Embedded Systems Ch4 – Embedded Linux distributions Ch5 – Case study: Xilinx PowerPC Linux Ch5 bis – Case study: Xilinx Zynq-7000 Linux Ch6 – Device driver development Polytech’Nice Sophia - Département Electronique - Université de Nice Sophia Antipolis - S. Bilavarn - 2 - Linux for Embedded Systems Introduction to Embedded Linux Key features Embedded Linux development Linux kernel development Polytech’Nice Sophia - Département Electronique - Université de Nice Sophia Antipolis - S. Bilavarn - 3 - Embedded Linux What is Embedded Linux ? Strictly speaking Embedded Linux is an operating system based on Linux and adapted specifically to the constraints of embedded systems. Unlike standard versions of Linux for Personal Computers, embedded Linux is designed for systems with limited resources Memory: few RAM, sometimes no Memory Management Unit (MMU) Storage: Flash instead of hard disk drive Since embedded systems are often designed for domain specific purposes and specific target platforms, they use kernel versions that are optimized for a given context of application. This results in different Linux kernel variants that are also called Linux distributions Polytech’Nice Sophia - Département Electronique - Université de Nice Sophia Antipolis - S. Bilavarn - 4 - Embedded Linux What is embedded Linux ? Embedded Linux is used in embedded systems such as mobile phones, personal digital assistants (PDA), media players set-top boxes, and other consumer electronics devices networking equipment machine control, industrial automation navigation equipment medical instruments Key features runs in a small embedded system, typically booting out of Flash, no hard disk drive, no full-size video display, and take far less than 2 minutes to boot up, sometimes supports real- time tasks.
    [Show full text]
  • Cross-Compiler Bipartite Vulnerability Search
    electronics Article Cross-Compiler Bipartite Vulnerability Search Paul Black * and Iqbal Gondal Internet Commerce Security Laboratory (ICSL), Federation University, Ballarat 3353, Australia; [email protected] * Correspondence: [email protected] Abstract: Open-source libraries are widely used in software development, and the functions from these libraries may contain security vulnerabilities that can provide gateways for attackers. This paper provides a function similarity technique to identify vulnerable functions in compiled programs and proposes a new technique called Cross-Compiler Bipartite Vulnerability Search (CCBVS). CCBVS uses a novel training process, and bipartite matching to filter SVM model false positives to improve the quality of similar function identification. This research uses debug symbols in programs compiled from open-source software products to generate the ground truth. This automatic extraction of ground truth allows experimentation with a wide range of programs. The results presented in the paper show that an SVM model trained on a wide variety of programs compiled for Windows and Linux, x86 and Intel 64 architectures can be used to predict function similarity and that the use of bipartite matching substantially improves the function similarity matching performance. Keywords: malware similarity; function similarity; binary similarity; machine-learning; bipar- tite matching 1. Introduction Citation: Black, P.; Gondal, I. Cross-Compiler Bipartite Function similarity techniques are used in the following activities, the triage of mal- Vulnerability Search. Electronics 2021, ware [1], analysis of program patches [2], identification of library functions [3], analysis of 10, 1356. https://doi.org/10.3390/ code authorship [4], the identification of similar function pairs to reduce manual analysis electronics10111356 workload, [5], plagiarism analysis [6], and for vulnerable function identification [7–9].
    [Show full text]
  • The Ultimate C64 Overview Michael Steil, 25Th Chaos Communication Congress 2008
    The Ultimate C64 Overview Michael Steil, http://www.pagetable.com/ 25th Chaos Communication Congress 2008 Retrocomputing is cool as never before. People play Look and Feel C64 games in emulators and listen to SID music, but few people know much about the C64 architecture A C64 only needs to be connected to power and a TV and its limitations, and what programming was like set (or monitor) to be fully functional. When turned back then. This paper attempts to give a comprehen- on, it shows a blue-on-blue theme with a startup mes- sive overview of the Commodore 64, including its in- sage and drops into a BASIC interpreter derived from ternals and quirks, making the point that classic Microsoft BASIC. In order to load and save BASIC computer systems aren't all that hard to understand - programs or use third party software, the C64 re- and that programmers today should be more aware of quires mass storage - either a “datasette” cassette the art that programming once used to be. tape drive or a disk drive like the 5.25" Commodore 1541. Commodore History Unless the user really wanted to interact with the BA- SIC interpreter, he would typically only use the BA- Commodore Business Machines was founded in 1962 SIC instructions LOAD, LIST and RUN in order to by Jack Tramiel. The company specialized on elec- access mass storage. LOAD"$",8 followed by LIST tronic calculators, and in 1976, Commodore bought shows the directory of the disk in the drive, and the chip manufacturer MOS Technology and decided LOAD"filename",8 followed by RUN would load and to have Chuck Peddle from MOS evolve their KIM-1 start a program.
    [Show full text]