This paper shows how thorough object code optimization has simplified a compiler and made it easy to retarget. The code generator forgoes case analysis and emits naive code that is improved by a retargetable object code optimizer. With this technique, cross-compilers have been built for seven machines, some in as few as three person days. These cross-compilers emit code comparable to host-specific compilers. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors--code genera-tion; compilers; optimization

The New Jersey Machine-Code Toolkit helps programmers write applications that process machine code. Applications that use the toolkit are written at an assembly-language level of abstraction, but they recognize and emit binary. Guided by a short instructionset specification, the toolkit generates all the bitmanipulating code. The toolkit's specification language uses four concepts: fields and tokens describe parts of instructions, patterns describe binary encodings of instructions or groups of instructions, and constructors map between the assembly-language and binary levels. These concepts are suitable for describing both CISC and RISC machines; we have written specifications for the MIPS R3000, SPARC, and Intel 486 instruction sets. We have used the toolkit to help write two applications: a debugger and a linker. The toolkit generates efficient code; for example, the linker emits binary up to 15% faster than it emits assembly language, making it 1.7-2 times faster to produce an a....

- CSDL should support a variety of machine-level tools while remaining inde-pendent of any one in particular.

nML is a formalism targetted for describing arbitrary single-processor computer architectures. nML works at the instruction set level, i.e. it hides implementation issues of the actual machine. nML can be used as an input language for a wide range of tools that need formal machine descriptions. Based on attribute grammars, nML is flexible and reasonably easy to use. Contents 1 Introduction 2 1.1 Where are Machine Descriptions needed? : : : : : : : : : : : : : : : : : : : : : : : : 2 1.2 Different Kinds of Machine Descriptions : : : : : : : : : : : : : : : : : : : : : : : : : 2 1.2.1 GCC's .md format : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 1.2.2 The VHDL Hardware Definition Language : : : : : : : : : : : : : : : : : : : 3 1.3 General aims of nML : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 1.3.1 Abstraction Level : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 1.3.2 Sharing in Descriptions : : : : : : :...

This paper presents an environment that integrates the tasks of translating a source program to machine instructions for a proposed architecture, imitating the execution of these instructions, and collecting measurements. The environment, which is easily retargeted and quickly collects detailed measurements, facilitates experimentation with a proposed architecture and a compiler.

There are more spots than immediately obvious in XQuery expressions where order is immaterial for evaluation— this affects most notably, but not exclusively, expressions in the scope of unordered { } and the argument of fn:unordered (). Clearly, performance gains are lurking behind such expression contexts but the prevalent impact of order on the XQuery semantics reaches deep into any compliant XQuery processor, making it non-trivial to set this potential free. Here, we describe how the relational XQuery compiler Pathfinder uniformly exploits such order indifference in a purely algebraic fashion: Pathfinder-emitted plans faithfully implement the required XQuery order semantics but (locally) ignore order wherever this is admitted.

Destination-driven code generation is a simple top-down technique that allows the code generated for a program phrase to depend upon its context in an abstract syntax tree. The context is encapsulated in a data destination and a control destination. The data destination specifies where the value computed by an expression is to be stored, while the control destination specifies where program execution is to resume after computation of the value. Together, the destinations allow a code generator to specify data and control flow dependencies between subcomputations. As a result, these subcomputations can be "wired" together in an efficient manner. We illustrate the technique by presenting a code generator for a subset of the programming language C. This technique has been used in the implementation of an incremental compiler for the Scheme programming language that generates code for one of several computer architectures.

FPGA systems outperform many ASIC and super computer systems through effective use of the reconfigurable resource. Reusing design effort across different applications requires a standard, flexible software environment. Driving FPGA systems from ANSI C is possible using lcc (an ANSI C compiler) targeted at an FPGA system and dasm (a retargetable, flexible assembler) . The compiler supports custom hardware capabilities of FPGA systems, as well as all constructs of C. The assembler reads instruction definitions at assemble time, allowing the user to add new custom hardware functions which dasm can assemble correctly to an instruction stream the hardware executes. A source code debugger has been implemented for this system. 1 Introduction FPGAs are capable of achieving high performance on many application-specific tasks. In many cases performance achievable with FPGAs on certain applications exceeds comparable ASIC designs or even super computers[2, 7]. One approach used in obtaining this...

The construction of compiler front and back-ends is understood well enough for a great deal of the work to be automated. This paper describes the RTL System, which helps construct the rest of the compiler---the optimizer---by providing a flexible set of classes with a large number of predefined algorithms that the compiler writer can customize. The RTL System differs from systems to construct compiler front and back-ends because it does not specify the optimizations with a specialized language, but is instead an objectoriented framework. This paper describes the framework and how it can be used to build a code optimizer. 1 Introduction Compiler front and back-ends are understood well enough for them to be generated automatically. A parser generator can create the parser from a grammar describing the language, and a code generator can be built automatically from a description of the machine. However, the construction of an optimizer is much less straightforward. This paper describes th...

Modern optimizing compilers apply a fixed sequence of optimizations, which we call a compilation sequence, to each program that they compile. These compilers let the user modify their behavior in a small number of specified ways, using command-line flags (e.g.,-O1,-O2,...). For five years, we have been working with compilers that automatically select an appropriate compilation sequence for each input program. These adaptive compilers discover a good compilation sequence tailored to the input program, the target machine, and a user-chosen objective function. We have shown, as have others, that program-specific sequences can produce better results than any single universal sequence [1, 23, 7, 10, 21] Our adaptive compiler looks for compilation sequences in a large and complex search space. Its typical compilation sequence includes 10 passes (with possible repeats) chosen from the 16 available—there are 16 10 or 1,099,511,627,776 such sequences. To learn about the properties of such spaces, we have studied subspaces that consist of 10 passes drawn from a set of 5 (5 10 or 9,765,625 sequences). These 10of-5 subspaces are small enough that we can analyze them thoroughly but large enough to reflect important properties of the full spaces. This paper reports, in detail, on our analysis of several of these subspaces and on the consequences of those observed properties for the design of search algorithms. 1 Compilation Sequences Compilers operate by applying a fixed sequence of optimizations, called a compilation sequence, to all programs. The compiler writer must select ten to twenty optimizations from the hundreds that have been pro-