« Disco: running commodity operating systems on scalable multiprocessors | Main | Memory Resource Management in VMware ESX Server »

Virtual memory, processes, and sharing in MULTICS

Daley, R. C. and Dennis, J. B. 1968. Virtual memory, processes, and sharing in MULTICS. Commun. ACM 11, 5 (May. 1968), 306-312.

Reviews due Tuesday 2/17.

Comments

1. Summary
The authors introduce several addressing mechanisms in MULTICS operating system. This includes formation of generalized address, process addressing registers, indirect addressing, descriptor segment and paging, and intersegment dynamic linking.
2. Problem
This paper aims to develop mechanisms for virtual memory addressing mechanisms that specifically target three objectives: 1) machine-independent virtual memory management, 2) procedure calls by symbolic name, and 3) sharing of procedures and data among different processes.
3. Contributions
In MULTICS, a process is natively associated with a contiguous virtual address space whose size is adjustable. Virtual memory is split into segment each containing a number of words. Segment can be either procedure instructions or data, the former being pure (non-modifiable).
The generalized address is virtual address we refer to today, which is composed of segment number and word number. Processor has several addressing registers to help implement addressing.
Internal instruction fetch retrieves segment number from procedure base register (PBR) and word number from PC to form generalized address, while external data gets base address from one base registers plus an index offset with external flag set.
Indirect addressing mode is supported when ‘its’ is set to retrieve a pair of words containing segment number and word number respectively.
Descriptor base register provides the base address of segment number, which in turn provides the base address of word number.
Paging mechanism is adopted to make physically noncontiguous address appear to be contiguous generalized address.
Intersegment linking and addressing requires 1) procedures are pure; 2) procedure is accessible by symbolic name and 3) segments within a procedure is invariant to recompilation of other segments.
Linking in a procedure is done by first search in the segment directory by symbolic name and then adding the generalized address into the linkage section whose base is stored in linkage pointer. Due to recompilation invariant, indirect addressing is used in linkage section to access another procedure. All symbolic word names are stored in the symbol table in a segment.
Transit control from one procedure to another requires replace linkage pointer, which is done by first transit control to link section which indirect addresses to the procedure wanted to be called. In this way, PBR stores the linkage pointer of the called procedure.
4. Evaluation
This paper does not provide evaluation results on the addressing mechanisms.
5. Confusion
I was wondering if the addressing mechanism is efficient and fast in practice. I see the effectiveness of this design, but suspect this complicated design would be time-consuming if put into implementation, especially on two things. First, before transition to generalized addressing, the procedure uses symbolic segment and word name to retrieve the information, which calls for an exhaustive search algorithm to find the data. Second, procedure call needs to replace the linkage section but this is done in a complicated way, by three-step jumping and control transfer, which may not be efficient in practice.

1. Summary
This paper explains some of the fundamental aspects of the MULTICS design. The concepts of process, address space and virtual memory are defined. The use of paging and segmentation is explained. The means by which users may share procedures and data is discussed. The use of a location-independent generalized addressing is discussed in great detail .

2. Problem
MULTICS was designed to serve multiple users with diverse needs operating from remote terminals with the following objectives:
1) Provide the user with a large machine-independent virtual memory so that the user does not have to bother about the storage mechanisms in the system and the system software is responsible for the management of the physical storage
2) To provide a facility of code-sharing by allowing the capability of one procedure calling another procedure using its name without bothering about its requirements of storage and its other details
3) To allow sharing of procedures and data among users subject to proper authorization. This can overcome overheads involved with transfer of information and holding multiple copies of the same procedure

3. Contributions
Association of a process with its own address space was one of the major contribution of the MULTICS system. Each process runs in its own address space independent of other address spaces.
The addressing mechanism uses a location-independent generalized address which consists of a segment number and a word number.
The ability of many users to share their procedure and data using proper authorization mechanism is very important as it allows users to write complex applications in a modular fashion.
The use of linking to allow inter-segment references along with the use of a generalized addressing mechanism is crucial to enable sharing amongst users mentioned above.

4. Evaluation
This paper simple presents some of the basic design concepts of the MULTICS system. No experiments are presented to evaluate its performance.

5. Confusions
I did not understand the directory structure of segments

Summary:

As the title explains, this paper talks about the concepts if virtual memory, what constitutes a process and how the addressing mechanism used in Multics was used to share procedures. This paper explains how processes in Multics are linked with an address space, the concept of a location independent generalised address and it's addressing modes as well as the linking process. In addition, the authors also explain how they use stacks and frames to handle procedure calls.

Problem:

The main problem that this paper addresses is that of sharing procedures. The designers of Multics attempted to isolate the calling procedure from the shared one, removing the requirement of the calling procedure needing to allocate memory for the called procedure.

Contributions:

This paper has a few contributions. The first of which is linking a process with its address space and the concept of virtual memory. Each process in Multics has access to a virtual address space built up of a number of segments, which can be accesses by a location independent generalised address.

The process of linking and allowing a process to make use of procedure segments might be a little convoluted in Multics but the concept of linking is still important and widely used today.

Another feature of Multics which is still relevant today is the directory structure with the hierarchical arrangement of directories with symbolic names that are independent of their associated segments.

The procedure call process looks to be almost unchanged from the mechanisms that are used today.

Evaluation:

This paper doesn't provide any evaluation of the effectiveness of Multics but this is understandable as the main objective of the paper is a description of the process, addressing and sharing implementation of Multics.

Confusion:

The inter-segment linking section isn't very clearly explained. I've understood the process of making a segment known to a process but got lost somewhere in the data structures that they use. Could you please go over this in class?

1. summary
In the paper "Virtual memory, processes, and sharing in MULTICS", various design concepts behind Virtual memory, paging and segmentation, dynamic linking and process in MULTICS Operating system was introduced.
2. Problem
The motivation behind the development of MULTICS is to develop a time sharing system satisfying diverse user requirements working on remote terminals. Prior to MULTICS, programmers have to address their procedures using physical address, which force them to know the physical memory limitations and requires them to plan ahead for swapping data between various memory levels. Inter procedure calls required the programmer to know he memory requirements of the called procedure and other subsequent procedures before hand. Multics aims to move this memory management into the system software.
3. Contributions
The key contribution is that, a layer of abstraction(generalized address) was introduced so that users can program using variable names and function names instead of physical locations.
1. Every process has a huge virtual memory. There is a one to one mapping of process and its address space. The address space is divided into segments i.e. procedure and data. Segments accessed by instruction fetch - procedure and all other are considered data segments.
2. Addressing is done using generalize address = Segment Number + word number. The translation of this generalized address to physical address is done using the descriptor segment.
3. Dynamic linking - When a segment is first accessed, its traps and find the corresponding file by doing a directory search, then it updates its linkage section. Future access to this segment need not under go the directory search again instead access the linkage section to find the segment.
4. Inter procedure calls are done by transferring the control over to that called procedure and updating the link pointer base register to point to the linkage section of the called procedure.
4. Evaluation
A lot of design concepts behind MULTICS was introduced, but this paper doesn't provide evaluation of their proposed design. I feel author was more concerned about flexibility rather than performance, because each access now has two memory translation.
5. Confusion
Linkage Mechanism is not completely clear. It would be great if you can explain them in class.

1.Summary
Daley and Dennis has described the basic design principles and concepts of processes, address space and virtual memory in MULTICS OS. The address space of a process with multiple segments, its directory structure and a generalized addressing mechanism is explained. Sharing of user procedures and data is enabled through inter segment linkage and the mechanism of translating symbolic references to generalized address is explained in detail.

2.Problem
The fundamental design decision was to support a time-shared system facilitating multiple users operating remotely at the same time. Authors try to address the problem of delayed buffering to various storage levels by providing an independent virtual memory for each user, with the authority of memory management of physical storage moved to system software. Program generality is addressed by making inter-procedure calls by only using symbolic names and not physical storage location. Also, protected sharing of procedures and data among multiple users is addressed through dynamic inter-segment linking.

3.Contributions
Although the concepts of address space, processes and virtual memory was already introduced during 1968, MULTICS has efficiently integrated all these concepts in a protected environment by using variable length segments for each process. A directory structure associating symbolic names to segments which is invariant across processes is introduced. A generalized addressing mechanism with the help of hardware registers is provided to fetch instructions and data in memory. Indirect addressing and dynamic inter-segment linkage mechanisms help users to access data across various procedure segments with right privileges. The important contribution is the concept of 'location independent’ data achieved through generalized addressing which helps for sharing procedures and data among users with just symbolic procedure names rather than actual physical location.

4.Evaluation
No evaluation methodology or any empirical data is provided to support their system performance and memory utilization. But, it would be interesting to see how MULTICS would perform with Unix like systems, with their dynamic linkage mechanism. Also, the extra overhead of adding instructions to support dynamic linkage between multiple procedures would be good to know.

5.Confusions
What is exactly a directory structure w.r.t to virtual address space segments? Indirecting addressing mechanism during 1968 makes sense, but why such a complex linkage mechanism for sharing procedures? I am trying to understand what benefits were they trying to achieve by making each procedure ‘pure' and do dynamic linkage by consuming extra memory for linkage segments?

Summary: This paper introduces the main design decisions in system MULTICS, the first OS designed for large number of users. It introduces techniques such as segments, generalized addresses, and dynamic linking.

Problem: To design a OS for multi-user and multi-tasks, so that each process (virtually) has its own memory space, also the sharing of data and instructions among processes should be enabled.

Contributions: The contribution is mainly on addressing.
1. Introduction of segment, which is a logically distinct units of information. Each segment is marked as either data or instructions, so that the sharing of data or instructions are treated separately. It can protect the instructions from modification.

2. Introduction of generalized addressing. It provides each process a independent very large addressing space, the mapping from generalized address to physical address are handled transparently by Multics. Generalized addressing makes each process independent to "avoiding the necessity of procedure overlays" and the "movement of data within the address space".

3. Dynamic linking. This idea allows the instruction sharing among processes without copying instructions. These instructions are marked as read-only and named by symbolic names.
The procedure is as follows: 1.searching the directory structures to find the segment. 2. creating a generalized address from the link data for subsequent references.

Evaluation: No quantitative evaluation is provided, since the whole paper is about introducing new concepts in system design.

Confusion: The paper itself is good. I wonder how Multics inspires the modern OS design (e.g. Unix).

1. Summary
The paper introduces the design of the Multics operating system. It covers the concepts of processes, address space, the virtual memory, the use of paging and segmentation and users share procedure and data.

2. Problem
The MULTICS is designed to support a large community of users with diverse interests. It should provide the user with a large machine-independent virtual memory to leave the physical storage management responsibility to the system. It should also permit a degree of programming generality and permit sharing of procedures and data among users according to proper authorization.

3. Contributions
(1) Associate every process with an address space. The address space is composed of many segments, which are logically distinct unit of information having attributes of length and access priviledged and may grow/shrink independently.
(2) Translate a generalized address (segment number + offset) to the physical memory address by having a two-step hardware table look-up procedure. Paging allows noncontiguous blocks of main memory to be referenced a a logically contiguous set of generalized address.
(3) Support dynamic linking using symbolic names for external segements, to allow share of procedure and data information among users.

4. Evaluation
The paper does not present any evaluation.

5. Confusion
FIG. 13 is not quite clear for me.

1. Summary

The paper discusses the design decisions in Multics which was one of the first time-sharing operating systems introduced. In particular, the mechanism by which "dynamic linking" is accomplished is explained in great detail.

2. Problem

The problem was to build a system to support a large number of concurrent users. As such, there were scalability issues with resources such as CPU and memory which needed to be handled.

3. Contributions

The Multics system primarily introduced 3 new ideas.

1. Segments

The virtual memory (address space) of a process is made up of segments which are a "logically distinct unit of information having attributes of length and access privilege". There are 2 different segment types: (1) data, and (2) procedure. In particular, both the process memory and files are treated as segments and segments are under a hierarchical directory structure. Thus, each process is allocated a large amount of virtual memory which aids in "avoiding the necessity of procedure overlays" and the "movement of data within the address space".

2. Generalized Addresses / Indirect Addressing

The generalized address is introduced as a location-independent means of identifying information. Hence this seems similar to virtual addresses in modern day systems. A generalized address consists of two parts (1) a segment number and (2) word number. A two-step hardware table look-up procedure is used to translate the generalized address to main memory address. An indirect addressing mode is also present which helps to implement dynamic linking.

3. Dynamic Linking

The sharing of procedures and data among user processes is key to avoiding the cluttering of memory with duplicate copies of routines and for programs to build on the work of others. To this end, Multics introduces the revolutionary dynamic linking idea. This allows processes to request for other segments be added to their address space and thus execute the procedures found in the other segment.

4. Evaluation

The paper provides no evaluation on the efficiency of the system (which leads me to believe the system was not very successful).

5. Confusion

I found the technical details of the linking mechanism hard to follow.

Summary
The MULTICS was one of the first few research works that developed a timesharing operating system so as to support several users at a time. In this paper, the authors elaborated on the idea of virtual memory, the structure of VM, segmentation, address translation, dynamic linking of ‘procedure’ (code) and data segments. The mechanism of virtualization has been explained in detail.

Problem
The paper identifies and aims at solving a variety of issues that are in general faced by any timesharing multiprocessor system. Three main goals listed in this papers are :-
1.To give the system responsibility for managing per process memory structure. An address space per process which gives every process the flexibility to manage its own memory resources.
2.To give a program the ability to make procedure calls only by using function/routine names. This may sound trivial in today’s workflow but was not so back in 1970s.
3.To permit sharing of procedures and data in core memory among users subject only to proper authorization.

Contribution
1.Virtual Memory and Segmentation – The paper describes in depth the structure of a virtual address space. The entire AS is depicted in segments. Every procedure thus maintains a segment descriptor table which maps the Segment # -> Physical address translation.
2.Procedure and Data segments are the two major segments in VM. The procedure segment is where the code resides and used for instruction fetch.
3.Generalized address – These are nothing but virtual addresses (segment # + word #). It allows access to a word without knowing its physical location in memory. The entire VM architecture in MULTICS is based on generating and referencing generalized addresses. The address translation however depends on whether it is an instruction or data fetch. Indirect addressing is also introduced in this paper.
4.Dynamic linking – The idea was to allow code sharing among different processes without creating duplicate copies. Also, procedures are read-only and are known by symbolic names. In the first reference, a segment is made ‘known’ to the procedure by a search through the directory structure. A generalized address is created from the link data for subsequent references. The paper describes the link data, linkage table creation in depth and also raises the concerns in this approach
5.Procedural calls – Subroutine calling from an existing procedure has been implemented using stacks. The addresses of these calls are stored in stack pointers. Argument pointers at procedure entry contains the list of arguments for called procedure.

Evaluation - The paper mentions the concept of Virtual memory and dynamic linking in good detail. No evaluation has been conducted for the purpose of this work.

Confusion – How does the linkage mechanism work in case where a procedure call is invoked from within an existing procedure? (P and Q procedure linkages)

Summary:
This paper talks about virtual memory in the MULTICS system as well as the idea of 'dynamically-linking' different segments together in a process.

Problems/Motivation:
The motivation given for the development of this virtual memory system is to increase the ease and generality of programming by providing processes with a large 'virtual' address space ( so that they need not deal with memory management tasks by using overlays. These tasks will be transparently handles by the system),and allowing easy sharing and addressing of procedures and data in different segments between different users ( and processes).

Contributions/Solution:
-The most important new ideas(for the time) presented in the paper were dynamic linking and a hierarchical file(/segment) system.
-Multics mainly used a segmentation based virtual memory solution ( the authors state that paging was used to allow large segments to have contiguous virtual addresses but discontiguous physical addresses)
-The important types of segments that are talked about are: stack, data, procedure, descriptor and linkage segment.
-The storage is organized into segments with logical names ( in a directory structure hierarchy - like a file system) and each process has a descriptor segment (with address and protection information - analogous to file descriptor table) for the segments which it accesses(which are brought into memory), so that the directory hierarchy need not be traversed to get to the segment on each access of the segment.
-The linkage section of an executing procedure ( pointed to by linkage pointer) contains the information needed to dynamically link to the actual location of any reference to data or procedure external to the current segment. This is needed separately since the procedures need to be location invariant and since the data in procedure segments cannot be modified ('pure procedure').
-When calling new procedures, new stack frames are pushed into the stack segment and the linkage pointer register is switched to point to the linkage section of the new procedure.

Evaluation:
The paper does not provide any empirical data regarding the success of their design in improving any objective metric of the 'programming generality' or 'ease of data/procedure sharing' as stated in their motivation. But the authors do give convincing reasons as to why this is the case.

Confusions:
The mapping from external segment references (to dynamically linked segments) to the actual generalized addresses of the external segment locations is handled in the linkage segment using the 'displacement'(/offset). Does this mean that programmers kept track of the order of the initial symbolic occurrences of these references and then ensured that further references to the same segment used the segment's position in the initial order?

1. Summary
The paper describes the design of the Multics operating system. It details the the notion of process and address space in Multics. It also describes how Multics handles virtual address translation and paging, and lets users share procedures and data.

2. Problem
To design a virtual memory subsystem of operating system and hardware to support sharing of data and code among users.

3. Contributions
Multics is one of the first operating systems to associate a process with a private address space with ability to map segments of data and code into this address space. Multics translates any word in this address space (or generalized address, a combination segment number and offset in segment) to the physical memory location by indexing into a table (named descriptor segment) for the executing process. Handling address translation for a newly scheduled process only involves changing the base register that points to the descriptor segment of the executing process to point to that of the new process. Multics supports dynamic linking (runtime) of procedures using symbolic names for external procedures, which are resolved the first time they are referenced using a trapping mechanism. Multics also supports making procedure calls, which are provided private storage by allocating a stack frame for each procedure in the call stack, a notion that is commonplace now.

4. Evaluation
The authors do not present any evaluation comparing alternative designs presumably because it would have been prohibitive to design and manufacture alternative designs. However, the author could have measured and presented the time taken to resolve generalized addresses, to resolve symbolic segment and address references, and to make a procedure call.

5. Confusion
Although the rationale for almost every design decision are presented in the paper, they are presented esoterically requiring multiple passes of text to understand them.

Summary:
This paper describes concepts of process, virtual memory and dynamic linking in MULTICS operating system. This paper describes in detail how generalized address is formed for instruction fetch and data access and translation of generalized address into physical address. Paper also describes implementation for secure sharing of data and procedures using dynamic linking of procedure.

Problem:
Multics was designed to effectively serve computing needs of large number of people. Operating system present at that time did not support dynamic linking of procedure and sharing was not effective because of lack of support from operating system. Multics also tries to add protection in multi-users systems by storing access rights in per process descriptor segment.

Contribution:
1. Major contribution is it changed the idea of computer from being a tool for scientists to a reliable and powerful resource for a large number of people.
2. Multics was first operating system which introduced hierarchical file system.
3. Per process address space was introduced which consists of large number of segments. Segments were further divided into pages which allowed noncontiguous blocks of memory to reference as logically contiguous set of address.
4. Introduced dynamic linking and calling function by name instead of knowing before hand machine address of function at which it is loaded.
5. Generalized address was used in Multics which made context switching between processes faster. Just descriptor base register along with other registers need to be changed during context switch.
6. Inter segment linking allowed for the ability to share procedure and data information and the power to construct complex procedures by building on previous work.
7. Multics was first operating system which was written in high level language.

Evaluation:
Paper doesn't describe about performance evaluation. Stats for increase in overhead for address translation and increase in performance because of sharing of data would have helped.

Confusion:
How do implementation of today's shared libraries differ from Multics?

Summary:

This paper describes the concept of virtual memory, address space and virtual memory in MULTICS. The paper describes in detail the addressing mechanism and the intersegment linking followed in MULTICS. Also, the mechanism of how procedures are shared between processes is explained.

Problem:

The main objective was to provide a large enough virtual memory and make the system software take care of storage instead of the user programs. This paper talks about the idea of a procedure being called from another procedure using only its name without the need for any other information like the memory requirements. Also, the authors tried to address the problem of sharing the procedures and data with users who had proper authorization.

Contributions:

In this paper, the idea of using a separate address space for each process implicitly induces the notion of memory abstraction. Organizing the address space using segments and words makes addressing location independent with the use of base registers to store the starting address. A directory structure provides each segment with at least one symbolic name which is global to all processes. MULTICS supports indirect addressing by using of the addressing mode field in the instruction format. The mapping of a generalized address to an address in main memory is done using a descriptor segment. The descriptor segment also contains protection information of the segment for a particular process. By the use of paging, large segments can be split into non-contiguous blocks in main memory. The linkage section contains references to external segments and provides generalized reference for a segment once a symbolic reference is made.

Evaluation:

The paper does not provide any evaluation of the MULTICS system. The paper concentrated only in the describing the underlying concepts of virtual memory, address space, paging and segmentation.

Confused about:

I could understand the use of the directory structure. How is this structure internally represented and how are changes made to it? I could not understand the linking section.

Summary:

This paper introduces the concepts of processes, address spaces, virtual memory, paging and segmentation in the MULTICS operating system. It demonstrates the procedure of the formation of location-independent generalized addresses and how they are effectively used. It also discusses how to dynamically transform symbolic references to virtual machine addresses.

Problem/Goals:

This paper tries to achieve three objectives:

1. Making the user programs independent from the various details of various storage devices by providing the user with machine-independent virtual memory.

2. Allowing procedures to call other procedures using a symbolic name instead of the address of the other procedure. This is achieved by dynamic linking of names to virtual addresses.

3. Sharing of procedures and data among users.

Contributions:

1. Segments as logically distinct units of information for the process, such as code, data, etc. Provides users with a large virtual memory made up of these segments.

2. The virtual memory is implemented through the concept of location-independent generalized addresses. The paper shows how to form the generalized addresses. To access the address specified by a generalized address it needs to be translated to a machine-dependent address by the system.

3. Concept of paging in order to simplify storage allocation problems in main memory. It allows non-contiguous blocks of main memory to be referenced as logically contiguous set of generalized addresses through transparent translation provided by the system.

4. A method of dynamically linking symbolic names to references of segments through the use of indirect addressing.

Evaluation:

The paper only describes the design but presents no evaluation. A simple comparison with a system that doesn't use virtual memory would have been interesting.

Confusions:

After presenting the directory structure in Fig. 1 , it mentions that we can dispense with files and no distinction need to be drawn between files and segments. What is the meaning of files here? Because we still need files for persistent storage.

1. summary
This paper introduces MULTICS, a time-sharing operating system designed for large, diverse user groups. The desired features and corresponding design decisions are explained in this paper, including “process” and “address space” concepts, the addressing mechanism and dynamic linking.

2. Problem
Before MULTICS there were no existing operating system capable of providing users with a large machine-independent virtual memory. Procedures are in lack of generality and it is impossible to call a different procedure without knowledge of its storage and procedure call hierarchy.

3. Contributions
This paper presented some novel ideas of about process and address space, addressing and dynamic linking in MULTICS.


  • It separates data segment and procedure segment in memory, and has different rules for either type of segments.

  • Novel addressing concepts are discussed in this paper, including generalized address, address formation, indirect addressing, descriptor segment and paging.

  • The paper talked about dynamic linking in MULTICS that would allow data object sharing and process interactions.

4. Evaluation
No evaluation experiment is described in this paper.

5. Confusion


  • I have a lot of confusions about the addressing part. How the different concepts work and how they work together?

  • Can we talk about the difference between MULTICS and modern OS that we’re using? There seem to be a lot of similarities and I wonder if the modern system design ideas came from MULTICS.


Summary: This paper introduces the design of Multics's memory subsystem. In Multics, each process have a separate address space. Processes can share memory or making procedure calls using dynamic linking.

Problem:
1. If every process uses physical memory address, it is very hard for each process to manage memory because all the addresses are system-dependent. Moreover, physical memory is usually limited, which again adds the complexities for processes to manage memory spaces.

2. Sharing procedures among processes is desirable. For example, one process may provide a routine that is useful to many other processes. Providing such sharing is challenging. For example, the caller does not know the address of the routine; the routine may not have access to caller's address space.

3. Sharing data among processes is also desirable. Memory is expensive; if multiple processes can share some data instead of making each a private copy, memory spaces can be saved.

Contribution:
1. Making each process a big enough address space, aka virtual memory. The address space of a process consists of an ordered set of segments. Every virtual address is composed of a segment number and a word number. Each process can have up to 2^14 segments, with each segment holding as many as 2^18 36-bit words. With such big address space, programs can manage their memory much more easily.

2. Structured segments. Segments in Multics is like files in a file system: they form a tree structure called directory. Each segment has one or more symbolic names associated with it. One process can refer to a segment in another process by calling its segment name.

3. Dynamic linking happens when a process tries to make a procedure call to another process. The OS will insert the segment containing the procedure into the address space of the caller. Since the segment is then mapped into the caller, it can access caller's memory.

Evaluation: The authors did not explicitly evaluate their work.

Confusions: Details about how linking works.

1. Summary
In this paper the authors describe MULTICS, an operating system designed to provide many users with machine independent virtual memory and the ability to share procedures and data, protected by permissions.
2. Problem
The designers of MULTICS wanted to introduce a new level of programming generality to the system, wherein a procedure could be called knowing only its name and nothing about its requirements or what other procedures it might need to call. Additionally, they wanted to design the system in such a way that procedures could be "dynamically linked" and shared between multiple executables.
3. Contributions
MULTICS was designed with a large virtual address space, and a hierarchical filesystem with names that pointed to segments inside the address space. The filesystem pointers had the same meaning in the address space of all processes on the machine. Generalized addresses consisting of a segment number with a word number were used to provide access to variables without knowing their locations in physical memory. Access to the physical memory locations specified by these generalized addresses was accomplished using a descriptor segment, a table used by the processor to perform lookups for the process in execution.

Additionally, the paper introduces the concept of dynamic linkage of procedures between programs. Segments external to the current process are referenced by name and the filesystem is searched to locate them. After they have been located they are inserted into the link data for a process for faster access. When transferring control between procedures, the concept of dynamic linking requires that the linkage pointer for each given segment be loaded at procedure entry time.
4. Evaluation
MULTICS is discussed in design only in this paper rather than practical evaluation.
5. Confusion
The address formation seems quite similar to the methods we use today, but handling linkage when switching procedures is confusing to me after my first read through.

Summary:
This paper covers the basic design concepts of MULTICS like processes, address space, and virtual address conversions. Since this is a design paper no evaluation is done.

Problem:
To design a system operating principally from remote terminal with following properties:
-Large machine-independent virtual memory availability: OS should manage physical storage.
-Programming generality: ability of one procedure to call another just by name
-Authorization: permit sharing of procedures and data among users subject by authorization

Solution:
-Process and Address Space:
Multics paper proposes a model similar to multi-page model. Here each process has its own address space, independent of other processes. Entire memory is divided into a number of segments, that are identified by a generalized address. It is comprised of segment number and word number; and is location-independent way of information retrieval. The paper further describes the role of processor registers in making the address formations. These formation are used for instruction fetch or data access. External flag in the instruction format is useful in indication of the usefulness of segment tag for address formation. Mode flag is used to identify Indirect addressing.
-Inter-segment linking and addressing:
Possible only for pure segments that does not allow any word modification. A symbolic segment reference name used for accessing shared segments. No segment number is used for it since its process dependent.

Evaluation:
No evaluation of design ideas done in paper.

Learning/Confusions:
-I am slightly confused about the way address formation for instruction fetch and data access is done.

1. Summary
The paper describes the working of MULTICS which was one of the initial attempts to virtualize memory and provide a large virtual address space, virtual addressing and multiprogramming. In addition to these, the idea of inter-procedure call by referring to a path name as opposed to a physical memory location has been implemented which again abstracts memory to the user.

2. Problem
a) Earlier to MULTICS, users had to address their procedures in actual physical memory which constrains them to plan beforehand for the swapping of data between different storage levels in the system.
b) And since everything was mapped in physical memory, inter-procedural calls were made to an actual physical memory location using an address and not using a function name as we do now.
c) This would also mean that using physical memory calls are not subject to any authorisation and any procedure can access any data in memory.
These three are the main motivations to design the MULTICS operating system.

3. Contributions
a) Each process has its own associated address space that is broken into code and data segments. The segments are further indexed as pages and are placed non-contiguous in memory.
b) Since the addresses are virtual, they are accessed using an indirect address translation mechanism where the segment number of an address specifies the which segments and the word number is the offset. In addition to this, inter-procedural jumps are made using link pointers and other registers pairs and by turning on the external flag in the instruction.
c) Data memory accesses are similar in the sense that they refer to a descriptor table using the descriptor base register and segment number and are offset from the address that is specified in the descriptor table.
d) Procedure calls access a linkage table using the link pointer and segment number and are offset from that address specified in the link data. This is the linkage section and it different for every procedure although they may point to the same segment in main memory.
e) In case of calling other procedures, a similar indirect address translation mechanism is used for the stack pointer and argument pointer which hold the return address value and the arguments that are passed on to the calling function.

Ideally, all the main memory accesses are abstracted from the user and the user can access his data/functions in memory using variables and procedure name paths.

4. Evaluation
There is no evaluation presented by the authors. A basic benchmarking of the time taken to convert virtual address to physical addresses using the indirect addressing mechanism could have been provided since that is the major change compared to earlier systems.

5. Confusions
What mode does the linkage table data have? It is mentioned 'ft' in one place and 'its' in another place. Ideally it should be ft, I am assuming.

Summary:

The paper describes the design of MULTICS operating system especially in regards to the virtualization of memory. Virtualization is achieved through a huge virtual address space per process which in turn refers to physical segments on the main memory. They also provide sharing of procedures and data through the process of linking appropriate data segments.

Problems:

The paper tries to solve a number of problems. One is the removal of memory management responsibilities from the user by providing a large enough virtual memory manage by the OS. Secondly, sharing of data and procedure in a protected manner thereby reducing the memory usage.

Contributions:

MULTICS operating system virtualizes the memory used by a process using certain data structures like base registers, segment descriptor table and the like. They divide the entire available physical memory into segments which are then assigned to the processes. Each segment is uniquely identifiable using a symbolic name which helps easy sharing of segments even without know the segment addresses. Also, to avoid lookup and traversal to find out the address of a segment, given its name, a segment descriptor table is maintained per process which gets populated after the first reference and indexed by a segment number.

The use of base registers to argument pointer, stack pointer, linkage pointer gives flexibility to memory allocation for a process i.e., one does not need to have contiguous space for it. To allow sharing of procedure through virtual addressing, linkage of data segment referenced by procedure is done through a linkage section. A stack is used to stored the return address from a procedure call and also the arguments for a procedure call though there are other alternatives provided for the same.

Evaluation:

The paper provides solutions to all of the problems that one would face virtualizing memory. Though there are certain places where it seems like they have overcomplicated things like why to have segments and then paging concept within the segments.

Confusions:

The linkage mechanism for procedure entry is not clear enough to me. When calling procedure Q from another procedure P, my understanding is they just update the link pointer register to point to the link section of procedure Q. What role does an entry point of Q play apart from providing the linkage section address? I think the Fig 13 has got me confused.

Summary
The paper mainly outlines the concepts of processes, their address space and various addressing and interlinking techniques involved in the MULTICS. It gives the details as to how the procedures and data can be shared among the processes and also describes the mechanism by which symbolic procedure names are translated into virtual memory addresses.
Problem
The main objectives of developing MULTICS are
To allow large number of users to operate simultaneously from remote terminals; to provide the user with a large machine independent memory and move the responsibility of physical storage management to system software; enable procedures to call other procedures without prior knowledge of its requirements of storage etc.; to permit sharing of procedures and data among user process subject to authorization.
Contribution
A major contribution would be the concept of virtual address space made of segments for each process. The directory structure associates symbolic name for each segment that is invariant over all the process in existence. Each word in the processes address space can be identified by a generalized address consisting of segment number and word number. The concept of indirect addressing and how it can be used to interlink procedures is explained in detail. The mechanism of resolving a symbolic segment name by a procedure in execution by maintaining link data of all the external references in linkage section allows faster data access after the initial trap.
Evaluation
The paper provides no evaluation. They could have discussed the performance improvement(?) obtained by maintaining the link data structure.
Confusion
The last section of linking various procedure segments is not quite clear.

1. Summary
The paper presents an operating system named MULTICS. It describes some interesting mechanisms the OS implements to processes to call procedures located outside of the current process by using indirect addressing and naming. The authors go into the details of how this system is designed and implemented including the specialized hardware it runs on.

2. Problem
The main problem the paper covers is the difficulty programmers face when designing programs that have overlapping, common functionalities. Previous operating systems had no mechanisms to support programs calling common procedures. Without this functionality, procedures must be rewritten in each process’s address space, adding the complexity of being at least partially aware of how the procedure operates to accommodate its storage usage or any other procedures it may call. In addition the authors aim to solve problems that arise in small address spaces where users must manage memory themselves.

3. Contributions
The authors provide a system in which procedures may be called simply by name, and without knowing how the procedure uses storage or what other procedures it may call. By leveraging some indirect addressing features of specialized hardware, the authors describe a system by which procedure names can be translated to a generalized address that references a specific word in a specific segment instead of a physical memory address. These levels of indirection allow users to call external procedures from within a process. In order for these external calls to function, MULTICS uses a stack pointer. When calling a procedure, state is saved onto the stack, new space is allocated for the called procedure, and when the call is complete state is restored by popping the stack.

4. Evaluation
The authors suggest what sort of benefits this system allows, specifically in the design of programs and procedures. There is no evaluation other than that a system like this is possible.

5. Confusion
The authors seem to have completely redone a lot of basic things like processor architecture, writing their own assembly language, maybe compilers, basic programming constructs like function calls etc. Presumably there was some inertia from already well known processor architectures, or operating systems. What allows a revamp like this to overcome that sort of inertia where other operating system ideas might not?

1. Summary
In the paper "Virtual memory, processes, and sharing in MULTICS", the authors propose Multics, an operating system which structures its programs in terms of segments, which could be read/write/execute protected. They also explain the mechanism of dynamic linking on procedure calls and data-sharing across segments with access control on a per-segment granularity.

2. Problem
The authors aim to build a time sharing system that is capable of catering to the diverse requirements of multiple users working on remote terminals. They also want to ensure that memory management is handled by the system software and the programmer no longer has to consider the physical storage limitations while writing programs or know the storage requirements of the callee procedure and the subsequent procedures which will be called by it.

3. Contributions
Segmentation:
- One-to-one mapping between process and address space. Each segment has length and access privilege attributes, and can grow/shrink dynamically.
- There is no separate file system; instead, each segment is named and accessed through a directory hierarchy, and memory accesses happen directly to these segments.

Addressing:
- Addressing is done using a generalized address(similar to virtual address in today's OS): (segment number + word number)
- Segment number is used as an index into the descriptor segment (table of segment attributes, including physical location, access privileges, length) which maps generalized address to hardware addresses. This is similar to a page table containing mappings between virtual and physical addresses.

Dynamic Linking:
- On the first reference to a segment, the trap handler finds the file of the external segment and links the two segments by updating the link data in the linkage table. Future references use that indirect address to go straight to the external segment.
- A linkage pointer points to the linkage table of the currently executing segment.

Procedure calls:
- The generalized address of the link table for a segment is located in the link pointer base register. Thus the link pointer must be updated whenever a new segment is executed via procedure call.
- Each process has a stack segment that is used to store stack frames of procedures. Only constants arguments are passed via procedure segment while pointers and variable arguments are passed via the stack segment.

4. Evaluation
The authors do not provide any evaluation results of using segment based virtual memory approach. They could have discussed the overhead of doing two memory references for address translation.

5. Confusions
Keeping a procedure segment self contained is not clear to me (Fig 12).

Summary:
The paper talks about various design concepts of the MULTICS operating system such as virtual memory, paging and segmentation, processes, linking and addressing mechanism for sharing of information/procedures/data.

Problem:
MULTICS aims at building a time sharing system with diverse user requirements, providing users with large machine-independent virtual memory, sharing and reusing procedures without bothering about its storage requiremnts but still maintaining authorization control.

Contributions:
1. Large address space per process and virtual memory management in a machine independent way.
2. Hierarchical arrangement of directories with symbolic links.
3. Generalized address allows access to a word without knowing its location in physical memory and easier reallocation of processor by changing DBR.
4. Location independent addresses and inter-segment linking allow sharing of procedure and data information and build complex procedures on the top.

Evaluation:
A lot of design concepts have been introduced but no evaluations have been provided to back them up.

Confusions:
The authors claim that no separate distinction is required between files and segments in the directory structure. How?
I could not fully understand the linkage mechanism and procedure calls/return.

Summary
This paper discusses the basic concept of process, address space and virtual memory as defined by MULTICS. It also talks about paging, segmentation, generation of addresses, inter-segment linking and addressing mechanism for users to share access to procedures and data.

Problem
Designers of MULTICS wanted to provide a system which could cater to a large number of users with diverse requirements and operating from remote locations. By providing a large machine independent virtual memory, programmers need not get involved in memory management tasks like preplanning of data transfer between various storage levels. User program development became more convenient as they became independent of the storage devices in the system and also allowing procedures to call other procedures by just their symbolic names.

Contribution
MULTICS provided each process with their own individual address space (virtual memory in terms of segments) and generalized addresses which were location independent forms of identifying data. These generalized addresses consisted of a segment number and word number which are formed using the data stored in the base registers and index registers. MULTICS implemented an entire form of inter segment linkage for data references and making segments known to different processes when referenced by their symbolic path names. MULTICS also fulfills all the needed features for implementing subroutine calling by reserving a frame of private storage in the stack segment associated with each process.

Evaluation
In this paper MULTICS has not been compared to any other OS hence no performance statistics are available.

Confusion
Did not completely understand why the symbolic name | [x] was put in procedure segment because the procedure segment needs to be "self contained" (Fig 12).

Summary:
This paper discusses the various design concepts of MULTICS operating system. Specifically, the paper discusses in great detail, the concepts of process and address space, addressing and hardware support in the form of various registers to implement generalized addressing and indirect addressing. The paper also discusses the concepts of inter-segment linking and the mechanisms available in MULTICS to convert symbolic references into virtual machine addresses.

Problem:
This paper tries to tackle the problem of designing a time sharing system, which would effectively cater to the computing needs of a collection of diverse users operating from remote terminals. The main objectives driving the design of the system are those of providing a machine- independent virtual memory, providing means for generic programming and allowing users to share procedures and data securely.

Contributions:
One of the main contributions of this paper is the association of a private address space, composed of segments per process. Just like everything in UNIX is a file, everything in MULTICS is a segment. In retrospect, it is easy to see that file as an abstraction in UNIX was motivated by MULTICS design.The authors argued that this organization of virtual memory was employed to avoid naming conflicts due to movement of data within address spaces and also to facilitate effective sharing of information between processes. MULTICS also introduced the concept of generalized address and decoupled the concept of (generalized) address from its location in storage hierarchy. Another contribution of MULTICS is dynamic linking, which allowed a process to resolve external segment references at runtime by requesting other segments to be added to its address space. This was achieved by “making a segment known” at run time and adding a separate linkage segment to the process.

Evaluation:
This paper does not provide any evaluation of its design ideas.

Confusions:
The way procedure call and return works in MULTICS is still not very clear to me

1. Summary
This paper describes some of the ideas used in the MULTICS system like virtual memory, addressing, sharing and processes.

2. Problem
MULTICS was developed to serve diverse computing needs of the users. To this end, the problem faced by the designers was to provide a large virtual memory to the users while allowing easy sharing of the memory and not having the users to do anything special in terms of writing the programs.

3. Contributions
The paper describes some of the key mechanisms developed for the MULTICS system. The authors begin with the concepts of a process in MULTICS and the address space. They divide the virtual memory into contiguous segments where each segment can contain a procedure or data. Each segment has a symbolic name and the names have a directory structure thus leaving no difference between segments and files. MULTICS uses indirect addressing using a descriptor segment. Sharing in MULTICS is achieved by linking segments. The proposed method is that the procedure first refers to the segment by its symbolic name and then the link is established to the segment adding it to the currently running process' address space. This also follows an indirect pattern via the linkage section. For procedure calls, passing arguments and returning back a similar segment linking mechanism is used.

4. Evaluation
This paper presents no evaluation of the proposed techniques.

5. Confusion
The working and use of linkage section seems confusing. Why is it needed apart from the descriptor segment.

Summary :
The paper discusses about how virtual memory, address translation mechanisms and dynamic linking are implemented in the MULTICS operating system.

Problem :
The problem in question is to develop a segment based virtual memory system that allows access of instructions and data to be physical memory location independent. In addition, it also deals with mechanisms to allow sharing of memory between processes based on access permissions.

Contributions :

1. The processes are mapped to address space that is basically segmented. Separation of data and instruction segments wherein instruction segments cannot be modified and data segments can be write protected.
2. Generates generalized addresses using the segment number and an offset(word number).
3. The address generation for instruction fetches uses the procedure base register and the program counter. For data accesses, the base pair registers and the address in the instruction are combined to form the final generalized address. Supports both internal and external segment data accesses.
4. Usage of descriptor segment table to locate the segment by a generalized address and contains information about the access permissions for that segment by the process.
5. Intersegment linking is made possible by being able to refer to a segment name only by its reference name. A linkage section contains the actual address which is populated on the first access on a trap. Every subsequent access to that segment by the process would then be linked.
6. Each segment maintains a symbol table to map symbolic word names to word numbers for access within the segment.
7. Procedure calls are implemented by creating stack frames and restoring on return. Intersegment procedure calls are also supported.

Evaluation:
The paper only discusses about the design of the system and does not deal with any sort of evaluation.

Confusion:
The linking of intersegment procedure calls to the linkage section of the called procedure is not clear.

1. summary
In this paper several high level concepts essential to the MULTICS operating system are detailed - particularly the concepts of processes, virtual memory, and segmentation. The bulk of the paper explores the concept of symbolic references to shared data and functions, and how these can be implemented.

2. Problem
No explicit problems are mentioned in this paper. However, the design goals of MULTICS suggest there were several fundamental, lacking issues with operating systems at the time.
The first is the issue of small or nonexistent virtual address spaces. In these systems, uses are forced to manage physical memory themselves, or use overlay techniques. The second is the issue of programming generality and sharing. At the time, it was difficult to reference shared “library” procedures in a simple manner.

3. Contributions
The contributions of virtual memory and segmentation are notable. The concept of easily transferrable generalized addresses is still in use today. At the time, a contiguous, process-independent 32-bit address space greatly simplified user-level programming efforts. However, I felt that the use of symbolic references (along with the necessary details for transferring into easily accessible virtual addresses) was particularly novel. This was accomplished through a number of concepts. the descriptor segment is a process-specific array that allows for quick indexing (along with protection) into memory segments. When a process first references a segment by symbolic name, the segment is made “known” to the process by searching the system directory, and inserting a reference into the descriptor segment. Because a segment can be accessed more quickly on subsequent references by creating a generalized address, a linkage section for the procedure (which is private per process) is maintained. Accessing such a remote procedure relies on the indirect addressing mode. This linkage section also allows for procedures to be recompiled with little effect on other code-bases. In execution, the only difference is the updating of a few pointers.
Finally, a major contribution is that of the stack frame when transferring from procedures. This recursive framework allows for each procedure to remain self-contained.

4. Evaluation
No performance evaluation is provided by the authors. I would have enjoyed seeing performance statistics when compared to statically linking procedures. This static linking would obviously be faster, but could not provide the flexibility of the MULTICS system.

5. Confusion
The entire last section of the paper (regarding the problem introduced by dynamically linking procedures) is difficult to understand. Why do we reference the linkage section for Q?

Summary:
The paper describes design principles of the MULTICS system which helped in achieving sharing and protection. The authors explain concepts of process, address space and virtual memory and how each of these are used to achieve the design goal. The paper also describes formation of the generalized address for instruction and data access, hardware requirements for MULTICS, and how symbolic names can be used to access procedures transparently.

Problem:
The basic problem addressed in the paper is of making the limited main memory accessible to a large number of users transparently and thus share data among applications. Sharing was difficult to achieve as systems were not inherently designed to share code or data. Another key concept is providing protection in a multi-user environment by using access control lists.

Contributions:
Sharing and Protection: Sharing was achieved using segments. The virtual memory was divided into segments and it could be mapped into the address space of processes. The concepts of files and segments were integrated into one where files are mapped to the address space when requested by the process. For protection, the hardware would check for access rights on each reference. Protection bits were used to achieve this.
Kernel: In MULTICS, the kernel is shared and mapped into the address space of running processes. It had procedures defined for segment and page fault handling.
Paging and other contributions: Paging was used to divide segments into equal sized chunks for efficient memory management as segments could vary in size. Demand paging concept was used to load only parts of segment into memory. Also, calling procedures using symbolic names was possible since user programs could now specify the name and the system software would transfer control to the desired location using dynamic linking.

Evaluation:
Unfortunately, the paper does not discuss the effectiveness of the mechanism or even the performance issues or overhead related to implementing segmentation and paging with the hardware.

Confusion:
How is internal fragmentation handled in segments ?
What are the concepts which are inspired from MULTICS in modern operating systems ?

1. Summary
The current paper discusses the mechanisms of virtual memory addressing and sharing of procedures and data in MULTICS operating system. It specifically focuses on dynamic linking of shared procedures in a multi program system.

2. Problem
The paper addresses three primary problems. One, to eliminate the need for procedure overlays, buffering and copying in virtual memory size management. Two, to enable sharing of procedures to eliminate redundancy and need for supervisor controlled accesses. Three, to reduce the burden on a programmer in managing a procedure call routines.

3. Contributions
The paper discusses several techniques that address these problems. The private virtual address space of a process is divided into segments. Each segment has a segment descriptor that manages length of segment and access rights. The segment descriptor table holds these descriptors and is private to each process. Generalized addressing scheme provides a location independent way of mapping a virtual address to a segment address. Paging is internally implemented for better memory efficiency. This whole procedure eliminates the need for overlays, buffering and provides a way to enforce memory protection.
Each segment is associated with a symbolic name and the mapping is arranged as a directory structure. Procedures are pure, location independent and are called by a symbolic name. On a procedure call, the procedure segment is added to the descriptor segment of the process. The link data of a procedure (the external references of the procedure), called the linkage section, is copied and made known to a process when accessed. Each process maintains a linkage pointer in a register, which is used for indirect access of the linkage section. This technique enables processes to share procedures without prior storage concerns.

4. Evaluation
This is primarily a design paper. So, no evaluation is provided.

5. Confusion
Its not very clear about what happens when a procedure calls another procedure. Is the link base register saved and restored? Or is the new linkage pointer indirectly accessed through the current register?

Summary:
The paper provides an overview of the concept of processes, virtual memory that was realized in the MULTICS OS. The early implementation of paging mechanism is described in detail and the method used to enable sharing of data and procedure is defined.

Problem:
The authors were trying to provide the users with a large address space, programming generality and procedure and data sharing so that the tasks of data movement between storage levels, procedure calls and sharing were handled or enabled by the OS. Another key problem that the authors try to solve is providing users the ability to use existing procedures to build their systems/work over. This is a part of the procedure sharing problem. The paper also addresses the problem of linking for the case where a procedure further calls another procedure.

Contributions:
The primary contribution of the paper includes the concept of per process address space controlled by the supervisor. The address space was realized using segments of finite sizes and this idea seems to have been the driving factor behind today's implementation of memory management using page tables. The categorization of segments into procedure and data, with protection features provided the basic protection features. Another interesting feature is the treatment of files like segments, which made it easier for processes to access files. The method of address formation seems to have been the influence behind today's VPN-PFN translation, which use page directories and page tables. The DBR and descriptor segments look like the MULTICS counterparts of PTBR and PT. The mechanism to establish the entries in the linkage section of the process seems to have a large overhead, due to directory traversal using symbolic name, considering the case where the procedure referenced may not be referenced many times. The paper also discusses the use of stack pointer for referencing private data of procedures, which is seen in all modern systems.

Evaluation:
The paper reports no evaluation of the system. Some of the interesting evaluations that would have shown the effectiveness of the approach are – overheads of indirect addressing using the linkage mechanism and overhead of context switch, now that the descriptor segment has to be switched too.

Confusions:
The paper states that pattern of descriptor segment assignment is different for each process. I don't understand the intuition behind this statement. Also, use of linkage sections for nested procedure calls is not completely clear to me.

1. Summary
This paper introduces the basic concept of process, address space and virtual memory in the design of the MULTICS OS. It focuses on the details of addressing mechanism and the implementation of “dynamic linking” built on the mechanism.

2. Problems
The motivation is to design a system that could effectively serve a large number of users with diverse interests and such users are principally from remote terminals. The problems include how to provide users with a large enough machine-independent virtual memory; use another procedure without knowledge of its requirements such as storage and sharing of procedures and data.

3. Contribution
Concepts of process and address space:
Each process runs in its own address space thus is independent with others and controlled by a processor. Virtual memory of a MULTICS process is an ordered set of segments consisting words. Each segment has attributes information such as access privilege. It can be treated as data or procedure depends on how it is intended accessed.
Addressing mechanisms are designed to effectively reference to a word with the help of its generalized address. External flag is used to switch between internal reference and control switch. A table called descriptor segment is used to perform a two-step look up. Paging is implemented for simple storage allocation.

Detailed descriptions on requirements, data structure and mechanisms of intersegment linking and addressing implementation.

4. Evaluation
There is no evaluation session in this paper. But the author made simple evaluation while illustrating the MULTICS.

5. Confusion
How control bits work
“Pure” means procedure segments must not cause a single word of their content to be modified, what content?

Summary>
The paper discusses basic concepts of processes, address space, and virtual memory used in the MULTICS system. Secure sharing of procedure, code and data among users is discussed through dynamic linking and the mechanism by which symbolic references are dynamically transformed into virtual machine address is also described in detail.

Problem>
MULTICS time-sharing OS’s goal was to serve the computing needs of a large community of users, operating principally from remote terminals. Few of the objectives that helped achieving the goal were to move physical storage management from user to system software, permit degree of programming generality by calling procedures by symbolic name and also allow sharing of procedures and data among multiple users.

Contribution
Few of the contributions I think were worth mentioning:
Large address space per process, machine independent VM mechanism.
Concept of generalized address i.e. a location independent means of identifying information.
Discussion of hierarchical directory structure with symbolic names, automatic backups
Segments as granularity of sharing (concept of protection rings and the protection level). Segments are also “made known” before access from a process.
Dynamic Linking resolves references across segments.

Evaluation
No performance evaluation is mentioned in the paper but it seems like this a part of bigger research and hence this paper miss out evaluation details. Authors could have shared performance results of procedure sharing and indirect addressing.

Confusion
I didn’t understand the last section where linking mechanism is discussed in detail.

Summary
This paper presents the concepts behind the design of MULTICS, which is an operating system that was designed to be accessed by a large variety of users with different workloads. Some of the goals of the system were to provide the user with large virtual memory space which is independent of the machine, to allow the user to reference a procedure by simply referencing its name, and to allow procedures to be shared between multiple processes so that copying of routines can be avoided. To do this, the paper presents a generalized addressing scheme that specifies a segment number and a word number and allows the procedure to read data independent of the location it is stored at.
Problem
MULTICS was designed such that multiple users could access the system at once. Previously, calling a remote procedure required knowing the address location of the desired procedure and did not allow processes to dynamically link into shared procedures efficiently. MULTICS was an attempt to allow programmers to call a procedure by simply specifying the procedure name and to link into shared procedures to reduce the number of copies of code replicated in memory.
Contributions
MULTICS defined the concept of a process and an address space to be connected, or a one to one correspondence for each process to address space. The system also introduced a generalized addressing scheme, which allowed processes to lookup specific words within a segment. A generalized address was composed of a segment number and a word number. Extra hardware support was added to accommodate for four base pair registers in each processor. To construct a generalized address, the instruction was combined with the appropriate base register according to the specified address mode to calculate the word number. Then, the segment tag of the instruction is used for the segment number. To lookup the segment using the generalized address, the system would use the segment number to index into a table that is maintained per process. Indirect addressing was also introduced, in which the generalized address points to another generalized address where the actual data resides. This is the basis for the linkage mechanism of MULTICS. MULTICS also allows for a procedure to reference another procedure using only its name by using a link structure that uses indirect addressing to point to the specified segment.
Evaluation
The paper doesn’t present an evaluation of the system. It would have been interesting to know how much the memory management techniques presented reduced the overhead in accessing memory, or if it actually contributed more overhead.
Confusions
I’m a little confused on how the link structure and the descriptor segment table interact with each other when accessing memory. Additionally, when a procedure is recompiled, how does the link structure get updated with the new proper address of the procedure?

Summary:
This paper describes the implementation of process, address space and virtual memory in the MULTICS OS. The format of virtual memory as segments and pages is discussed along with how the addressing scheme is made location independent. Symbolic links to share procedure and data segments are also discussed in detail.

Problem:
Since MULTICS was to be used a computing resource by multiple user programs the authors wanted to facilitate user processes by providing them with a machine independent address space without concerning them with complicated buffering and overlays. Secondly they wanted to improve programming generality by having the ability to call other procedures by their symbolic names, without having prior knowledge of the specifics of that procedure. Additionally they wanted to promote secure sharing of data and code among processes without duplicating segments.

Contributions:
The use of segments to clearly organize data and code made for a simple and clear address space structure for each process. The implementation of location independent addressing by using base registers and descriptor segment tables was another simplification for user processes and it also made it easier to switch between processes. Inter-segment linkage allowed for pure procedure segments to be used in a shared library fashion by calling them via symbolic names and making them invariant to recompilation of other segments. Using link data private to the procedure allowed for them to be symbolic and invariant. Requirements of procedure calls like argument passing and private space for the procedure are fulfilled via stack frames reserved for each procedure.

Evaluation:
The paper has no evaluation in terms of benchmark results or even commentary on the expected performance of the various abstractions. The performance cost of establishing a link by trapping into the kernel could have been discussed. The cost of the address translation is another performance overhead worth investigating.

Confusion:
I did not understand the last section on the linkage mechanism of transferring from one procedure to another.

Summary:
This paper describes the basic concepts involved in the design of
MULTICS OS like processes, address spaces, virtual memory, paging, and
segmentation. This paper also talks about linking procedure and data
information between users.

Problem:
The authors want to design a system which enables users to share
procedures and data while simultaneously providing them with a huge
virtual memory which provides isolation. The system also provides an
interface where the users can access data with only names and don't
have to worry about physical memory addresses.

Contributions:
1. Providing the users with large virtual memory which is divided into
segments. For segments that are large, Multics uses paging to allow
non-contiguous blocks of main memory to be referenced together.
2. Accessing data and procedures by introducing the generalized
addressing mode which has the segment number and the word number. This
enables the users to reference a word regardless of its location in
the storage hierarchy.
3. Enforcing access control for a segment via descriptor segments of
the processes.
4. This paper introduced hierarchical directory structure where
directories are associated with one symbolic name for each segment.
These names are invariant over all processes.
5. Since traversing the directory tree to access data every time might
be slow, Multics uses linking to store symbolic names and their memory
addresses.

Evaluation:
The paper does not have an evaluation section.

Confusions:
I don't understand how linking works differently for procedure
segments and data segments.

Summary

This paper presents some of the design concepts behind MULTICS, an important operating system in the 1960s which heavily influenced Unix. It introduces very early designs of virtual memory, dynamic linking (known here as intersegment linking) and shared memory. The paper discusses in great detail the addressing system used in MULTICS, designed to be flexible and secure for a wide case of uses.

Problem

The authors do not go into any detail about existing operating systems or what particular problems they were trying to solve. They do mention that they are trying to improve flexibility, which suggests that is one motivating problem. They also go into considerable detail describing intersegment linking, which infers that sharing data and execution code between different and users was very limited in other systems.

Contributions

The paper presented three main contributions:

  1. Providing the user with machine-independent virtual memory, such that user level programs did not need to deal with the lower-level details of memory management.
  2. Allowing one process to run code that exists in another process' memory at runtime; effectively, dynamic linking.
  3. Security mechanisms, effectively access control lists, to ensure interprocess communications are protected at a user level.

Evaluation

The authors do not provide any evaluation of the system -- they simply describe how the various mechanisms work. Granted that they were focused on improving flexibility instead of performance, they ought to have provided some quantitative measurements.

Confusions

I struggled immensely with this paper -- even after reading external sources and other online reviews, I wasn't able to make much sense of it. Notable confusions:

  • The general addressing mechanism mostly made sense, but I couldn't understand what indirect address was or how it is used.
  • Is there a distinction between main memory and secondary memory? It sounds like everything is just in main memory all the time?
  • How exactly do they mix paging and segmentation?
  • The second half of the paper dealing with intersegment linking and addressing was especially difficult. I didn't understand this even at a high level.

1. Summary
This paper discusses the basic concepts of process address space, addressing mechanism and dynamic linking, used in the MULTICS system. The address space is shown to be composed of variable length segments which can be addressed using a generalized addressing scheme. This addressing scheme can be used to address files and memory uniformly. Secure & reliable code and procedure sharing is possible in this system through dynamic inter-segment linking.

2. Problem
MULTICS system was expected to simultaneously serve many users with diverse usage requirements. Towards this end, the designers seek to simplify user-level programming by providing a machine-independent virtual memory, the ability to call procedures using symbolic names and allow safe sharing of code and data.

3. Contributions
The notion of process in MULTICS is intertwined with a private virtual address space consisting of variable length segments. The 32-bit VA space was large enough (back in the day) to allow mapping of memory and disk contents onto it. A directory structure is maintained by the system which is a hierarchical arrangement of mappings from symbolic file names to segment numbers. A generalized addressing scheme is introduced in which each instruction fetch and data access is composed into a segment number and a word offset within the segment. The segment base addresses are stored in respective processor registers. To allow flexible pointer-style operations, MULTICS supports indirect addressing. Given a generalized address, the memory lookup consists of indexing into tables, table entries provide the segment access control information. Since individual segments can become too big, they are split into fixed-size pages for flexible allocation and replacement. MULTICS allows a procedure to invoke a data/code reference to another unknown segment using just a symbolic name. Using a link data structure, the OS can replace references to the symbolic name with the actual memory addresses of the code/data segment. This allows faster access after an initial trap during the first access. An advantage of this approach is that the caller procedure is agnostic of the exact location of a destination as well as its recompilations.

4. Evaluation
This paper offers no evaluations. Considering that operations like linking require multiple memory references for each access, I’m interested in knowing the perf overhead of offering this convenience.

5. Confusions
The inter-segment code linking operation is not clear (Figure 13). What is the reason for indexing into the linkage section of the called procedure Q? If a data/code segment is recompiled, how will this information be reflected in procedures which have linked to this? Is there a backpointer that we can follow to invalidate these links?

Summary - This paper discusses virtual memory, processes and sharing in MULTICS. It describes in detail the concepts of a process and an address. It stresses the notion of a generalized address which is a location independent way of addressing words. It talks about how addresses are formed directly and indirectly. Of much value is the description of the descriptor segment which is a table of descriptors for different segments. Then inter-segment linking and addressing is discussed. How a certain procedure can call another procedure (or more precisely segments containing code) is described in great detail. The concept of a pointer that is used for intersegment linkage is discussed. Finally, how procedure call and return happens with the help of a stack is pondered upon.

Problem - The problem being addressed is to provide a set of simultaneous users a uniform view of memory in the form of segmentation and paging while keeping access rights in mind. Data objects can now share information and call each other's procedures without the knowledge of each other's requirements for storage or any other procedures they might call. This was not practical earlier.

Contributions -

1) A uniform view of virtual addresses is provided to all processes which stand in one-to-one correspondence to these virtual memories
2) Generalized addresses are a combination of a segment number and a word offset and they are location independent
3) The procedure base register and the program counter collectively generate the location of the next instruction
4) Indirect addressing is also possible for data access depending on the mode field in the instruction
5) The descriptor base register holds the base address of the descriptor table for segments
6) The use of linkage data of the originating segment, link pointer and the symbol table of the destination segment are crucial for inter-segment communication.

Evaluation - No evaluation data has been reported in this paper. However a benchmark of reduced performance due to procedure calls and inter-segment linkages could have been shown.

Confusions - I don't completely understand the linkage mechanism for procedure entry as depicted in Fig. 13

Summary - The implementation of processes, address spaces, virtual memory and dynamic linking in the MULTICS operating system is described in this paper. In particular, the construction of the location-independent generalized address, its translation into the machine address and the mechanism behind using symbolic names for linking segments is explained in detail.

Problem - The overall goal driving this work is to create a time-sharing system capable of serving the diverse requirements of many simultaneous users. Coming to the aspects discussed in this paper, Daley and Dennis wished to move the onus of memory management from the programmer to the operating system, by creating a uniform view of memory. Also, they wanted to enable the use of procedures without substantial knowledge of its requirements, and also enforce secure sharing of procedures and data.

Contributions - While MULTICS did not introduce the concepts of paging, segments or virtual memory, it was one of the first systems to incorporate these concepts together with protection guarantees in a well-designed system. Also, the MULTICS system associated processes with individual address spaces, and most importantly treated files and segments uniformly. A dynamic linking mechanism to allow symbolic references to segments is also an important contribution of this system.

Evaluation - There is no evaluation reported for the ideas presented in this paper. This might be due to the fact that this paper specifically focuses on a few aspects of the MULTICS design, and is part of a larger group of papers about this system. However, the authors could have shown the performance degradation due to address translation, or the cost of indirect addressing. Furthermore, savings due to resource sharing facilitated by dynamic linkages, or the impact to procedure call latencies could have been discussed.

Confusions - I am not sure I understand the directory structure of the virtual memory/segments as shown in Fig 1 correctly. To be more precise, how do you traverse that tree, and what is present at the various non-leaf nodes?

Post a comment