This white paper describes Scout, a new operating system being designed for systems connected to the National Information Infrastructure (NII). Scout provides a communication-oriented software architecture for building operating system code that is specialized for the different systems that we expect to be available on the NII. It includes an explicit path abstraction that both facilitates effective resource management and permits optimizations of the critical path that I/O data follows. These path-enabled optimizations, along with the application of advanced compiler techniques, result in a system that has both predictable and scalable performance. June 17, 1994 Department of Computer Science The University of Arizona Tucson, AZ 1 Introduction As the National Information Infrastructure (NII) evolves, and digital computer networks become ubiquitous, communication will play an increasingly important role in computer systems. In fact, a recent report on the NII rejects the term "compu...

This paper introduces superoperators, an optimization technique for bytecoded interpreters. Superoperators are virtual machine operations automatically synthesized from smaller operations to avoid costly per-operation overheads. Superoperators decrease executable size and can double or triple the speed of interpreted programs. The paper describes a simple and effective heuristic for inferring powerful superoperators from the usage patterns of simple operators. The paper describes the design and implementation of a hybrid translator/interpreter that employs superoperators. From a specification of the superoperators (either automatically inferred or manually chosen), the system builds an efficient implementation of the virtual machine in assembly language. The system is easily retargetable and currently runs on the MIPS R3000 and the SPARC.

Dynamic code generation allows aggressive optimization through the use of runtime information. Previous systems typically relied on ad hoc code generators that were not designed for retargetability, and did not shield the client from machine-specific details. We present a system, dcg, that allows clients to specify dynamically generated code in a machineindependent manner. Our one-pass code generator is easily retargeted and extremely efficient (code generation costs approximately 350 instructions per generated instruction). Experiments show that dynamic code generation increases some application speeds by over an order of magnitude.

Abstract not found

INTRODUCTION The Java language [Gosling et al. 1996], while enjoying widespread use in many application domains, is by design also meant to be used in embedded systems. This is witnessed by the availability of specific APIs, such as the JavaCard and EmbeddedJava specifications [Sun Microsystems, Inc. 1997; 1998a; 1999b; 1999c; 1999d]. The primary advantage of Java in this context is portability, which is realized through the Java bytecode format [Lindholm and Yellin 1996]. The use of a standard format allows any third-party developed services to be installed on any Java-compatible embedded system. Low-end embedded systems, such as smart-cards, have strong restrictions on the amount of available memory, severely limiting the size of applications that they can run. Memory is scarce for a number of reasons: production costs must be kept low; power consumption must be minimized; and available physical space is limited. This research was supported in part by Bull. Authors'

Languages with programmer-visible stacks (stack-based languages) are used widely, as intermediate languages (e.g., JavaVM, FCode), and as languages for human programmers (e.g., Forth, PostScript). However, the prevalent computer architecture is the register machine. This poses the problem of efficiently implementing stack-based languages on register machines. A straight-forward implementation of the stack consists of a memory area that contains the stack items, and a pointer to the top-of-stack item. The basic

Interfaces --- the collection of procedures and data structures that define a library, a subsystem, a module --- are syntactically poor programming languages. They have state (defined both by the interface's data structures and internally), operations on this state (defined by the interface's procedures), and semantics associated with these operations. Given a way to incorporate interface semantics into compilation, interfaces can be compiled in the same manner as traditional languages such as ANSI C or FORTRAN. This paper makes two contributions. First, it proposes and explores the metaphor of interface compilation, and provides the beginnings of a programming methodology for exploiting it. Second, it presents Magik, a system built to support interface compilation. Using Magik, software developers can build optimizers and checkers for their interface languages, and have these extensions incorporated into compilation, with a corresponding gain in efficiency and safety. This organization contrasts with traditional compilation, which relegates programmers to the role of passive consumers, rather than active exploiters of a compiler's transformational abilities. 1

To compete with optimized C, object-oriented languages need classical optimizations as well as specific object-oriented optimizations. Therefore, a compiler infrastructure that enables object-oriented compiler research isof great interest for the research community. The SUIF compiler system with the OSUIF extension offers such a research environment. SUIF defines an intermediate representation for procedural languages and offers standard optimization passes. OSUIF extends SUIF with an intermediate representation tailored towards object-oriented languages, hence allowing specific object-oriented optimizations. To enable Java-related compiler research in (O)SUIF, we have implemented j2s, a Java bytecode front end for the OSUIF/SUIF 2.0 compiler system. Our compiler uses off-line compilation, so that the whole program is known at compile time. Thus, static whole-program optimizations such as class hierarchy analysis and type inference can be implemented with (O)SUIF and applied during the compilation. j2s supports the complete Java Virtual Machine specification, except for threads and exception handling, which are currently not supported by the runtime system and (O)SUIF. Because we implemented an off-line compiler, the dynamic loading of classes is also not supported. The compiler is divided into the (O)SUIF front end and the runtime system. The main part of

This document describes the intermediate program representation DCode. The representation is an ASCII format which specifies instructions for an abstract stack machine. Interpretive code generators may process this file to produce object code for various target machines. The semantics of each instruction in the code is explained, and the various directives detailed. This document is intended to serve as a guide for those wishing to create new code generator backends for the existing compilers, and for those wishing to create frontends for a new language for the existing code generators. The first part of the report is a concise reference manual for the language, while the second part is a detailed description of the way in which the language is used in typical cases. The second part describes the way in which the form is used in typical cases, and contains a number of examples. The DCode Report, revision 2.1 1 Copyright This report is copyright c fl 1993--1994, Faculty of Informati...

In this paper we present a compiler testing technique that closes the gap between existing compiler implementations and correct compilers. Using formal specifications of procedure calling conventions, we have built a target-sensitive test suite generator that builds test cases for a specific aspect of compiler code generators: the procedure calling sequence generator. By exercising compilers with these specification-derived target-specific test suites, our automated testing tool has exposed bugs in every compiler tested. These compilers include some that have been in heavy use for many years. Once a fault has been detected, the system can often suggest the nature of the problem. The testing system is an invaluable tool for detecting, isolating, and correcting faults in today's compilers.