N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....provide resource management for its applications: resource shortages had to be either managed by the user, or more resources had to be added. Oberon Juice: Juice [38] provides an execution environment for downloaded Oberon code (just as a JVM provides an execution environment for Java) Oberon [89] has many of Java s features, such as garbage collection, object orientation, strong type checking, and dynamic binding. Unlike Java, Oberon is a nonpreemptive, single threaded system. Its resource management policies are oriented towards a single user workstation with interactive and background ....

Wirth, N., and Gutknecht, J. Project Oberon. ACM Press, New York, NY, 1992.

....for each memory region in use, and is free to deallocate the region at will. Angel [39] Opal [14] and Mungi [32] are example single address space operating systems. 5. 2 Language Based Resource Accounting Systems such as Smalltalk [26] Pilot [40] Cedar [44] Lisp Machines [10] and Oberon [49] have taken advantage of language based mechanisms to provide OS like services. At least as early as the Burroughs B5000 [11] series computers, language based mechanisms were being used for security purposes. More recently, language based enforcement of security has been popularized by Java, ....

N. Wirth and J. Gutknecht. Project Oberon. ACM Press, 1992. 16

....language security, also derives from previous work in persistent object systems. Finally, this thesis depends on work done in bytecode rewriting and code to code transformation. 1.1. 1 Language Based Security Systems such as Smalltalk [40] Pilot [66] Cedar [76] Lisp Machines [11] and Oberon [82] have taken advantage of language based mechanisms to provide OS like services. At least as early as the Burroughs B5000 [13] series computers, language based mechanisms were being used for security purposes. At least as early as the University of California at Berkeley s Informer system [29] ....

N. Wirth and J. Gutknecht. Project Oberon. ACM Press, 1992.

....of the des gners of SPIN was to create an operat ng system that could be safely extended to meet the spec al zed requ rements of appl cat ons. As such, the use of Modula s safety features s rel ed upon only for extens ons w th n the kernel, and not for the system as a whole. The Oberon system[2][10] s an ent re system wr tten n the language of the same name. Its ma n emphas s was on extens b l ty of the system. Safety was guaranteed by the fact that everyth ng n the system was wr tten n Oberon, a strongly typed language. The Oberon system turned out to be surpr sngly portable and was ....

N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.

....1,192,800 64 Compiler 23,621 1,173,369 66,512,064 57 Table I. Benchmark Characteristics The other benchmarks are TreeAdd and Bisort from the Olden benchmark suite [Rogers et al. 1995] Jigsaw from the WPI benchmark suite [Finkel et al. 1992] and BTrees and Tex t s from the Oberon System 3 [Wirth and Gutknecht 1992; Gutknecht 1994; Gutknecht and Franz 1999] These benchmarks represent a variety of applications and programming styles but have in common that each of them allocates many megabytes of data, executes billions of instructions, and represents frequently used operations on dynamic data structures. ....

....were executed on a machine with 64 megabytes of physical memory, in contrast to many published results based on more uncommon hardware configurations. Hence, our performance data implicitly include the cost of garbage collection, which in our system is implemented as mark and sweep collector [Wirth and Gutknecht 1992]. Table II and Figure 3 present overall performance improvements due to datamember reordering, while Figure 4 shows how this performance improvement relates to the cost of profiling. In our system, the very first instance of a program to be executed in a user session is always created by a fast ....

Wirth, N. and Gutknecht, J. 1992. Project Oberon. Addison-Wesley.

....of them support strong security features. None of them, however, provides strong resource controls. Pilot [32] and Cedar [38] were two of the earliest language based systems. Their development at Xerox PARC predates a flurry of research in the 1990 s on such systems. These systems include Oberon [44] and Juice [20] which are based on the Oberon language; SPIN [6] which is based on Modula3; and Inferno [17] which is based on a language called Dis. Such systems can be viewed as single address space operating systems (see Opal [11] that use type safety for protection. VINO is a ....

N. Wirth and J. Gutknecht. Project Oberon. ACM Press, New York, NY, 1992.

....highlight the use of some features of PCCTS as they are used in an actual project. 1. Introduction The Oberon language was originally defined as part of a research project performed by Niklaus Wirth at the Institut fr Computersysteme, ETH Zentrum, Zurich, Switzerland from 1986 through 1989 [WG92]. The goal of the project was to design and implement a complete workstation class computer from scratch, including hardware, operating system, compiler, and software. The name Oberon refers to both the language and operating system developed as part of that project. The Oberon language was later ....

....Modula 2. Indeed, the first implementation of Oberon was compiled using a subset of Modula 2. At this time, no standards for the language have been formalized by any standardization committee such as ANSI or ISO. In absence of such a standard, the implementation published by Wirth and Gutknecht in [WG92] remains as the reference standard, although minor revisions have been made since the original publication. Some of the more notable additions to Oberon 2 compared to its ancestors include case sensitivity, type extension constructs and typeguards, and the reclassification of some reserved words ....

Niklaus Wirth, Jrg Gutknecht, Project Oberon, Addison-Wesley Publishing Company (ACM Press). Reading, Massachusetts, 1992.

....for optimal storage layout, but at present, the compiler cannot be continuously re optimized. The other benchmarks are TreeAdd and Bisort from the Olden benchmark suite [Rogers et al. 1995] Jigsaw from the WPI benchmark suite [Finkel et al. 1992] and BTrees and Tex t s from the Oberon System 3 [Wirth and Gutknecht 1992; Gutknecht 1994; Gutknecht and Franz 1999] These benchmarks represent a variety of applications and programming styles but have in common that each of them The Case for Dynamic Optimization 11 Benchmark Program Size Number of Al Number of Al Average Object (Lines of Code) located Objects ....

....were executed on a machine with 64 megabytes of physical memory, in contrast to many published results based on more uncommon hardware configurations. Hence, our performance data implicitly include the cost of garbage collection, which in our system is implemented as mark and sweep collector [Wirth and Gutknecht 1992]. The Oberon system has a document centric architecture and runs completely in a single address space, rather than one address space per application. Our first set of benchmarks (Table II and Figure 2) present an idealistic situation in which we compare a program with no data layout optimizations ....

Wirth, N. and Gutknecht, J. 1992. Project Oberon. Addison-Wesley.

....the problems of hardware variability that are one of the two main reasons for existing hardware software mismatches mentioned above. The overall structure of our dynamic code generation and optimization system is illustrated in Figure 1. The system, implemented on top of the Oberon System 3 [Wirth and Gutknecht 1992; Gutknecht 1994; Gutknecht and Franz 1999] for the Macintosh platform, is composed of five key constituents: a manager, a code generating loader, a profiler, an optimizer, and a replacer. This assembly of sub systems is in turn part of the Oberon System that provides many additional services, ....

....exits with a high probability. Long latency instructions include floating point and integer division, as well as load instructions that are likely to miss in the cache. 8. EMPIRICAL EVALUATION We have implemented the architecture described in Section 2 through Section 4 on top of Oberon System 3 [Wirth and Gutknecht 1992; Gutknecht 1994; Gutknecht and Franz 1999] and have integrated both dynamic object layout adaptation and dynamic trace scheduling into the framework for the PowerPC 604e [Motorola Inc. 1996] The PowerPC 604e is a superscalar out of order processor with one branch processing unit, one condition ....

[Article contains additional citation context not shown here]

Wirth, N. and Gutknecht, J. 1992. Project Oberon. Addison-Wesley.

.... of static single assignment form [Brandis 1995; Cytron et al. 1991] The other benchmarks are TreeAdd and Bisort from the Olden benchmark suite [Rogers et al. 1995] Jigsaw from the WPI benchmark suite [Finkel et al. 1992] and BTrees and Tex t s, a fundamental shared library of Oberon System 3 [Wirth and Gutknecht 1992; Gutknecht 1994; Gutknecht and Franz 1999] that is simultaneously accessed by virtually every program running as part of any Oberon session. ACM Transactions on Programming Languages and Systems, Vol. TBD, No. TBD, TBD TDB. Automated Data Member Layout of Heap Objects 11 Table I. Benchmark ....

....with 64 megabytes of physical memory, in contrast to many published results based on more uncommon hardware configurations. For the second set of benchmarks, our performance data also implicitly include the cost of garbage collection, which in our system is implemented as mark and sweep collector [Wirth and Gutknecht 1992]. The Oberon system has a document centric architecture and runs completely in a single address space, rather than one address space per application. Benchmarks (Table II and Figure 2) present the situation in which we directly compare the execution time of a program with no data layout ....

Wirth, N. and Gutknecht, J. 1992. Project Oberon. Addison-Wesley.

....process of linearization generally might not be achieved in a straight forward manner. Ferrante, 1985] describes an approach for linearizing parallel code, without the need of code replication. CDGs emerging from compilation of programs written in a structured programming language, such as Oberon [Wirth, Reiser, 1992], normally do not show the properties that make such an approach necessary. If, by code transformations carried out by previous optimization stages, control structures that meet these properties arise, it would be enough to solve the problem of linearization by means of code replication. For a ....

....since 0 is considered to denote a valid address. Negative memory addresses are designated invalid. Thus, exceptions for load instructions may only happen on referencing negative memory addresses or by violating segment boundaries. For programs executed under control of the Oberon operating system [Wirth, Gutknecht, 1992], only dereferencing of NIL pointers with a negative offset is unsafe. Exceptions can only occur for access operations to the type tag of a record bound pointer that might be NIL. All other pointerdereferences can be considered safe as long as pointers on stack are initialized to NIL. Other ....

[Article contains additional citation context not shown here]

Wirth, N., and Gutknecht, J. Project Oberon. Addison-Wesley, 1992.

....system allows the most efficient communication between processes, but isolation is the most difficult. Opal [13] as well as older work on language based operating systems [38, 43] has focused on the left side of the figure. The reemergence of language based extensible systems, such as SPIN [9, 32, 51] has focused attention back on the left side of the diagram. Such systems are single address space systems that use type safety instead of hardware memory mapping for protection. In this paper we discuss how resource management can be provided in language based systems (in particular, in Java) ....

....although a number of them support strong security features. None of them, however, provide strong resource controls. Pilot [38] and Cedar [43] were two of the earliest language based systems. Their development at Xerox PARC predates a flurry of research in the 1990 s on such systems. Oberon [51] has many of Java s features, such as garbage collection, object orientation, strong typechecking, and dynamic binding. Unlike Java, Oberon is a non preemptive, single threaded system. Background tasks like the garbage collector are implemented as calls to procedures, where interruption can only ....

N. Wirth and J. Gutknecht. Project Oberon. ACM Press, New York, NY, 1992. 14

....idioms. Using a similar technique, Ford and Lepreau [17] improved the performance of Mach RPC. Nevertheless, a significant overhead remains. 7 Related Work As a GUI oriented, high level language, MrEd shares much in common with Smalltalk [19] Pilot [27] Cedar [32] the Lisp Machine [7] Oberon [33], and JavaOS [31] All of these systems simplify the implementation of cooperating graphical programs through a high level language. Although most of these systems support multiple processes, only MrEd provides the kind of process controls that are necessary for implementing a SchemeEsq like ....

Wirth, N. and J. Gutknecht. Project Oberon. ACM Press, 1992.

....each module load, we need to call the procedure CleanCache( to ensure that each cached value is consistent with the memory locations referenced. DEFINITION HKernel; PROCEDURE CleanCache( END HKernel. Chapter 3 The File System The file system implementation is similar to the standard Oberon [15] file system. There are only two differences. First, the files stored in the RAM disk can be made persistent, i.e. moved to the ROM disk. These files cannot be deleted, nor can they be written. Second, the file system can access the host file system: reading files from and writing files to the ....

....FlashROM. Right after startup the HKernel calls the procedure FPGAInit that reads the bitstream file and copies it to the FPGA configuration memory. This takes only about 36 ms. Chapter 5 The Linker Loader The Linker Loader strategy adopted is the same as in the original Oberon operating system [15]. The modules needed are loaded and linked dynamically on the target system. The helicopter computer does not have any user interface devices like keyboard, display or mouse. Therefore all the development has to be done on a host cross platform. The host holds the development environment (a PC ....

[Article contains additional citation context not shown here]

N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.

....and openness. Extensible and dynamically changeable translators can be implemented by using inheritance and overloading. Dynamic loading facilities are helpful in saving resources and speeding up design and test phases. The current version bases on Oberon and the innovative Oberon System [18]. In the sequel, we start with a description of the meta language. Then some aspects of the implementation are discussed, followed by a more detailed outline of the extensibility. Afterwards a view on thinkable applications is given. 2. The meta language The definition of the meta language is a ....

....on Oberon was based on good experience with Pascal and Modula 2, but also on its impressive spirit of strengthening by generalisation. Further benefits are: Efficient and truly portable compilers for a wide range of hardware. Complete documentation (including source code) of the Oberon System [18]. Dynamic linking and loading facilities. A second far reaching design decision concerns the choice of the parsing method. There is much of work treating efficient algorithms. Nearly all of them are founded on the assumption that the language, resp. the grammar is completely known in advance. ....

Wirth, N., Gutknecht, J. Project Oberon. Addison-Wesley, Reading, 1992.

....Oberon program. 3 A Unified Framework Inspired by simulation programming in general and by the Simula language family [3] the very origin of object oriented programming) in particular, we have experimented with modelling self active objects on the Oberon language and environment [4] [5]. The result is a unified framework for concurrent, objectoriented programming. It can briefly be summarized in terms of four new con2 cepts on the level of individual objects that, together, constitute the core of our framework: a) Protected access, b) local activity control, c) guarded ....

N. Wirth, J. Gutknecht, Project Oberon, Addison-Wesley, 1992.

.... is an excellent example of an abstract data type, because its abstract presentation is simple and closed (complete set of operations, including delete, insert and read write access) while any efficient implementation is sophisticated and depends on rather complex auxiliary dynamic data structures [1]. However, a similar statement is not true for all object types that are used in an environment like Oberon. For example, the definition in the system base of any type that describes viewers (windows) on the screen must remain incomplete and open until the exact kind of contents and functionality ....

N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley 1992.

No context found.

N. Wirth and J. Gutknecht. Project Oberon. Addison-Wesley, 1992.

No context found.

N. Wirt and J. Gutknecht, "Project Oberon", AddisonWesley, 1992.

No context found.

N. Wirt and J. Gutknecht, "Project Oberon", Addison-Wesley, 1992.

No context found.

N. Wirt and J. Gutknecht: "Project Oberon", ACM Press, Addison-Wesley New York 1992.

No context found.

N. Wirth and J. Gutknecht. Project Oberon.ACM Press, New York, NY, 1992. 15

No context found.

N. Wirth and J. Gutknecht. Project Oberon. ACM Press, New York, NY, 1992. 15

No context found.

N. Wirth and J. Gutknecht. Project Oberon, ACM Press, 1992.

No context found.

Nicklaus Wirth and Jurg Gutknecht. Project Oberon. ACM Press, 1992. ISBN 0-201-544288.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC