Traditional database management systems perform updates-in-place and use logs and periodic checkpointing to efficiently achieve atomicity and durability. In this Thesis we shall present a different method, Shades, for achieving atomicity and durability using a copy-on-write policy instead of updates-in-place. We shall also present index structures and the implementation of Shines, a persistent functional programming language, built on top of Shades. Shades includes real-time generational garbage collection. Real-timeness is achieved by collecting only a small part, a generation, of the database at a time. Contrary to previously presented persistent garbage collection algorithms, Shades has no need to maintain metadata (remembered sets) of intra-generation pointers on disk since the metadata can be reconstructed during recovery. This considerably reduces the amount of disk writing. In conjunction with aggressive commit grouping, efficient index structures, a design specialized to a main memory environment, and a carefully crafted implementation of Shines, we have achieved surprisingly high performance, handsomely beating commercial database management systems.

this paper is to help clear up some confusion about developing software with Modula-3. In particular, we will concentrate on using Modula-3 to write an operating system, which is where our primary experience lies. The key point with which we hope to leave the reader is that there is a fundamental difference between a programming language, and a particular implementation of that language. For example, there are many different versions of the C compiler and its runtime utilities. In the 80's though, BSD UNIX's pcc and libc.a

In real-time systems the correctness of the computation depends not only on the logical correctness of the answer, but also on when it is produced. Run-time management in a real-time system must therefore exercise detailed control of how and when computations execute. As a result, most approaches to real-time scheduling require substantially more information about a computation's run-time behavior than those used by conventional (non-real-time) systems. The computation behaviors of concern vary with each system, but include: deadline, worst case execution time (WCET), resource use, communication behavior, and precedence relations. One of the ways in which real-time systems are significantly different from conventional systems is that much of of...

this paper discusses only its application to switch statements. There has been considerable work in the past ([2], [3], [5], [6] and [10]) on the Pascal case statement and code generation. The generation of code for switch statements is discussed in [4] and [11]. A scheme similar to MRST, but restricted to binary radix search trees, appears in [9]. Preprint submitted to Elsevier Preprint 8 August 1997 Applications for fast sparse switch statements are many and varied. Two examples are: -- Let L be a Common-Lisp-like language with dynamic type dispatch on function arguments. Let F be an n argument generic function in L, with

. Given an alphabet \Sigma = fa1 ; : : : ; ang with a corresponding list of positive weights fw1 ; : : : ; wng and a length restriction L, the length-restricted prefix code problem is to find, a prefix code that minimizes P n i=1 w i l i , where l i , the length of the codeword assigned to a i , cannot be greater than L, for i = 1; : : : ; n. In this paper, we present an efficient implementation of the WARM-UP algorithm, an approximative method for this problem. The worst-case time complexity of WARM-UP is O(n log n +n log wn ), where wn is the greatest weight. However, some experiments with a previous implementation of WARM-UP show that it runs in linear time for several practical cases, if the input weights are already sorted. In addition, it often produces optimal codes. The proposed implementation combines two new enhancements to reduce the space usage of WARM-UP and to improve its execution time. As a result, it is about ten times faster than the previous implementat...

Recent research on timing analysis has focused on static methods to predict worst-case execution times that provide safe approximations of the actual worst-case execution time of real-time tasks. Since these predictions are verifiable, they can be used in schedulability analysis so that the overall temporal behavior of tasks can be analyzed. This paper details our efforts to integrate a commonly available and widely accepted compiler, the Gnat/Gcc family, into our tool set for timing analysis. We discuss the design and implementation of our modifications to Gnat/Gcc, where we accommodated our enhancements in a widely portable way within the common back-end of Gnat and Gcc. With this work, it is our aim to make the analytical approach of static timing analysis available to the real-time community. 1. Introduction Real-time applications are concerned with the timely execution of tasks in response to events. In this context, the deadline of a task describes the latest point in time wher...

Assignment ImplicitAssignment Assignment PhiAssignment Jump CondJump Return The subclasses play the following roles: EmptyRegisterTransfer: used in the instruction builder to represent transfers that only set flags. See Chapter 8. RegisterTransferSet: represents sets of RegisterTransfers to be performed concurrently. Theoretically, this is a recursive structure, since it could contain an instance of itself; however, this is never allowed. Its only instance variable is transfers, an OrderedCollection of the component transfers. Call: represents procedure calls. Its instance variables are method, the Register containing the callee's address; returnValueRegister, the Register in which the result of the call will be found; and argumentLogicalRegisters, an OrderedCollection of the Registers that contain the receiver and the first two arguments. AbstractAssignment: the abstract superclass of all classes representing assignments to some storage. Its only instance variable is destinatio...

The image processing applications require both computing and input/output power. The GFLOPS project's aim is to develop a parallel architecture as well as its software environment to implement those applications efficiently. This goal can be achieved only with a real collaboration among the architecture, the compiler and the programming language. This paper investigates the C// on global address space architectures. The main advantage of our paradigm is that it allows a unique framework to express both data and control parallelism We will first present the structure of the GFLOPS machine used to implement this language. The C// parallel language will be presented in the next section, and finally we will evaluate the effectiveness of the mechanisms incorporated in the architecture to implement the high level C// structures. 1. Introduction Most recent MPP systems employ fast sequential microprocessors surrounded by a shell of communication and synchronization logic. The GFLOPS computer...

We describe a new system for automatic compiler retargeting. The system combines the advantages of C code generating compilers (fast retargeting) with the advantages of compilers based on specification driven code generation (fast native code generation) .

this report, are due to the front-end adopted for the first compilation stage from C or C++ source files, which is the Free Software Foundation GNU compiler (called gcc). Even though it is a good quality, widely supported and tested compiler, gcc produces intermediate code strongly oriented to typical workstation architectures, which does not fully match ASP application requirements. Some of the characteristics of the intermediate code turn out to limit the architecture template: 1. Data word width and address space are fixed to 32 bits. 2. Memory partitioning is limited to a single memory bank for data and one bank for instructions. No partitioning of data into multiple, user definable memories is possible. 3. Automatic variables are always dynamically allocated: it is not possible to allocate temporary variables into a static stack. 4. Memory is addressed by 8 bit bytes [30]. In addition to these limitations, some parts of the back-end, the MOVE instruction scheduler, present room for improvements which should significantly reflect on compiled code performance: