linuxoid: переводы

→Global variables and constants (strings) are accessed via the SB register (static base). The value of this register is automatically adjusted by the CXP and RXP instruction as well as by interrupts and traps.

→It follows that local variables are addressed relative to the FP value with negative offsets. Parameters are addressed relative to FP with positive offsets, starting at 12 for external procedures called by a CXP instruction, and at 8 for local procedures, where the MOD register is not pushed onto the stack by the call instruction.

→The workspace is organized in the usual fashion as a stack of procedure activation records. Its top is denoted by the SP-Register. A second register, the so-called frame pointer FP is the anchor of the dynamic chain of activation records. A new element is added upon procedure call in two steps. The first step is performed after the loading of parameters by the call instruction (CXP for calls of external, BSR for calls of local procedures). The second step is performed by the ENTER instruction which is the first instruction of every procedure body. An activation record is removed, also in two steps, upon procedure completion by the instructions EXIT and RXP for external or RET for local procedures. The state of the workspace before and after these four steps is shown in Fig 8.3.

→5. Blocks for the permanently resident modules of the inner core, i.e. Kernel, FileDir, Files and Modules.

→4. Module descriptors (4000H - 7FFFH).

→3. Allocation tables for pages and disk sectors.

→2. The system stack (1000H - 17FFH) which is used by interrupt routines executed in supervisor mode, including the trap handler.

→1. The NIL-page (0...FFFH) which remains permanently unallocated. The purpose of this measure is to let references via a NIL-pointer invoke addressing traps.

→The area with address range 0...FFFFH contains

→Fig. 8.3. State of stack before and after procedure call and return

→Fig. 8.2. Storage layout for Ceres-3

→Fig. 8.1. Storage layout for Ceres-1 and Ceres-2

→If address mapping is unavailable, as in the case of Ceres-3 which lacks a memory management unit, the fixing of size limitations is unavoidable. The chosen layout for Ceres-3 is shown in Fig. 8.2; the stack is limited to 128K bytes.

→Furthermore, we note that both the stack and the heap space must be genuinely allocated, i.e. any address within the space must denote a physically present location. Hence, there is no point in making the virtual address space of their sum larger than the entire physical store. The size of the virtual block space then becomes the difference between virtual and physical address space. The resulting layout is shown in Fig. 8.1. The upper end of the address space is reserved for device registers.

→Unfortunately, the number of distinct spaces is larger than two. If it were two, no arbitrary size limitation would be necessary; merely the sum of their sizes would be inherently limited by the size of the store. In the case of three spaces, arbitrarily determined size limits are unavoidable. The presence of an address-mapping hardware alleviates the problem, however, because the virtual address space is so large that limits will hardly ever be reached.

→The storage layout of the Oberon System is determined by the structure of code and data typical in the use of modular, high-level programming languages, and in particular of the language Oberon. It suggests the subdivision of storage into three areas.

→A crucial property of the Oberon System is centralized resource management. Its advantage is that replication of management algorithms and a premature partitioning of resources are avoided. The disadvantage is that management algorithms are fixed once and forever and remain the same for all applications. The success of a centralized resource management therefore depends crucially on its flexibility and its efficient implementation. This Chapter presents the scheme and the algorithms governing main storage in the Oberon System.

→Although there exist numerous books explaining principles and structures of operating systems, there is a lack of descriptions of systems actually implemented and used. We wished not only to give advice on how a system might be built, but to demonstrate how one was built. Program listings therefore play a key role in this text, because they alone contain the ultimate explanations. The choice of a suitable formalism therefore assumed great importance, and we designed the language Oberon as not only an effective vehicle for implementation, but also as a publication medium for algorithms in the spirit in which Algol 60 had been created three decades ago. Because of its structure, the language Oberon is equally well suited to exhibit global, modular structures of programmed systems.

→This book presents the results of Project Oberon, namely an entire software environment for a modern workstation. The project was undertaken by the authors in the years 1986-89, and its primary goal was to design and implement an entire system from scratch, and to structure it in such a way that it can be described, explained, and understood as a whole. In order to become confronted with all aspects, problems, design decisions and details, the authors not only conceived but also programmed the entire system described in this book, and more.