UNIX V6 memory layout - Revision history

Jnc: /* Split I-D layout */ precision

2023-07-08T13:20:28Z

‎Split I-D layout: precision

Jnc: /* Split I-D layout */ minor clarifications

2022-06-23T13:33:22Z

‎Split I-D layout: minor clarifications

Jnc: simplifies swapping

2022-06-23T01:36:53Z

simplifies swapping

Jnc: clarification copyedits

2021-06-12T13:29:06Z

clarification copyedits

Jnc: minor copyedits,

2021-06-11T12:05:48Z

minor copyedits,

Jnc: Jnc moved page UNIX V6 kernel memory layout to UNIX V6 memory layout: Now covers user as well as kernel

2021-06-11T02:52:43Z

Jnc moved page UNIX V6 kernel memory layout to UNIX V6 memory layout: Now covers user as well as kernel

Jnc: Cover mem + addr space generally

2021-06-11T02:51:52Z

Cover mem + addr space generally

Jnc: Jnc moved page Unix V6 kernel memory layout to UNIX V6 kernel memory layout: Consistent caps

2021-03-10T16:47:48Z

Jnc moved page Unix V6 kernel memory layout to UNIX V6 kernel memory layout: Consistent caps

Jnc: consistent caps

2021-03-10T16:46:52Z

consistent caps

Jnc: clarify

2020-09-15T16:04:31Z

clarify

@@ Line 23: / Line 23: @@
 ===Split I-D layout===
-The more powerful models of the PDP-11 supported by V6 (the [[PDP-11/45]] and [[PDP-11/70]]) provide two independent 16-bit address spaces for code and data, for both the kernel, and for user processes. (Two of the data segments have fixed, special usage, as described above.) The way the code and data blocks are allocated to actual physical main memory for the kernel are non-obvious, though.
+The more powerful models of the PDP-11 supported by V6 (the [[PDP-11/45]] and [[PDP-11/70]]) provide two independent 16-bit address spaces for code and data, for both the kernel, and for user processes. (In the kernel, two of the data segments have fixed, special usage, as described above.) The way the code and data blocks are allocated to actual physical main memory for the kernel are non-obvious, though.
 All the kernel data (both initialized and un-initialized), along with a small amount of code, is placed in low ''physical'' memory. The advantage of doing this is that the physical address of any kernel data is the same as its virtual address, so when setting up a peripheral to do [[Direct Memory Access|DMA]] (which ''always'' uses physical addresses), no address translation is necessary.

@@ Line 23: / Line 23: @@
 ===Split I-D layout===
-The more powerful models of the PDP-11 supported by V6 (the [[PDP-11/45]] and [[PDP-11/70]]) provide two independent 16-bit address spaces for code and data, for both the kernel, and for user processes. (Two of the data segments have fixed, special usage, as described above.) The way the code and data blocks are allocated to actual physical main memory for the OS are non-obvious, though.
+The more powerful models of the PDP-11 supported by V6 (the [[PDP-11/45]] and [[PDP-11/70]]) provide two independent 16-bit address spaces for code and data, for both the kernel, and for user processes. (Two of the data segments have fixed, special usage, as described above.) The way the code and data blocks are allocated to actual physical main memory for the kernel are non-obvious, though.
 All the kernel data (both initialized and un-initialized), along with a small amount of code, is placed in low ''physical'' memory. The advantage of doing this is that the physical address of any kernel data is the same as its virtual address, so when setting up a peripheral to do [[Direct Memory Access|DMA]] (which ''always'' uses physical addresses), no address translation is necessary.
@@ Line 33: / Line 33: @@
 First, the Unix [[linker]] is not prepared to produce output files in which the data is below the code (in file terms), which is what would be needed to simply load the file produced by the linker into main memory, and have things wind up at the correct physical locations.
-Rather than complicate the [[bootstrap]] (which, in V6, is a single-stage which has to fit into a single [[disk block]]) to perform this transformation, a separate program, 'sysfix', post-processes the linker's output to produce a file where the initialized data is below the code; it also moves the code's [[absolute address]] up, so that it starts at the start of the second page of the instruction space.
+Rather than complicate the [[bootstrap]] (which, in V6, is a single stage which has to fit into a single [[disk block]]) to perform this transformation, a separate program, 'sysfix', post-processes the linker's output [[object code]] to produce a file where the initialized data is placed below the code; it also moves the code's [[absolute address]] up, so that it starts at the start of the second page of the instruction space.
 This is because of that small amount of code in low memory; instruction address space segment 0 is used to contain this (once memory management is enabled), so that it will appear in the address space at the same place after memory management is enabled as before (so that this code, which is what is running when memory management is turned on, will appear in the same place during that); this means that the system's actual code must start in segment 1.

@@ Line 5: / Line 5: @@
 Two segments of the kernel's [[virtual address]] space are used for specialized purposes. One segment is used for gaining access to the swappable per-process data of each process (including its kernel [[stack]]); this is the 'user' block (the term 'user' is re-used here). Thus, that data for the current process is thus always at the same virtual address in the kernel's address space, no matter which process is running. The other special segment is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s. The other kernel segments are used for one or two (see below) large block(s) containing the kernel's code and data; details of the kernel's address space and main memory layout are given below.
-User processes contain data in two separate blocks of virtual address space (one for the stack), and potentially also another block containing [[pure code]]. (If a user program has pure code, and two processes are running that program, they will share a single copy in main memory of its pure code.) If the process does not have pure code, the instructions are in the same block as the data. The two data blocks are ''always'' stored contiguously in main memory, along with the 'user' block, and all three are always swapped as a unit; this simplifies physical memory allocation.
+User processes contain data in two separate blocks of virtual address space (one for the stack), and potentially also another block containing [[pure code]]. (If a user program has pure code, and two processes are running that program, they will share a single copy in main memory of its pure code.) If the process does not have pure code, the instructions are in the same block as the data. The two data blocks are ''always'' stored contiguously in main memory, along with the 'user' block, and all three are always swapped as a unit; this simplifies physical memory allocation and swapping code.
 ==Two variants in kernel layout==

@@ Line 3: / Line 3: @@
 [[PDP-11 Memory Management]] provides a number of [[segment]]s of [[address space]], both in kernel and [[user]] mode. Each segment can be independently mapped to main memory, but UNIX makes very limited use of the overall potential flexibility; rather, it is mostly used to provide a few large blocks.
-Two segments of the kernel's [[virtual address]] space are used for specialized purposes. One is for gaining access to the swappable per-process data of each process (including its kernel [[stack]]); this is the 'user' block (the term 'user' is re-used here). Thus, that data for the current process is thus always at the same virtual address in the kernel's address space, no matter which process is running. The other special segment is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s. The other kernel segments are used for one or two (see below) large block(s) containing the kernel's code and data; details of the kernel's address space and main memory layout are given below.
+Two segments of the kernel's [[virtual address]] space are used for specialized purposes. One segment is used for gaining access to the swappable per-process data of each process (including its kernel [[stack]]); this is the 'user' block (the term 'user' is re-used here). Thus, that data for the current process is thus always at the same virtual address in the kernel's address space, no matter which process is running. The other special segment is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s. The other kernel segments are used for one or two (see below) large block(s) containing the kernel's code and data; details of the kernel's address space and main memory layout are given below.
-User processes contain data in two separate blocks of virtual address space (one for the stack), and potentially also another block containing [[pure code]]. (If a user program has pure code, and two processes are running that program, they will share a single copy of it in main memory.) If the process does not have pure code, the instructions are in the same block as the data. The two data blocks are ''always'' stored contiguously in main memory, along with the 'user' block, and all three are always swapped as a unit; this simplifies physical memory allocation.
+User processes contain data in two separate blocks of virtual address space (one for the stack), and potentially also another block containing [[pure code]]. (If a user program has pure code, and two processes are running that program, they will share a single copy in main memory of its pure code.) If the process does not have pure code, the instructions are in the same block as the data. The two data blocks are ''always'' stored contiguously in main memory, along with the 'user' block, and all three are always swapped as a unit; this simplifies physical memory allocation.
 ==Two variants in kernel layout==

@@ Line 1: / Line 1: @@
-'''UNIX V6 memory layout''', and how [[UNIX Sixth Edition]] uses the [[main memory]] and [[memory management]] of the system, is fairly simple. The [[operating system]]'s [[kernel]] (both [[instruction]]s and data) permanently occupies low physical memory; [[process]]es reside above the kernel, and can be [[swapping|swapped]] in and out, from [[secondary storage]], as needed. All physical memory above the OS is available for use by processes.
+'''UNIX V6 memory layout''', and how [[UNIX Sixth Edition]] uses the [[main memory]] and [[memory management]] of the host [[PDP-11]] system, is fairly simple. The [[operating system]]'s [[kernel]] (both [[instruction]]s and data) permanently occupies low physical memory; [[process]]es reside above the kernel, and can be [[swapping|swapped]] in and out, from [[secondary storage]], as needed. All physical memory above the OS is available for use by processes.
 [[PDP-11 Memory Management]] provides a number of [[segment]]s of [[address space]], both in kernel and [[user]] mode. Each segment can be independently mapped to main memory, but UNIX makes very limited use of the overall potential flexibility; rather, it is mostly used to provide a few large blocks.
-Two segments of the kernel's address space are used for specialized purposes. One is for gaining access to the swappable per-process data of each process (including its kernel [[stack]]); this is the 'user' block (the term 'user' is re-used here). Thus, that data is thus always at the same [[virtual address]] in the kernel's address space, no matter which process is running. The other segment is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s. The other kernel segments are used for on or two (see below) large block(s) containing the kernel's code and data; details of the kernel's address space and main memory layout are below.
+Two segments of the kernel's [[virtual address]] space are used for specialized purposes. One is for gaining access to the swappable per-process data of each process (including its kernel [[stack]]); this is the 'user' block (the term 'user' is re-used here). Thus, that data for the current process is thus always at the same virtual address in the kernel's address space, no matter which process is running. The other special segment is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s. The other kernel segments are used for one or two (see below) large block(s) containing the kernel's code and data; details of the kernel's address space and main memory layout are given below.
 User processes contain data in two separate blocks of virtual address space (one for the stack), and potentially also another block containing [[pure code]]. (If a user program has pure code, and two processes are running that program, they will share a single copy of it in main memory.) If the process does not have pure code, the instructions are in the same block as the data. The two data blocks are ''always'' stored contiguously in main memory, along with the 'user' block, and all three are always swapped as a unit; this simplifies physical memory allocation.
@@ Line 9: / Line 9: @@
 ==Two variants in kernel layout==
-The details of how the kernel of UNIX V6 uses the main memory of the system is fundamentally different between the two types of PDP-11 Memory Management provided by the various models of [[PDP-11]] on which UNIX V6 runs.
+The details of how the kernel of UNIX V6 uses the main memory of the system is fundamentally different between the two types of PDP-11 Memory Management provided by the various models of PDP-11 on which UNIX V6 runs.
 ===Single-space layout===
@@ Line 17: / Line 17: @@
 The organization of the kernel's address space is very similar to that of a Unix process: the [[object code]] is in the low part of the kernel's address space, with initialized data above it, and the so-called [[BSS]] (un-initialized data) above that.
-This exactly matches the layout of all this in actual physical main memory; the operating system is in the lowest physical memory, with the code at the bottom, and kernel data above that. There are 8 segments available when memory management is enabled; the first 6 are used to hold the kernel's instructions and data, as described. As mentioned above, the 7th segment is used to gain access to the swappable per-process data of each process, and the 8th is set up to allow access to the UNIBUS 'I/O Page'.
+This exactly matches the layout of all this in actual physical main memory; the OS is in the lowest physical memory, with the code at the bottom, and kernel data above that. There are 8 segments available when memory management is enabled; the first 6 are used to hold the kernel's instructions and data, as described. As mentioned above, the 7th segment is used to gain access to the swappable per-process data of each process, and the 8th is set up to allow access to the UNIBUS 'I/O Page'.
 Note that the allocation of 6 segments to the kernel's code and data provides a hard limit on the size of the kernel, including the number of [[disk]] [[buffer]]s, etc. (Later versions of UNIX supported [[overlay]]s in the kernel, to remove this limitation.) The stock V6 ''does not'' check to make sure that a system build respects this limit; it is perfectly possible to build images that take more than 6 segments (48KB) to hold them, which ''will'' fail in bizarre and un-predictable ways.
@@ Line 50: / Line 50: @@
 ** [[Running UNIX v6 in SIMH]]
 * [[Installing UNIX Sixth Edition on Ersatz-11]]
 [[Category: UNIX]]

← Older revision	Revision as of 02:52, 11 June 2021
(No difference)

← Older revision	Revision as of 16:47, 10 March 2021
(No difference)

@@ Line 1: / Line 1: @@
-The '''Unix V6 kernel memory layout''' is fundamentally different between the two types of [[PDP-11 Memory Management]] provided by the various models of [[PDP-11]] on which [[UNIX Sixth Edition]] runs.
+The '''UNIX V6 kernel memory layout''' is fundamentally different between the two types of [[PDP-11 Memory Management]] provided by the various models of [[PDP-11]] on which [[UNIX Sixth Edition]] runs.
 ==Single-space layout==
@@ Line 34: / Line 34: @@
 * [[UNIX V6 internals]]
-** [[Unix V6 dump analysis]]
+** [[UNIX V6 dump analysis]]
 * [[Installing UNIX Sixth Edition]]
 ** [[Setting up UNIX Sixth Edition]]
 ** [[Upgrading UNIX Sixth Edition‎]]
 ** [[Running UNIX V6 on an -11/23]]
-* [[Installing Unix v6 (PDP-11) on SIMH]]
+* [[Installing UNIX v6 (PDP-11) on SIMH]]
-** [[Running Unix v6 in SIMH]]
+** [[Running UNIX v6 in SIMH]]
 * [[Installing UNIX Sixth Edition on Ersatz-11]]
 [[Category: UNIX]]

@@ Line 9: / Line 9: @@
 This exactly matches the layout of all this in actual physical [[main memory]]; the [[operating system]] is in the lowest physical memory, with the code at the bottom, and kernel data above that. Any physical memory above the OS is available for use by [[user]] processes.
-There are 8 [[segment]]s available with memory management enabled; 6 are used to hold the kernel's [[instruction]]s and data, as described above. There are two other specialized areas of memory as well; the 7th segment is used to gain access to the [[swapping|swappable]] per-process data of each process (including its kernel [[stack]]); the 8th is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s.
+There are 8 [[segment]]s available with memory management enabled; the first 6 are used to hold the kernel's [[instruction]]s and data, as described above. There are two other specialized areas of memory as well; the 7th segment is used to gain access to the [[swapping|swappable]] per-process data of each process (including its kernel [[stack]]); the 8th is set up to allow access to the [[UNIBUS]]'s so-called 'I/O Page', which holds [[peripheral]] and [[Central Processing Unit|CPU]] [[register]]s.
 Note that the allocation of 6 segments to the kernel's code and data provides a hard limit on the size of the kernel, including the number of [[disk]] [[buffer]]s, etc. The stock V6 ''does not'' check to make sure that a system build respects this limit; it is perfectly possible to build images that take more than 6 segments (48KB) to hold them, which ''will'' fail in bizarre and un-predictable ways.