Architecture The Alma Abstract Architecture (AAA) is the virtual architecture used during the intermediate code generation phase of the Alma-0 compiler. The AAA combines the features of the abstract machines for imperative languages and for logic programming languages. The compiler compiles the Alma-0 programs into AAA programs. In a second phase the AAA instructions are translated into C statements. As the Alma-0 language itself, the AAA aims to combine the best of both worlds; elements were taken from virtual machines used to compile imperative languages (in particular the RISC architecture described in Wirth [1996, pp. 55--59], and from the WAM machine used to compile a logical language (see Ait-Kaci [1991]). Still, the AAA resembles most the virtual machines used in the compilation of imperative languages. The additions made to provide for the extensions of the Alma-0 language are ---the failure handling instructions ONFAIL, FAIL, 40 \Delta Krzysztof R. Apt et al ---the log ...

A major problem for writing extensible software arises when recursively defined datatypes and operations on these types have to be extended simultaneously without modifying existing code. This paper introduces Extensible Algebraic Datatypes with Defaults which promote a simple programming pattern to solve this well known problem. We show that it is possible to encode extensible algebraic datatypes in an object-oriented language, using a new design pattern for extensible visitors. Extensible algebraic datatypes have been successfully applied in the implementation of an extensible Java compiler. Our technique allows for the reuse of existing components in compiler extensions without the need for any adaptations.

Machine, abbreviated to AAA), which combines the features of abstract machines for imperative languages with those of abstract machines for logical languages. Part II describes the implementation of the Alma-0 compiler in detail, from lexical analysis to code generation and the run-time system. It not only describes the current implementation, but commentary sections describe the problems encountered during the implementation and the motivations behind certain solutions. These sections have been divided from the main text by large captions, and can be recognized by the little "c" after the section number. I would like to thank Krzysztof Apt for his support, and for the enlightening conversations I've had with him on many a rainy morning, and, if one of the mornings was not rainy, it should have been, just for the effect. My fellow students should be thanked for their interesting remarks and discussions, whether they concerned my project or not. Finally, I would especially like to tha...

We present a concurrent compiler for Active Oberon built itself with active objects. We describe the experience made on parallelizing the Oberon compiler, in particular explaining how concurrency and synchronization are achieved by using active objects, and showing how we achieved ensured deadlock freedom. Based on the implementation, we discuss why we consider active objects beneficial for the implementation of software frameworks and where their limitations are.

Abstract. Recursive descent parsing is restricted to languages whose grammars are LL(1), i.e., which can be parsed top-down with a single lookahead symbol. Unfortunately, many languages such as Java, C++, or C # are not LL(1). Therefore recursive descent parsing cannot be used or the parser has to make its decisions based on semantic information or a multi-symbol lookahead. In this paper we suggest a systematic technique for resolving LL(1) conflicts in recursive descent parsing and show how to integrate it into a compiler generator (Coco/R [9]). The idea is to evaluate user-defined boolean expressions, in order to allow the parser to make its parsing decisions where a one symbol lookahead does not suffice. Using our extended compiler generator we implemented a compiler front end for C # that can be used as a framework for implementing a variety of tools. 1

The ever-increasing complexity of today’s hardware designs also increases the challenge of verifying those designs. With more transistors crammed onto chips, the design’s state space (which directly relates to its complexity) can be considered to grow exponentially, while the computational power (which relates to the ability to verify the design) only grows linearly. This results in the so-called verification gap: the efforts necessary to provide satisfying verification results are rising. In today’s larger projects the verification engineers may even outnumber the design engineers. Thus, the semiconductor industry is constantly searching for ways to minimize the verification efforts while still achieving the desired results. Assertion-based verification (ABV), which can be used to specify both the design’s properties and behavior is constantly catching on. Using specialized languages such as PSL (Property Specification Language) or SVA (SystemVerilog Assertions) allows the engineers to define properties during the implementation or even during the specification phase. Those properties can be used in formal, semi-formal, or functional tools to verify the design’s correctness. An additional trend in today’s hardware verification is simulation acceleration and emulation. These approaches source parts of the design under verification out on an FPGA, where they can be run by orders of magnitude faster than in simulation. Such acceleration systems rely on the ability to synthesize parts of the design under verification, however: otherwise they could not source them out into hardware. Therefore, in order to deploy them in an ABV-based project, a way to incorporate the assertions in hardware needs to be found. This is what this thesis aims to do: it will provide a way to generate synthesizable HDL code from PSL assertions. First, PSL will be divided in base cases, denoted PSLmin, and more complex constructs that can be rewritten to the base cases. Then an automatatheoretic approach for representing PSLmin will be shown before a simple tool implementing the algorithms described is presented and simulation, synthesis, and emulation results are given.

The project Cing consists of a compiler and a virtual machine. It is part of the compiler construction course held by Prof. Christoph Kirsch in SS 2007 at the University of Salzburg. The compiler interprets and translates our own defined programming language, which is a subset of the.NETlanguage C#. This report is the technical documentation of our implementation and shows the problems and solutions for implementing a self-compiling compiler. 2

1.1 Features................................ 4 1.2 Input language............................ 5

In this paper we present the design and implementation of the BoA programming language, the BoA compiler, and the BoA virtual machine. The objective of this project was to create a simple programming language and a self-hosting compiler. The resulting language BoA is meant to be a simplified version of Python, although it is not a subset. BoA extends Python in a number of ways, most notable in its static type system. 1

The Minimal Interpreted C Environment project (Mice) is an attempt to create a simple toolchain for a subset of ANSI C, conststing of compiler, linker and virtual machine (VM). Primary goal is to reach self-bootstrapping capability within the timeframe of the summer 2006 compiler construction class of Prof. Kirsch. For a more detailed list of goals please refer to the according section below. Further emphasis will be on clean interfaces between the compiler’s subsystems. Even though being written in a subset of C, the Mice components ’ source code will read like just another reasonably well written C source. Therefore, if during implementation obstacles are encountered that would easily be solvable using additional C language functionality, the compiler’s featureset is extended rather than resorting to workarounds that could obfuscate the algorithms and data structures used. The implementation is conducted as simple and obvious as possible, considerable