The Mesa programming environment

Adaptation of operating systems to a new processor architecture is a complicated process during which incompatible parts of an embedded operating system have to be redesigned and missing parts have to be implemented. The complications grow when there is a need to adapt operating system to completely different processor architecture as was an operating system optimised for. During our work on this problem we proposed a tool which reduces effect of these complications to a minimum. The tool uses a processor formal description file, which can act as a standard for processor manufacturers, and could help during generation of a platform dependent code of the operating system kernel. As a result of a platform code generation the adaptation time of operating system was reduced into platform independent adjustments. In this paper reader will find the recent status of work on an operating system adaptation process. A generator of platform-dependent code is described together with a framework that will help to shorten the adaptation process of any operating system.

Improvements in distributed computing, and the technologies that enable them, have led to significant advancements in middleware functionality and quality, mainly through networking and protocols. However, the distributed programing style has changed little over the years. Most programs are still written line per line of code in languages such as C, C++, and Java. These conventional programs that can provide grid operations and grid data can be considered as common grid resources and shared by research and education communities worldwide. However, there are no relevant programing methodologies to utilize efficiently these shared service providers as a potentially vast grid repository, except through the manual writing of code. Realization of the potential of grid computing requires significant improvements in grid programing methodologies. The Grid interactive service-oriented (GISO) methodology presented provides a programming environment with development tools that permit true interactive grid programming. The GISO approach permits the different elements of programming to be stored, reused, aggregated, and executed with concurrency and a grid-level control strategy not achievable in the conventional programming languages.

The standard tools for cloud computing — processor and network virtualization — make it difficult to achieve dependability, both in terms of real time operations and fault tolerance. Virtualization multiplexes virtual resources onto physical ones, typically by time division or statistical multiplexing. Time, in the virtual machine, is therefore as virtual as the machine itself. And fault tolerance is difficult to achieve when redundancy and independent failure in the virtual environment do not necessarily map to those properties in the physical environment. Virtualization adds a level of indirection that creates overhead, and makes it all but impossible to achieve predictable performance. Osprey uses an alternative to virtualization that achieves the same goals of scalability and flexibility but carries neither the overhead of virtualization, nor the restrictions on dependability. The result is a programming environment that achieves most of the compatibility offered by traditional virtualization efforts and provides much better and much more predictable performance. One technique we use is called Library OS, which stems from high-performance computing. The technique consists of linking applications with a library that implements most services normally provided by the operating system, creating an application that can run practically stand alone, or at least with a very minimal operating system. The Library OS approach moves the boundary between application and operating system down to a level where interactions with the operating system consist of sending/receiving messages (e.g., network packets) and scheduling resources (processor, memory, network bandwidth, and device access). These interactions, as we demonstrate, form a relatively weak bond between an application and the particular instance of the operating system on which it runs — one that can be broken and re-established elsewhere. In fact, we make sure this is the case. Legacy applications that cannot be recompiled or relinked can make use of a Library OS server that runs as a tandem process along with the legacy application processes. System calls from the legacy process are catapulted into the Library OS server which executes them. Applications can still migrate, taking their server process along with them. © 2012 Alcatel-Lucent.

There are few open source autonomous driving planners that are general enough to be used directly, or which could be easily customized to suit a particular application. OpenPlanner 1.0 was introduced back in 2017 to fill this gap. It was developed and integrated with the open source autonomous driving framework Autoware. Since then, many improvements have been introduced, following the original design goals. In this paper, the basic design will be re-introduced along with the latest developed technologies. The new planner is called OpenPlanner 2.0 and includes several new techniques such as multiple HD road network map formats support, trajectory and behavior estimation, planning based HMI support, path generation using kinematics based motion simulation and lane change behavior. OpenPlanner 2.0 is already attracting attention from the autonomous driving research and development communities; universities and companies. Several projects are using and contributing to its code base. Some of these applications will be discussed in this paper as well. A comparison between OpenPlanner and other open source planners showing the aspects where it is superior is also presented.

The 3200-seat Congress Hall in Jerusalem, Israel, was completed in the spring of 1960 after a construction period of some ten years. The original primary design goal was to provide a place for large assemblies, the most important of which was the semiannual meeting of the World Zionist Congress. During construction, the repeated use of the partially completed “unroofed” structure for outdoor concerts led to the reconsideration of the original design goals to give primary emphasis to music. The hall now has become the home of the Israeli Philharmonic while still serving its function for congresses and other uses. This paper traces the development of the acoustical design goals as well as discusses the important acoustical design features, the results of measurements made in the completed hall, and the reactions of musicians who have played in the hall.

Application of SLAM in the design and performance analysis of a multi-processor database system

: A full-scale demonstration plant utilizing ozone/ultraviolet radiation for removal of cyanide from electroplating wastes was optimized and tested at Tinker Air Force Base, Oklahoma. The original design goal was to reduce cyanide concentrations to nondetectable limits in a waste stream (6.25 gallons per hour) containing up to 50,000 milligrams per liter cyanide. Study results are supplemented by a review of literature related to ozone oxidation. The report summarizes equipment operational and plant design deficiencies identified and corrected. Major problems included compressors breakdown, oil carry-over, inefficient air filters, inoperable dryers, inadequate ventilation, low power output from ozone generators and an inefficient ozone contact system.

The decision to improve consumer interface with on-board vehicle systems in the new Buick Riviera presented many challenges. The major challenges were how to display the information and how to optimize the driver's interface with the display. Challenges were met with the development of an interactive and reconfigurable display system based on CRT (Cathode Ray Tube) and transparent membrane switch technologies. Human factors concerns were resolved, design requirements were met, limitations in existing technologies were overcome, and testing has verified that original design goals were met or exceeded.

This paper discusses the basic design of the encoding scheme described by the Text Encoding Initiative’s Guidelines for Electronic Text Encoding and Interchange (TEI document number TEI P3, hereafter simply P3 or the Guidelines).1 It first reviews the basic design goals of the TEI project and their development during the course of the project. Next, it outlines some basic notions relevant for the design of any markup language and uses those notions to describe the basic structure of the TEI encoding scheme. It also describes briefly the “core” tag set defined in chapter 6 of P3, and the “default text structure” defined in chapter 7 of that work. The final section of the paper attempts an evaluation of P3 in the light of its original design goals, and outlines areas in which further work is still needed.

Data sets in large applications are often too massive to fit completely inside the computers internal memory. The resulting input/output communication (or I/O) between fast internal memory and slower external memory (such as disks) can be a major performance bottleneck. In this article we survey the state of the art in the design and analysis of external memory (or EM) algorithms and data structures, where the goal is to exploit locality in order to reduce the I/O costs. We consider a variety of EM paradigms for solving batched and online problems efficiently in external memory. For the batched problem of sorting and related problems such as permuting and fast Fourier transform, the key paradigms include distribution and merging. The paradigm of disk striping offers an elegant way to use multiple disks in parallel. For sorting, however, disk striping can be nonoptimal with respect to I/O, so to gain further improvements we discuss distribution and merging techniques for using the disks independently. We also consider useful techniques for batched EM problems involving matrices (such as matrix multiplication and transposition), geometric data (such as finding intersections and constructing convex hulls), and graphs (such as list ranking, connected components, topological sorting, and shortest paths). In the online domain, canonical EM applications include dictionary lookup and range searching. The two important classes of indexed data structures are based upon extendible hashing and B-trees. The paradigms of filtering and bootstrapping provide a convenient means in online data structures to make effective use of the data accessed from disk. We also reexamine some of the above EM problems in slightly different settings, such as when the data items are moving, when the data items are variable-length (e.g., text strings), or when the allocated amount of internal memory can change dynamically. Programming tools and environments are available for simplifying the EM programming task. During the course of the survey, we report on some experiments in the domain of spatial databases using the TPIE system (transparent parallel I/O programming environment). The newly developed EM algorithms and data structures that incorporate the paradigms we discuss are significantly faster than methods currently used in practice.

Constructing an embedded device with a real-time and a general-purpose operating system has attracted attention as a promising approach to let the device balance real-time responsiveness and rich functionalities. This paper introduces our methodology for constructing such multi-OS platform with minimal engineering cost by assuming asymmetric OS combinations unique to embedded systems. Our methodology consists of two parts. One is a simple hypervisor for multiplexing resources to be shared between operating systems. The other is modifying operating systems to allow them to be aware of each other. We constructed an experimental system executing TOPPERS and Linux simultaneously on a hardware equipped with an SH-4A processor. The modification to each operating system kernel limited to a few dozen lines of code and do not introduce any overhead that would compromise real-time responsiveness or system throughput.KeywordsEmbed SystemEngineering CostEmbed DeviceVirtual Machine MonitorVirtual ProcessorThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

The SCREEN system is an experimental tool for development and maintenance of application software. It is organized as a System of Communicating REsidential ENvironments, where each environment may be e.g. a programming environment or an end-user environment. Environments are able to send and receive modules which contain programs and data, and the maintenance of an application (throughout the software life-cycle) is performed by communicating such modules. Each programming environment may send several modules to each of several end-user environments, to account for specialized user needs, as well as updates of those modules.End-user environments consist of a fixed framework, into which contributed modules can plug in. The framework is designed specifically for each class of applications, and can be viewed as a special-purpose operating system for that class of applications. The organizational principles used in the SCREEN system are an extension of the residential programming systems that have been developed for Lisp, but they have an increased emphasis on software engineering issues. They represent an alternative to the classical principles for the production and use of software, which are based on the use of compilers, linkage editors, and general-purpose operating systems.

JavaScript is a language that is widely-used for both web- based and standalone applications such as those in the upcoming Windows 8 operating system. Analysis of JavaScript has long been known to be challenging due to its dynamic nature. On top of that, most JavaScript applications rely on large and complex libraries and frameworks, often written in a combination of JavaScript and native code such as C and C++. Stubs have been commonly employed as a partial specification mechanism to address the library problem; however, they are tedious to write, incomplete, and occasionally incorrect. However, the manner in which library code is used within applications often sheds light on what library APIs return or consume as parameters. In this paper, we propose a technique which combines pointer analysis with use analysis to handle many challenges posed by large JavaScript libraries. Our approach enables a variety of applications, ranging from call graph discovery to auto-complete to supporting runtime optimizations. Our techniques have been implemented and empirically validated on a set of 25 Windows 8 JavaScript applications, averaging 1,587 lines of code, demonstrating a combination of scalability and precision.

Protecting commodity operating systems against software exploits is known to be challenging, because of their sheer size. The same goes for key software applications such as web browsers or mail clients. As a consequence, a significant fraction of internet-connected computers is infected with malware.To mitigate this threat, we propose a combined approach of (1) a run-time security architecture that can efficiently protect fine-grained software modules executing on a standard operating system, and (2) a compiler that compiles standard C source code modules to such protected binary modules.The offered security guarantees are significant: relying on a TCB of only a few thousand lines of code, we show that the power of arbitrary kernel-level or process-level malware is reduced to interacting with the module through the module's public API. With a proper API design and implementation, modules are fully protected.The run-time architecture can be loaded on demand and only incurs performance overhead when it is loaded. Benchmarks show that, once loaded, it incurs a 3.22% system-wide performance cost. For applications that make intensive use of protected modules, and hence benefit most of the security guarantees provided, the performance cost is up to 14%.

Summary Open architecture has reshaped the computer marketplace and has significantly affected the development, maintenance, and application of reservoir simulation technology. We have moved rapidly from mainframe computers to distributed applications on workstations. Here, we discuss four open-systems initiatives (communication, language, operating system, and graphics) that have particularly influenced reservoir simulation at Mobil R and D Corp. Over the last 2 decades, our simulators have grown from 50,000-line single-well programs to greater than 1.5-million lines of code in the current field simulator. Advances in open systems have enabled us to manage this explosive growth on a network of workstations. We have been able to standardize around the UNIX operating system and C and FORTRAN languages. X-Window MOTIF-based interactive graphics have been a key element in migrating the simulator to a variety of computers. Although these open-architecture initiatives have had a significant and positive impact on reservoir simulation at Mobil, we still are faced with certain disadvantages. This paper discusses how we overcame these disadvantages and the challenges we face in the future. Introduction "Open systems" has become one of the most overused computer buzz words, yet that concept is credited with reshaping the marketplace. This paper describes four open initiatives as interpreted at Mobil and presents a metric to quantify their impact on the development, maintenance, and application of the company's reservoir simulators. For the purposes of this paper, a reservoir simulator is simply a computer program whose heart is a computationally intensive numerical model. The program processes the physical description of the reservoir (e.g., the type of fluid, pressure, saturation, temperature, and geology). It also processes the proposed development strategy in the form of operating constraints. Using this information, it predicts the effectiveness of different production strategies and is used to optimize gas and oil recovery from petroleum reservoirs. During the last 2 decades, Mobil has developed four reservoir simulators. Fig. 1 shows that the number of lines of code in each program increased dramatically as more complex engineering features were incorporated. The first of these programs, WELCOS, was released more than 20 years ago. That black-oil simulator could model the behavior of only a single well and was used extensively for water- and gas-coning studies. Written in FORTRAN, it consisted of less than 50,000 statements. By 1975, Mobil had developed ALPURS. It was also a black-oil model, but ALPURS had the power to model all the wells in a field. ALPURS contained sophisticated well controls that enabled it to model complex production strategies. ALPURS also provided limited, black-and-white plotting and contouring capabilities. Because of its added engineering capabilities, ALPURS was six times the size of WELCOS, or about 300,000 lines. In the mid-1980's, Mobil developed a fullfield, compositional reservoir model, COSMOS. It was about one-third larger than ALPURS, with more than 400,000 statements. PEGASUS is a multipurpose, compositional, black-oil simulator capable of modeling a broad range of reservoirs with complex geology and fluid behavior, each with different production strategies. It integrates various modeling capabilities, such as a sophisticated well-management scheme for full-field studies and accurate predictions of horizontal-well performance. PEGASUS is used to study gas-condensate, volatile-oil, faulted, and fractured reservoirs. It also has gas-storage applications. It is 30 times the size of WELCOS and contains more than 1,500,000 statements. The interactive color graphics feature for interpretation of simulation results represents about 40% of the code.