To an unappreciated degree, research both in operating systems and their programming languages has been severely hampered by the lack of cleanly reusable code providing mundane low-level OS infrastructure such as bootstrapcode and device drivers. The Flux OS Toolkit solves this problem by providing a set of clean, well-documented components. These components can be used as basic buildingblocks both for operating systems and for booting language run-time systems directly on the hardware. The toolkit’s implementation itself embodies reuse techniques by incorporating components such as device drivers, file systems, and networking code, unchanged, from other sources. We believe the kit also makes feasible the production of highly assured embedded and operating systems: by enabling reuse of low-level code, the high cost of detailed verification of that code can be amortized over many systems for critical environments. The OS toolkit is already heavily used in several different OS and programming language projects, and has already catalyzed research and development that would otherwise never have been attempted.

is not the first till it comes to nought; then the first count is the sum. 4 2 5 0 Four plus two is the same as five plus one, which is the same as six plus nought, which is six. We shall take the word many to mean "more than two in number." Think of a machine that can keep track of two numbers, and count each one up or down, and test if a number be nought and by such a test choose to do this or that. The list of things that it can do and of choices that it can make must be of a known size that is some number. Here you can see the two numbers and a list. The machine starts its work with the first row of the list. Each row in the list has a state name; the word "up" or "down"; and which number to count up or count down. For "up," we have the name of the next state to go to (and the machine counts the number up by one); for "down," the machine first tests the number, and so we have the name of the new state to go to if the number be nought and the name of the new stat

The ultimate goal of all computer science is the program. The performance of programs was once the noblest function of computer science, and computer science was indispensable to great programs. Today, programming and computer science exist in complacent isolation, and can only be rescued by the conscious co-operation and collaboration of all programmers. The universities were unable to produce this unity; and how indeed, should they have done so, since creativity cannot be taught? Designers, programmers and engineers must once again come to know and comprehend the composite character of a program, both as an entity and in terms of its various parts. Then their work will be filled with that true software spirit which, as “theory of computing”, it has lost. Universities must return to programming. The worlds of the formal methods and algorithm analysis, consisting only of logic and mathematics, must become once again a world in which things are built. If the young person who rejoices in creative activity now begins his career as in the older days by learning to program, then the unproductive “scientist ” will no longer be condemned to inadequate science, for their skills will be preserved for the programming in which they can achieve great things. Designers, programmers, engineers, we must all return to programming! There is no essential difference between the computer scientist and the programmer. The computer scientist is an exalted programmer. By the grace of Heaven and in rare moments of inspiration which transcend the will, computer science may unconsciously blossom from the labour of the hand, but a base in programming is essential to every computer scientist. It is there that the original source of creativity lies. Let us therefore create a new guild of programmers without the class-distinctions that raise an arrogant barrier between programmers and computer scientists! Let us desire, conceive, and create the new program of the future together. It will combine design, user-interfaces, and programming in a single form, and will one day rise towards the heavens from the hands of a million workers as the crystalline symbol of a new and coming faith. 1 1

this paper were formatted input and output of the prototype preprocessor. The prototype is a one-pass preprocessor whose only input is a single source file and whose outputs are the preprocessed source along with a header file. The functionality of the prototype is limited by the fact that it is first in the chain of compilation, prior to the regular C preprocessor. This was done to keep the prototype small and simple. A full implementation should be in the form of a plug-in replacement for the C preprocessor. That way, any implementation conflicts which might arise between the Robust C functions and the regular C preprocessor functions can be transparently resolved

For the last 15 years, implementors of multiple view programming environments have sought a single code model that would form a suitable basis for all of the program analyses and tools that might be applied to the code. They have been unsuccessful. The consequences are a tendency to build monolithic, single-purpose tools, each of which implements its own specialized analyses and optimized representation. This restricts the availability of the analyses, and also limits the reusability of the representation by other tools. Unintegrated tools also produce inconsistent views, which reduce the value of multiple views. This paper describes an architecture that allows a single, minimal representation of program code to be extended as required to support new tools and program analyses, while still maintaining a simple and uniform interface to program properties. We present architectural patterns that address efficiency, correctness and the integration of multiple analyses and tools in a modular fashion.

The design constraints in ubiquitous computing (ubicomp) differ from those traditionally emphasized by the systems community: evolvability, long-term maintainability, and robustness to transient failures are essential, while scalability and performance are lesser concerns, due to the nature of ubicomp itself and the performance of today's commodity equipment. We show how these observations are reflected in the design of iROS, a ubicomp software framework in production use. In particular, we show that a centralized architecture directly enables the ubicomp programming abstractions needed while providing the best solution for evolvability and maintainability/deployability, and that we can achieve the required robustness through a fast-recovery strategy, which allows a simple centralized implementation of the architecture. Throughout, we achieve performance, scalability, and recovery behavior sufficient for typical operation.

This is the first in a series of articles on Lisp performance, called "Performing Lisp". This paper analyzes the FANNKUCH benchmark, that was discussed on the comp.lang.lisp internet newsgroup during September 1994, and reviews the performance issues underlying it. This benchmark involves operations on integers and vectors of integers so one might expect that Lisp and C versions could have comparable performance. However, the original benchmark suggested that the Lisp version was at least 10 times slower than the C version. While this version appeared to be optimized, several important improvements are possible. The improved version is between 24 and 116 percent slower than C when run on several Lisp implementations. This can be accounted for by differences in the quality of the compiled code of the inner loops of the benchmark, not by an essential difference between the two languages. The GNU C compiler, gcc, produces a loop with a larger overall size (footprint) but with a sma...

: In this paper the architecture of the VITAL-KR is described. Author: Enrico Motta and Arthur Stutt Collaborators (VITAL Partners): SYSECA - SYSECA TEMPS REEL (Coordinator) * NOTT - UNIVERSITY OF NOTTINGHAM * BULL - BULL CEDIAG AC - ANDERSEN CONSULTING ONERA - ONERA PTT - ROYAL PTT NEDERLAND NV * OU - THE OPEN UNIVERSITY * NOKIA - NOKIA RESEARCH CENTER * marked partners are involved in this task page 1 _____________________________________________________________________ The Open University 1991 1. INTRODUCTION As discussed in (Motta, 1991) both the current practice of industrial KBS, and the consensus among researchers (Frisch & Cohn, 1991) suggest that hybrid architectures, embedding a number of specialized representations/reasoners, are required to enable knowledge engineers to build efficient and powerful KBs. This is due to the fact that it has been recognized that no universal knowledge representation language exists, which can efficiently model all types of proble...

A number of recent developments in software engineering --- from agile methods to aspect-oriented programming to design patterns to good enough software --- share a number of common attributes. These developments avoid a unifying theme or plan, focus on negotiation between different concerns, and exhibit a high level of context sensitivity. We argue that these developments are evidence of a postmodern turn in software engineering. In this paper, we survey a number of these developments and describe their potential implications for the practice of conceptual modelling.