DOCSLIB.ORG

JOP: a Java Optimized Processor for Embedded Real-Time Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Downloaded from orbit.dtu.dk on: Oct 04, 2021 JOP: A Java Optimized Processor for Embedded Real-Time Systems Schoeberl, Martin Publication date: 2005 Document Version Publisher's PDF, also known as Version of record Link back to DTU Orbit Citation (APA): Schoeberl, M. (2005). JOP: A Java Optimized Processor for Embedded Real-Time Systems. Vienna University of Technology. http://www.jopdesign.com/ General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. DISSERTATION JOP: A Java Optimized Processor for Embedded Real-Time Systems ausgef¨uhrt zum Zwecke der Erlangung des akademischen Grades eines Doktors der technischen Wissenschaften unter der Leitung von AO.UNIV.PROF. DIPL.-ING. DR.TECHN. ANDREAS STEININGER und AO.UNIV.PROF. DIPL.-ING. DR.TECHN. PETER PUSCHNER Inst.-Nr. E182 Institut f¨ur Technische Informatik eingereicht an der Technischen Universit¨at Wien Fakult¨at f¨ur Informatik von DIPL.-ING. MARTIN SCHOBERL¨ Matr.-Nr. 8625440 Straußengasse 2-10/2/55 1050 Wien Wien, im J¨anner 2005 Abstract Compared to software development for desktop systems, current software design practice for embedded systems is still archaic. C/C++ and even assembler are used on top of a small real-time operating system. Many of the benefits of Java, such as safe object references, the notion of concurrency as a first-class language construct, and its portability, have the potential to make embedded systems much safer and simpler to program. However, Java technology is seldom used in embedded systems, due to the lack of acceptable real-time performance. This thesis presents a Java processor designed for time-predictable execution of real-time tasks. JOP (Java Optimized Processor) is the implementation of the Java virtual machine in hardware. JOP is intended for applications in embedded real-time systems and the primary implementation technology is in a field programmable gate array. This research demonstrates that a hardware implementation of the Java virtual machine results in a small design for resource-constrained devices. Architectural advancements in modern processor designs increase average perfor- mance with features such as pipelines, caches and branch prediction. However, these features complicate worst-case execution time (WCET) analysis and lead to very conservative WCET estimates. This thesis tackles this problem from the architec- tural perspective – by introducing a processor architecture in which simpler and more accurate WCET analysis is more important than average case performance. This thesis evaluates the issues surrounding the use of standard Java for real-time applications. In order to overcome some of the issues with standard Java, a profile for real-time Java is defined. Tight integration of the real-time scheduler with the supporting processor result in an efficient platform for Java in embedded real-time systems. The proposed processor and the Java real-time profile have been used with success to implement several commercial real-time applications. Kurzfassung Eingebettete Systeme werden zur Zeit vorwiegend in C/C++ oder auch noch in Assembler programmiert. Viele Vorteile der Programmiersprache Java, wie z.B. sichere Objektreferenzen, die Notation von Nebenl¨aufigkeit in der Sprache und auch die Portabilit¨at der Sprache, k¨onnten die Entwicklung dieser Systeme vereinfachen und auch die Sicherheit dieser Systeme erh¨ohen. Jedoch erschwert die mangelnde Echtzeitf¨ahigkeit von Standard Java den Einsatz in eingebetteten Systemen. Diese Arbeit beschreibt den Entwurf eines echtzeitf¨ahigen Java Prozessors. JOP (Java Optimized Processor) ist die Realisierung der Java virtual machine in Hard- ware. JOP ist f¨ur den Einsatz in eingebetteten, echtzeitf¨ahigen Systemen entworfen und ist in einem ‘Field Programmable Gate Array’ implementiert. Diese Arbeit zeigt, dass eine Hardwarerealisierung der Java virtual machine zu einem kleinen System f¨uhrt, das auch f¨ur Applikationen mit rigiden Ressourcebeschr¨ankungen geeignet ist. Moderne Prozessoren weisen Architekturmerkmale auf (wie z.B. Parallelverar- beitung, Cachespeicher und Sprungvorhersage), die vor allem die durchschnittliche Rechenleistung erh¨ohen. Diese Architekturmerkmale erschweren jedoch die ‘Worst- Case Execution Time’ (WCET) Analyse und f¨uhren zu pessimistischen WCET Ab- sch¨atzungen. Diese Arbeit geht einen anderen Weg – Es wird eine Prozessorarchitek- tur vorgestellt, f¨ur die eine einfache und genauere WCET Analyse wichtiger ist als die durchschnittliche Rechenleistung. Diese Arbeit untersucht die Probleme, die sich bei der Verwendung von Java in Echtzeitsystemen ergeben. Standard Java wird um eine Spezifikation f¨ur Echtzeit- systeme erweitert. Die Integration des echtzeitf¨ahigen Schedulers mit dem Prozessor f¨uhrt zu einer effizienten Plattform f¨ur Java in eingebetteten Echtzeitsystemen. Der vorgestellte Prozessor und die Spezifikation f¨ur echtzeitf¨ahiges Java wurden erfolgreich in mehreren kommerziellen Echtzeitsystemen eingesetzt. Contents 1 Introduction 1 1.1 Justification for Development . 1 1.2 Embedded Real-Time Systems . 2 1.3 Research Objectives and Contributions . 3 1.4 OutlineoftheThesis ......................... 6 2 Java and the Java Virtual Machine 7 2.1 Java .................................. 7 2.1.1 History ............................ 9 2.1.2 The Java Programming Language . 9 2.2 The Java Virtual Machine . 11 2.2.1 MemoryAreas ........................ 11 2.2.2 JVM Instruction Set . 12 2.2.3 Methods ........................... 13 2.2.4 Implementation of the JVM . 14 2.3 Summary ............................... 16 3 Related Work 17 3.1 Hardware Translation and Coprocessors . 17 3.1.1 Hard-Int............................ 19 3.1.2 DELFT-JAVAEngine. 19 3.1.3 JIFFY............................. 19 3.1.4 Jazelle............................. 20 3.1.5 JSTAR,JA108 ........................ 21 3.1.6 A Co-Designed Virtual Machine . 21 3.2 JavaProcessors ............................ 22 3.2.1 picoJava............................ 22 3.2.2 aJileJEMCore ........................ 25 3.2.3 Cjip.............................. 26 3.2.4 Ignite,PSC1000 ....................... 26 II CONTENTS 3.2.5 Moon............................. 27 3.2.6 Lightfoot ........................... 27 3.2.7 LavaCORE .......................... 28 3.2.8 Komodo............................ 28 3.2.9 FemtoJava .......................... 28 3.3 AdditionalComments. 29 3.4 Research Objectives . 30 4 Restrictions of Java for Embedded Real-Time Systems 33 4.1 Java Support for Embedded Systems . 33 4.2 Issues with Java in Embedded Systems . 34 4.3 JavaMicroEdition .......................... 37 4.3.1 Connected Limited Device Configuration (CLDC) . 37 4.3.2 Connected Device Configuration (CDC) . 39 4.3.3 Additional Specifications . 40 4.3.4 Discussion .......................... 40 4.4 Real-Time Extensions . 41 4.4.1 Real-Time Core Extension . 41 4.4.2 Discussion of the RT Core . 42 4.4.3 Real-Time Specification for Java . 43 4.4.4 Discussion of the RTSJ . 45 4.4.5 SubsetsoftheRTSJ ... ..... ...... ..... .. 51 4.4.6 Extensions to the RTSJ . 53 4.5 Summary ............................... 53 5 JOP Architecture 55 5.1 BenchmarkingtheJVM. 55 5.1.1 Bytecode Frequency . 55 5.1.2 Methods Types and Length . 60 5.1.3 Summary ........................... 64 5.2 OverviewofJOP ........................... 64 5.3 Microcode............................... 66 5.3.1 Translation of Bytecodes to Microcode . 66 5.3.2 Compact Microcode . 68 5.3.3 Instruction Set . 69 5.3.4 BytecodeExample .... ..... ...... ..... .. 70 5.3.5 Flexible Implementation of Bytecodes . 70 5.3.6 Summary ........................... 71 5.4 The Processor Pipeline . 71 CONTENTS III 5.4.1 Java Bytecode Fetch . 72 5.4.2 JOP Instruction Fetch . 73 5.4.3 Decode and Address Generation . 74 5.4.4 Execute............................ 75 5.4.5 Interrupt Logic . 77 5.4.6 Summary ........................... 77 5.5 AnEfficientStackMachine. 78 5.5.1 Java Computing Model . 78 5.5.2 Access Patterns on the Java Stack . 81 5.5.3 Common Realizations of a Stack Cache . 82 5.5.4 A Two-Level Stack Cache . 85 5.5.5 Resource Usage Compared . 91 5.5.6 Summary ........................... 93 5.6 HW/SWCodesign .......................... 93 5.7 Real-Time Predictability . 98 5.7.1 Interrupts ........................... 98 5.7.2 TaskSwitch.......................... 99 5.7.3 Architectural Design Decisions . 101 5.7.4 Summary ........................... 103 5.8 A Time-Predictable Instruction Cache . 103 5.8.1 Cache Performance . 104 5.8.2 Proposed Cache Solution . 107 5.8.3 WCETAnalysis ....................... 112 5.8.4 CachesCompared . 113 5.8.5 Summary ........................... 119 6 JOP Runtime System 121 6.1 A Real-Time Profile for Embedded Java . 121 6.1.1 Application Structure . 122 6.1.2 Threads............................ 122 6.1.3 Scheduling .......................... 123 6.1.4 Memory...........................
Recommended publications
  • Java (Programming Langua a (Programming Language)

    Java (Programming Langua a (Programming Language)

    Java (programming language) From Wikipedia, the free encyclopedialopedia "Java language" redirects here. For the natural language from the Indonesian island of Java, see Javanese language. Not to be confused with JavaScript. Java multi-paradigm: object-oriented, structured, imperative, Paradigm(s) functional, generic, reflective, concurrent James Gosling and Designed by Sun Microsystems Developer Oracle Corporation Appeared in 1995[1] Java Standard Edition 8 Update Stable release 5 (1.8.0_5) / April 15, 2014; 2 months ago Static, strong, safe, nominative, Typing discipline manifest Major OpenJDK, many others implementations Dialects Generic Java, Pizza Ada 83, C++, C#,[2] Eiffel,[3] Generic Java, Mesa,[4] Modula- Influenced by 3,[5] Oberon,[6] Objective-C,[7] UCSD Pascal,[8][9] Smalltalk Ada 2005, BeanShell, C#, Clojure, D, ECMAScript, Influenced Groovy, J#, JavaScript, Kotlin, PHP, Python, Scala, Seed7, Vala Implementation C and C++ language OS Cross-platform (multi-platform) GNU General Public License, License Java CommuniCommunity Process Filename .java , .class, .jar extension(s) Website For Java Developers Java Programming at Wikibooks Java is a computer programming language that is concurrent, class-based, object-oriented, and specifically designed to have as few impimplementation dependencies as possible.ble. It is intended to let application developers "write once, run ananywhere" (WORA), meaning that code that runs on one platform does not need to be recompiled to rurun on another. Java applications ns are typically compiled to bytecode (class file) that can run on anany Java virtual machine (JVM)) regardless of computer architecture. Java is, as of 2014, one of tthe most popular programming ng languages in use, particularly for client-server web applications, witwith a reported 9 million developers.[10][11] Java was originallyy developed by James Gosling at Sun Microsystems (which has since merged into Oracle Corporation) and released in 1995 as a core component of Sun Microsystems'Micros Java platform.
  • Real-Time Java for Embedded Devices: the Javamen Project*

    Real-Time Java for Embedded Devices: the Javamen Project*

    REAL-TIME JAVA FOR EMBEDDED DEVICES: THE JAVAMEN PROJECT* A. Borg, N. Audsley, A. Wellings The University of York, UK ABSTRACT: Hardware Java-specific processors have been shown to provide the performance benefits over their software counterparts that make Java a feasible environment for executing even the most computationally expensive systems. In most cases, the core of these processors is a simple stack machine on which stack operations and logic and arithmetic operations are carried out. More complex bytecodes are implemented either in microcode through a sequence of stack and memory operations or in Java and therefore through a set of bytecodes. This paper investigates the Figure 1: Three alternatives for executing Java code (take from (6)) state-of-the-art in Java processors and identifies two areas of improvement for specialising these processors timeliness as a key issue. The language therefore fails to for real-time applications. This is achieved through a allow more advanced temporal requirements of threads combination of the implementation of real-time Java to be expressed and virtual machine implementations components in hardware and by using application- may behave unpredictably in this context. For example, specific characteristics expressed at the Java level to whereas a basic thread priority can be specified, it is not drive a co-design strategy. An implementation of these required to be observed by a virtual machine and there propositions will provide a flexible Ravenscar- is no guarantee that the highest priority thread will compliant virtual machine that provides better preempt lower priority threads. In order to address this performance while still guaranteeing real-time shortcoming, two competing specifications have been requirements.
  • Anpassung Eines Netzwerkprozessor-Referenzsystems Im Rahmen Des MAMS-Forschungsprojektes

    Anpassung Eines Netzwerkprozessor-Referenzsystems Im Rahmen Des MAMS-Forschungsprojektes

    Anpassung eines Netzwerkprozessor-Referenzsystems im Rahmen des MAMS-Forschungsprojektes Diplomarbeit an der Fachhochschule Hof Fachbereich Informatik / Technik Studiengang: Angewandte Informatik Vorgelegt bei von Prof. Dr. Dieter Bauer Stefan Weber Fachhochschule Hof Pacellistr. 23 Alfons-Goppel-Platz 1 95119 Naila 95028 Hof Matrikelnr. 00041503 Abgabgetermin: Freitag, den 28. September 2007 Hof, den 27. September 2007 Diplomarbeit - ii - Inhaltsverzeichnis Titelseite i Inhaltsverzeichnis ii Abbildungsverzeichnis v Tabellenverzeichnis vii Quellcodeverzeichnis viii Funktionsverzeichnis x Abkurzungen¨ xi Definitionen / Worterkl¨arungen xiii 1 Vorwort 1 2 Einleitung 3 2.1 Abstract ......................................... 3 2.2 Zielsetzung der Arbeit ................................. 3 2.3 Aufbau der Arbeit .................................... 4 2.4 MAMS .......................................... 4 2.4.1 Anwendungsszenario .............................. 4 2.4.2 Einführung ................................... 5 2.4.3 NGN - Next Generation Networks ....................... 5 2.4.4 Abstrakte Darstellung und Begriffe ...................... 7 3 Hauptteil 8 3.1 BorderGateway Hardware ............................... 8 3.1.1 Control-Blade - Control-PC .......................... 9 3.1.2 ConverGate-D Evaluation Board: Modell easy4271 ............. 10 3.1.3 ConverGate-D Netzwerkprozessor ....................... 12 3.1.4 Motorola POWER Chip (MPC) Modul ..................... 12 3.1.5 Test- und Arbeitsumgebung .......................... 13 3.2 Vorhandene
  • S32 Design Studio for S32 Platform 3.4 Installation Guide

    S32 Design Studio for S32 Platform 3.4 Installation Guide

    S32 Design Studio for S32 Platform 3.4 Installation Guide Document Number: S32DSIG Rev. 1.0, 12/2020 Contents System Requirements......................................................................................................................3 Installation prerequisites for Linux platforms.............................................................................5 Downloading S32DS 3.4................................................................................................................12 Downloading the S32DS 3.4 installer................................................................................................................12 Obtaining the activation code.............................................................................................................................12 Installing S32DS 3.4......................................................................................................................14 Debian 8 post-installation settings..................................................................................................................... 20 Installing product updates and packages................................................................................... 23 Installing Synopsys tools...............................................................................................................25 Installing VP Explorer........................................................................................................................................25 Post-installation settings....................................................................................................................................
  • Embedded Java with GCJ

    Embedded Java with GCJ

    Embedded Java with GCJ http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1140000/11341... Embedded Java with GCJ Gene Sally Abstract You don't always need a Java Virtual Machine to run Java in an embedded system. This article discusses how to use GCJ, part of the GCC compiler suite, in an embedded Linux project. Like all tools, GCJ has benefits, namely the ability to code in a high-level language like Java, and its share of drawbacks as well. The notion of getting GCJ running on an embedded target may be daunting at first, but you'll see that doing so requires less effort than you may think. After reading the article, you should be inspired to try this out on a target to see whether GCJ can fit into your next project. The Java language has all sorts of nifty features, like automatic garbage collection, an extensive, robust run-time library and expressive object-oriented constructs that help you quickly develop reliable code. Why Use GCJ in the First Place? The native code compiler for Java does what is says: compiles your Java source down to the machine code for the target. This means you won't have to get a JVM (Java Virtual Machine) on your target. When you run the program's code, it won't start a VM, it will simply load and run like any other program. This doesn't necessarily mean your code will run faster. Sometimes you get better performance numbers for byte code running on a hot-spot VM versus GCJ-compiled code.
  • Optimizing for Jazelle DBX and Java Hotspot™ Technology Case Study

    Optimizing for Jazelle DBX and Java Hotspot™ Technology Case Study

    Optimizing Midlets for Size and Performance Simon Robinson Innaworks www.innaworks.com TS-5109 2007 JavaOneSM Conference | Session TS-5109 | Goal of This Talk Pushing the size and performance of Java™ Platform, Micro Edition (Java ME platform) applications on today’s handsets 2007 JavaOneSM Conference | Session TS-5109 | 2 Agenda Why size and performance matters Under the bonnet of a Java ME Platform MIDlet Optimization strategy Optimization techniques Optimizing for Jazelle DBX and Java HotSpot™ technology Case study 2007 JavaOneSM Conference | Session TS-5109 | 3 Agenda Why size and performance matters Under the bonnet of a Java ME Platform MIDlet Optimization strategy Optimization techniques Optimizing for Jazelle DBX and Java HotSpot™ technology Case study 2007 JavaOneSM Conference | Session TS-5109 | 4 Why Size and Performance Matters Adoption = Potential market size × How much fun ×Marketing 2007 JavaOneSM Conference | Session TS-5109 | 5 Why Size and Performance Matters Adoption = Potential market size × How much fun ×Marketing Handset coverage matters 2007 JavaOneSM Conference | Session TS-5109 | 6 Why Size and Performance Matters Adoption = Potential market size × How much fun ×Marketing How fun is your game? Perceived quality matters 2007 JavaOneSM Conference | Session TS-5109 | 7 Constraints of Consumer Handsets JAR size Heap memory Nokia S40 v1 (3300, etc.) 64 kB 370 kB Nokia S40 v2 (6230, etc.) 128 kB 512 kB Sharp GX22 100 kB 512 kB DoJa 2.5 (m420i) 30 B 1.5 MB 15% game sales for handsets < 64 kB Java Archive (JAR) file size
  • Java in Embedded Linux Systems

    Java in Embedded Linux Systems

    Java in Embedded Linux Systems Java in Embedded Linux Systems Thomas Petazzoni / Michael Opdenacker Free Electrons http://free-electrons.com/ Created with OpenOffice.org 2.x Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 1 Rights to copy Attribution ± ShareAlike 2.5 © Copyright 2004-2008 You are free Free Electrons to copy, distribute, display, and perform the work [email protected] to make derivative works to make commercial use of the work Document sources, updates and translations: Under the following conditions http://free-electrons.com/articles/java Attribution. You must give the original author credit. Corrections, suggestions, contributions and Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license translations are welcome! identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/2.5/legalcode Java in Embedded Linux Systems © Copyright 2004-2007, Free Electrons, Creative Commons Attribution-ShareAlike 2.5 license http://free-electrons.com Sep 15, 2009 2 Best viewed with... This document is best viewed with a recent PDF reader or with OpenOffice.org itself! Take advantage of internal
  • Paper Discusses the Advantages and Disadvantages of Each Approach As Well As Specific Experiences of Using Java in a Commercial Tape Drive Project

    Paper Discusses the Advantages and Disadvantages of Each Approach As Well As Specific Experiences of Using Java in a Commercial Tape Drive Project

    Java and Real Time Storage Applications Gary Mueller 195 Garnet St Broomfield, CO 80020-2203 [email protected] Tel: +1-303-465-4279 Janet Borzuchowski Storage Technology Corporation 2270 South 88th Street M. S. 4272 Louisville CO 80028 [email protected] Tel: +1-303-673-8297 Abstract Storage systems have storage devices which run real time embedded software. Most storage devices use C and occasionally C++ to manage and control the storage device. Software for the storage device must meet the time and resource constraints of the storage device. The prevailing wisdom in the embedded world is that objects and in particular Java only work for simple problems and can not handle REAL problems, are too slow and can not handle time critical processing and are too big and can’t fit in memory constrained systems. Even though Java's roots are in the embedded application area, Java is more widely used in the desktop and enterprise environment. Use of Java in embedded real time environments where performance and size constraints rule is much less common. Java vendors offer a dizzying array of options, products and choices for real time storage applications. Four main themes emerge when using Java in a real time storage application; compiling Java, executing Java with a software Java Virtual Machine (JVM), executing Java with a hardware JVM and replacing a real time operating system (RTOS) with a JVM. The desktop and enterprise environment traditionally run Java using a software JVM that has been ported to a particular platform. The JVM runs as a task or process hosted by the platform operating system.
  • Dalvik Bytecode Acceleration Using Fetch/Decode Hardware Extension

    Dalvik Bytecode Acceleration Using Fetch/Decode Hardware Extension

    Journal of Information Processing Vol.23 No.2 118–130 (Mar. 2015) [DOI: 10.2197/ipsjjip.23.118] Regular Paper Dalvik Bytecode Acceleration Using Fetch/Decode Hardware Extension Surachai Thongkaew1,a) Tsuyoshi Isshiki1,b) Dongju Li1,c) Hiroaki Kunieda1,d) Received: May 6, 2014, Accepted: November 10, 2014 Abstract: The Dalvik virtual machine (Dalvik VM) is an essential piece of software that runs applications on the Android operating system. Android application programs are commonly written in the Java language and compiled to Java bytecode. The Java bytecode is converted to Dalvik bytecode (Dalvik Executable file) which is interpreted by the Dalvik VM on typical Android devices. The significant disadvantage of interpretation is a much slower speed of program execution compared to direct machine code execution on the host CPU. However, there are many tech- niques to improve the performance of Dalvik VM. A typical methodology is just-in-time compilation which converts frequently executed sequences of interpreted instruction to host machine code. Other methodologies include dedi- cated bytecode processors and architectural extension on existing processors. In this paper, we propose an alternative methodology, “Fetch & Decode Hardware Extension,” to improve the performance of Dalvik VM. The Fetch & De- code Hardware Extension is a specially designed hardware component to fetch and decode Dalvik bytecode directly, while the core computations within the virtual registers are done by the optimized Dalvik bytecode software handler. The experimental results show the speed improvements on Arithmetic instructions, loop & conditional instructions and method invocation & return instructions, can be achieved up to 2.4x, 2.7x and 1.8x, respectively.
  • WCET Analysis of Java Bytecode Featuring Common Execution Environments

    WCET Analysis of Java Bytecode Featuring Common Execution Environments

    WCET Analysis of Java Bytecode Featuring Common Execution Environments Christian Frost, Casper Svenning Jensen, Kasper Søe Luckow, Bent Thomsen Department of Computer Science, Aalborg University Selma Lagerlöfs Vej 300 DK-9220, Aalborg East, Denmark {chrfrost,semadk,luckow,bt}@cs.aau.dk ABSTRACT 1. INTRODUCTION We present a novel tool for statically determining the Worst Java in its traditional form, has inherent issues that makes Case Execution Time (WCET) of Java Bytecode-based pro- it less suitable for development of hard real-time embedded grams called Tool for Execution Time Analysis of Java byte- systems such as the lack of the notion of a deadline and code (TetaJ). This tool differentiates itself from existing high-resolution real-time clocks. To accommodate these, a tools by separating the individual constituents of the execu- variety of initiatives such as the Real-Time Specification tion environment into independent components. The prime for Java (RTSJ) [23] and related profiles: Safety Critical benefit is that it can be used for execution environments Java (SCJ) [16] and Predictable Java (PJ) [9] have been featuring common embedded processors and software im- initiated. These specify certain alterations to the under- plementations of the JVM. TetaJ employs a model checking lying Java Virtual Machine (JVM) and various extensions approach for statically determining WCET where the Java through libraries that, when adhered to, creates a program- program, the JVM, and the hardware are modelled as Net- ming model that can be used for real-time systems devel- works of Timed Automata (NTA) and given as input to the opment in Java.
  • Design Decisions for a Java Processor

    Design Decisions for a Java Processor

    Design Decisions for a Java Processor Martin Schoeberl JOP.design Strausseng. 2-10/2/55, A-1050 Vienna, AUSTRIA [email protected] Abstract The paper is organized as follows: Section 2 gives an overview of the architecture of JOP. In section 3 some This paper describes design decisions for JOP, a Java design decisions for the implementation in an FPGA are Optimized Processor, implemented in an FPGA. FPGA described. One example of the flexibility of an FPGA density-price relationship makes it now possible to con- based architecture is given in section 4. sider them not only for prototyping of processor designs but also as final implementation technology. However, using an FPGA as target platform for a processor dif- 2 Overview of JOP ferent constraints influence the CPU architecture. Digi- tal building blocks that map well in an ASIC can result Figure 1 shows the datapath of JOP. In the first pipe- in poor resource usage in an FPGA. Considering these line stage Java bytecodes, the instructions of the JVM, constraints in the architecture can result in a tiny soft- are fetched. These bytecodes are translated to addresses core processor. in the micro code. Bytecode branches are also decoded and executed in this stage. A fetched bytecode results in an absolute jump in the micro code (the second stage). If 1 Introduction the bytecode has a 1 to 1 mapping with a JOP instruc- tion, a new bytecode is fetched, resulting in a jump in Common design praxis for embedded systems is us- the micro code in the next cycle.
  • JOP: a Java Optimized Processor

    JOP: a Java Optimized Processor

    JOP: A Java Optimized Processor Martin Schoeberl JOP.design, Strausseng. 2-10/2/55, A-1050 Vienna, AUSTRIA [email protected] Abstract. Java is still not a common language for embedded systems. It posses language features, like thread support, that can improve embedded system de- velopment, but common implementations as interpreter or just-in-time compiler are not practical. JOP is a hardware implementation of the Java Virtual Ma- chine with focus on real-time applications. This paper describes the architecture of JOP and proposes a simple real-time extension of Java for JOP. First applica- tion in an industrial system showed that JOP is one way to use Java in the em- bedded world. 1 Introduction Current software design practice for embedded systems is still archaic compared to software development for desktop systems. C and even Assembler is used on top of a small RTOS. The variety of embedded operating systems is large and this fragmenta- tion of the market leads to high cost. Java [1] can be a way out of this dilemma and possess language features not found in C: - Object-oriented - Memory management with a garbage collector - Implicit memory protection - Threads Memory management and threads are (besides device drivers) the main compo- nents of embedded operating systems. Finding these features in the language embed- ded systems can be programmed in Java without the need of an operating system. Java on desktop systems comes with a large library. However, if Java is stripped down to the core components it has a very small memory footprint. With careful pro- gramming (like using only immortal memory as in [2]) the garbage collector can be avoided.