UNIX V6 internals - Revision history

Jnc: Add link to new Lions page; improve qsav text a bit while I'm here

2024-04-08T11:48:09Z

Add link to new Lions page; improve qsav text a bit while I'm here

Jnc: /* exec() and pure-text images */ PWB1 implements the idea of bypassing the swap-out

2023-09-28T15:26:53Z

‎exec() and pure-text images: PWB1 implements the idea of bypassing the swap-out

Jnc: +Booting

2022-01-04T11:28:06Z

+Booting

Jnc: Read V6 mem article first

2021-06-11T03:02:58Z

Read V6 mem article first

Jnc: /* exec() and pure-text images */ correct emph

2019-05-07T17:15:05Z

‎exec() and pure-text images: correct emph

Jnc: /* See also */ fmt

2019-03-03T01:35:12Z

‎See also: fmt

Jnc: +See also

2019-03-03T01:18:00Z

+See also

Jnc: Jnc moved page Unix V6 internals to UNIX V6 internals: Use consisten caps

2019-02-13T13:33:12Z

Jnc moved page Unix V6 internals to UNIX V6 internals: Use consisten caps

Jnc: /* exec() and pure-text images */ clarify

2019-02-12T04:58:06Z

‎exec() and pure-text images: clarify

Jnc: /* rsav, qsav and ssav */ clarify

2019-02-12T04:50:20Z

‎rsav, qsav and ssav: clarify

@@ Line 1: / Line 1: @@
-The internals of [[UNIX Sixth Edition|UNIX V6]] are relatively easy to understand, particularly with the aid of the (justly) famed [[Lions book]], John Lions' ''Commentary on UNIX 6th Edition''. Reading [[UNIX V6 memory layout]], which explains V6's use of physical [[main memory]], and [[PDP-11 Memory Management]], is recommended as a first step, before tackling Lions.
+The internals of [[UNIX Sixth Edition|UNIX V6]] are relatively easy to understand, particularly with the aid of the (justly) famed [[Lions book]], [[John Lions]]' ''Commentary on UNIX 6th Edition''. Reading [[UNIX V6 memory layout]], which explains V6's use of physical [[main memory]], and [[PDP-11 Memory Management]], is recommended as a first step, before tackling Lions.
 Here are a few notes on various specific topics which are covered in more detail than in Lions, and which may be helpful.
@@ Line 13: / Line 13: @@
 These are the primitives which switch, or otherwise adjust, [[stack]]s in the kernel. aretu() is significantly different from retu() - the latter switches to a different process/stack, whereas aretu() does a 'non-local goto' in the current process. (Actually, technically, it switches to a different [[stack frame]] on the current stack; when the [[subroutine]] which had called aretu() returns, it does not return to its caller, but instead returns to the procedure which had called savu().) In addition to switching to a different stack, retu() also switches to a saved stack frame on that stack, in the same manner as aretu().
-Note that in [[PDP-11]] [[C programming language|C]] all stack frames look identical, but this is not true of other machines/[[compiler]]s. So if subroutine A calls savu(), and subroutine B calls aretu(), when the call to aretu() returns, procedure B is still running, but on procedure A's stack frame. So on machines where A's stack frame looks different from B's, hilarity ensues; this famously caused a problem when [[Unix Seventh Edition]] was moved to the [[Interdata 8/32]].
+Note that in [[PDP-11]] [[C programming language|C]] all stack frames look identical, but this is not true of other machines/[[compiler]]s. So if subroutine A calls savu(), and subroutine B calls aretu(), when the call to aretu() returns, procedure B is still running, but on procedure A's stack frame. So on machines where A's stack frame looks different from B's, hilarity ensues; this famously caused a serious problem when [[Unix Seventh Edition]] was moved to the [[Interdata 8/32]].
 ===rsav, qsav and ssav===
@@ Line 24: / Line 24: @@
 Calls to retu(), the primitive to switch stacks/processes, ''always'' use rsav. The others are for 'non-local gotos' inside a process.
-One can think of the qsav as a poor man's [[condition handler|exception handler]] for software [[interrupt]]s to a process while it's asleep in the kernel, waiting for something. When a process is interrupted out of such a wait, rather than the sleep() call returning, the process wakes up returning from the procedure that did the savu(qsav). (That happens because sleep() - which is the procedure that's running when the call to aretu(qsav) returns - does a return immediately after restoring the stack to the frame saved in qsav.)
+One can think of the qsav as a poor man's [[condition handler|exception handler]] for software [[interrupt]]s to a process while it's asleep in the kernel, waiting for something. When a process is interrupted out of such a wait, rather than the sleep() call returning, the process wakes up returning from the procedure that did the savu(qsav). (That happens because sleep() - which is the procedure that's running when the call to aretu(qsav) returns - does a return immediately after restoring the stack to the frame saved in qsav.) The intervening call chain (from the savu() to the sleep()) is ''discarded'' - which is why UNIX has that annoying "Interrupted system call" system call error return.
-The ssav is used in association with swapping; when a process is swapped out, since that can happen in a number of ways/places, the call stack can contains calls to various things like expand(), etc. When it's swapped back in, apparently rather than include code in all those places to unwind the call stack, the simplest thing to do is to just throw that all away, and have it go back to where it was just before it was decided to swap it out.
+The ssav is used in association with swapping; when a process is swapped out, since that can happen in a number of ways/places, the [[call stack]] can contain calls to various things like expand(), etc. When it's swapped back in, apparently rather than include code in all those places to unwind the call stack, the simplest thing to do is to just throw that all away, and have it go back to where it was just before it was decided to swap it out.
 ==exec() and pure-text images==
@@ Line 42: / Line 42: @@
 Things are considerably more complex when the new program/command has a pure text.
-In such a case, exec() calls xalloc(), which, if the text was not already available (either in main memory, or swapped out), reads in a copy of the pure text from the file, and then ''always'' moves that (contiguous) copy out to the swap device. In both this case, and if the text was in use, but not already in main memory, it ''also'' swaps the rest of the process out, because, as the code explains:
+In such a case, exec() calls xalloc(), which, if the text was not already available (either in main memory, or swapped out), reads in a copy of the pure text from the file, and then ''always'' moves that (contiguous) copy out to the swap device. In both this case, and if the text was in use, but not already in main memory, it ''also'' swaps out the rest of the process, because, as the code explains:
 <pre>
    if the calling process

@@ Line 49: / Line 49: @@
    see if the text does fit and simply swap it in.
 </pre>
-The first part of of the comment is applicable even in the case where the text was just read into main memory: note that the process doesn't yet have a data or stack segment allocated at that point, just the 'user' area. (The two will be stored contiguously with the 'user' area, when they are eventually added.)
+The first part of the comment is applicable even in the case where the text was just read into main memory: note that the process doesn't yet have a data or stack segment allocated at that point, just the 'user' area. (The two will be stored contiguously with the 'user' area, when they are eventually added.)
 The data and stack segments will be set up later in the exec() code, after the call to xalloc() returns, after the process is swapped back in, but this may be impossible if the text segment is 'poorly' placed in main memory - which is why the in-memory copy is discarded. (This is more likely to be an issue on systems with a limited amount of main memory, of course.)
@@ Line 55: / Line 55: @@
 (In fact, the process will ''never'' have anything other than a 'user' area when in xalloc(); the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the 'user' area.)
-(It would be possible to do what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text as well as the rest of the process, and if so, avoiding the swap-out/in of the 'user' segment of the process.)
+(It would be possible to do what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text as well as the rest of the process, and if so, avoiding the swap-out/in of the 'user' segment of the process. It appears that something like this was done in [[PWB/UNIX]], which is otherwise mostly very similar to V6; xalloc() calls xexpand(), which only swaps out the process if there is no room for the pure text. In PWB1, though, the data and stack segments have already been set up when this happens.)
 Anyway, unlike the mixed text/data case, a considerable number of swap operations ''inevitably'' result, (the exact number depending on exactly what the situation is with main memory); for the first instance of a pure-text program/command, at least:

@@ Line 2: / Line 2: @@
 Here are a few notes on various specific topics which are covered in more detail than in Lions, and which may be helpful.
 ==savu(), retu() and aretu()==
-These are the primitives which switch, or otherwise adjust, [[stack]]s in the [[kernel]]. aretu() is significantly different from retu() - the latter switches to a different [[process]]/stack, whereas aretu() does a 'non-local goto' in the current process. (Actually, technically, it switches to a different [[stack frame]] on the current stack; when the [[subroutine]] which had called aretu() returns, it does not return to its caller, but instead returns to the procedure which had called savu().) In addition to switching to a different stack, retu() also switches to a saved stack frame on that stack, in the same manner as aretu().
+These are the primitives which switch, or otherwise adjust, [[stack]]s in the kernel. aretu() is significantly different from retu() - the latter switches to a different process/stack, whereas aretu() does a 'non-local goto' in the current process. (Actually, technically, it switches to a different [[stack frame]] on the current stack; when the [[subroutine]] which had called aretu() returns, it does not return to its caller, but instead returns to the procedure which had called savu().) In addition to switching to a different stack, retu() also switches to a saved stack frame on that stack, in the same manner as aretu().
 Note that in [[PDP-11]] [[C programming language|C]] all stack frames look identical, but this is not true of other machines/[[compiler]]s. So if subroutine A calls savu(), and subroutine B calls aretu(), when the call to aretu() returns, procedure B is still running, but on procedure A's stack frame. So on machines where A's stack frame looks different from B's, hilarity ensues; this famously caused a problem when [[Unix Seventh Edition]] was moved to the [[Interdata 8/32]].
@@ Line 11: / Line 17: @@
 ===rsav, qsav and ssav===
-There are actually three sets of saved stack information stored in the 'user' [[structure]] (the [[swapping|swappable]] per-process data block):
+There are actually three sets of saved stack information stored in the 'user' [[structure]] (the swappable per-process data block):
 <pre>	int	u_rsav[2];	/* save r5,r6 when exchanging stacks */
 	int	u_qsav[2];	/* label variable for quits and interrupts */
@@ Line 18: / Line 24: @@
 Calls to retu(), the primitive to switch stacks/processes, ''always'' use rsav. The others are for 'non-local gotos' inside a process.
-One can think of the qsav as a poor man's [[condition handler|exception handler]] for software [[interrupt]]s to a processs while it's asleep in the kernel, waiting for something. When a process is interrupted out of such a wait, rather than the sleep() call returning, the process wakes up returning from the procedure that did the savu(qsav). (That happens because sleep() - which is the procedure that's running when the call to aretu(qsav) returns - does a return immediately after restoring the stack to the frame saved in qsav.)
+One can think of the qsav as a poor man's [[condition handler|exception handler]] for software [[interrupt]]s to a process while it's asleep in the kernel, waiting for something. When a process is interrupted out of such a wait, rather than the sleep() call returning, the process wakes up returning from the procedure that did the savu(qsav). (That happens because sleep() - which is the procedure that's running when the call to aretu(qsav) returns - does a return immediately after restoring the stack to the frame saved in qsav.)
 The ssav is used in association with swapping; when a process is swapped out, since that can happen in a number of ways/places, the call stack can contains calls to various things like expand(), etc. When it's swapped back in, apparently rather than include code in all those places to unwind the call stack, the simplest thing to do is to just throw that all away, and have it go back to where it was just before it was decided to swap it out.
@@ Line 51: / Line 57: @@
 (It would be possible to do what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text as well as the rest of the process, and if so, avoiding the swap-out/in of the 'user' segment of the process.)
-Anyway, unlike the mixed text/data case, a considerable number of swap operations ''inevitably result'', (the exact number depending on exactly what the situation is with main memory); for the first instance of a pure-text program/command, at least:
+Anyway, unlike the mixed text/data case, a considerable number of swap operations ''inevitably'' result, (the exact number depending on exactly what the situation is with main memory); for the first instance of a pure-text program/command, at least:
 * swapping out the text

@@ Line 1: / Line 1: @@
-The internals of [[UNIX Sixth Edition|UNIX V6]] are relatively easy to understand, particularly with the aid of the (justly) famed [[Lions book]], John Lions' ''Commentary on UNIX 6th Edition''.
+The internals of [[UNIX Sixth Edition|UNIX V6]] are relatively easy to understand, particularly with the aid of the (justly) famed [[Lions book]], John Lions' ''Commentary on UNIX 6th Edition''. Reading [[UNIX V6 memory layout]], which explains V6's use of physical [[main memory]], and [[PDP-11 Memory Management]], is recommended as a first step, before tackling Lions.
-Here are a few notes on various topics which are covered in a bit more detail than in Lions, and which may be helpful.
+Here are a few notes on various specific topics which are covered in more detail than in Lions, and which may be helpful.
 ==savu(), retu() and aretu()==
@@ Line 9: / Line 9: @@
 Note that in [[PDP-11]] [[C programming language|C]] all stack frames look identical, but this is not true of other machines/[[compiler]]s. So if subroutine A calls savu(), and subroutine B calls aretu(), when the call to aretu() returns, procedure B is still running, but on procedure A's stack frame. So on machines where A's stack frame looks different from B's, hilarity ensues; this famously caused a problem when [[Unix Seventh Edition]] was moved to the [[Interdata 8/32]].
-==rsav, qsav and ssav==
+===rsav, qsav and ssav===
 There are actually three sets of saved stack information stored in the 'user' [[structure]] (the [[swapping|swappable]] per-process data block):
@@ Line 24: / Line 24: @@
 ==exec() and pure-text images==
-For simple [[program]]s/commands (stored in the [[file system]] in a [[file]], and read into [[main memory]] to [[execute]] them), UNIX divides the [[address space]] of a process into a mixed 'text/data' [[segment]] and a 'stack' segment, using [[hardware]] support from [[PDP-11 Memory Management]]. The text/data segment contains both [[object code]], and data.
+For simple [[program]]s/commands (stored in the [[file system]] in a [[file]], and read into main memory to [[execute]] them), UNIX divides the [[address space]] of a process into a mixed 'text/data' [[segment]] and a 'stack' segment, using [[hardware]] support from PDP-11 Memory Management. The text/data segment contains both [[object code]], and data.
 UNIX also has the ability to provide separate 'text' (referred to as a 'pure text') and 'data' segments; the text segment will be read-only, and shared between all processes executing that program/command.
@@ Line 64: / Line 64: @@
 ==See also==
-* [[Unix V6 kernel memory layout]]
+* [[Unix V6 dump analysis]]
 * [[Installing UNIX Sixth Edition]]
 ** [[Setting up UNIX Sixth Edition]]

@@ Line 47: / Line 47: @@
 The data and stack segments will be set up later in the exec() code, after the call to xalloc() returns, after the process is swapped back in, but this may be impossible if the text segment is 'poorly' placed in main memory - which is why the in-memory copy is discarded. (This is more likely to be an issue on systems with a limited amount of main memory, of course.)
-(In fact, the process will _never_ have anything other than a 'user' area when in xalloc(); the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the 'user' area.)
+(In fact, the process will ''never'' have anything other than a 'user' area when in xalloc(); the only call to xalloc() in the system is immediately preceeded by an "expand(USIZE)" which throws away everything except the 'user' area.)
 (It would be possible to do what the comment suggests - adding code to check to see if there's enough memory available to hold the pure text as well as the rest of the process, and if so, avoiding the swap-out/in of the 'user' segment of the process.)

@@ Line 66: / Line 66: @@
 * [[Unix V6 kernel memory layout]]
 ** [[Unix V6 dump analysis]]
 * [[Installing UNIX Sixth Edition]]
 ** [[Setting up UNIX Sixth Edition]]
-* [[Running UNIX V6 on an -11/23]]
+** [[Upgrading UNIX Sixth Edition‎]]
 * [[Installing Unix v6 (PDP-11) on SIMH]]
 ** [[Running Unix v6 in SIMH]]

← Older revision		Revision as of 01:18, 3 March 2019
Line 61:		Line 61:

	Note that at that point, after the two swaps in, the process still does not have its data and stack segments; therefore, the call to expand(), after the return from xalloc(), to allocate the memory for them, may ''also'' result in a swap out/in cycle.		Note that at that point, after the two swaps in, the process still does not have its data and stack segments; therefore, the call to expand(), after the return from xalloc(), to allocate the memory for them, may ''also'' result in a swap out/in cycle.
		+
		+	==See also==
		+
		+	* [[Unix V6 kernel memory layout]]
		+	** [[Unix V6 dump analysis]]
		+	* [[Upgrading UNIX Sixth Edition‎]]
		+	* [[Installing UNIX Sixth Edition]]
		+	** [[Setting up UNIX Sixth Edition]]
		+	* [[Running UNIX V6 on an -11/23]]
		+	* [[Installing Unix v6 (PDP-11) on SIMH]]
		+	** [[Running Unix v6 in SIMH]]
		+	* [[Installing UNIX Sixth Edition on Ersatz-11]]

	==External links==		==External links==

← Older revision	Revision as of 13:33, 13 February 2019
(No difference)

@@ Line 26: / Line 26: @@
 For simple [[program]]s/commands (stored in the [[file system]] in a [[file]], and read into [[main memory]] to [[execute]] them), UNIX divides the [[address space]] of a process into a mixed 'text/data' [[segment]] and a 'stack' segment, using [[hardware]] support from [[PDP-11 Memory Management]]. The text/data segment contains both [[object code]], and data.
-UNIX also has the ability to provide separate 'text' and 'data' segments (referred to as a 'pure text'); the text segment will be read-only, and shared between all processes executing that program.
+UNIX also has the ability to provide separate 'text' (referred to as a 'pure text') and 'data' segments; the text segment will be read-only, and shared between all processes executing that program/command.
 (Note that for simplicity, the data and stack segments are stored contiguously in physical main memory, although they are in separate segments in the address space of the process.)
-The operation of the exec() system call (which replaces the contents of the address space of a process with new contents, read in from a program/command in a file) is fairly simple for mixed programs/commands: a block of main memory large enough to hold the new program/command is allocated (the process may pause before this happens), the text and data is read in, and off it goes.
+The operation of the exec() system call (which replaces the contents of the address space of a process with new contents, read in from a program/command stored in a file) is fairly simple for mixed programs/commands: a block of main memory large enough to hold the new program/command is allocated (the process may pause to be swapped out before this happens), the text and data is read in, and off it goes.
 Both newproc() (the routine that implements the fork() operation) and expand() (the routine used to re-size the data/stack segments of a process) have code which uses a simple memory-memory copy if there is enough free memory to do what they have been requested to do.
@@ Line 36: / Line 36: @@
 Things are considerably more complex when the new program/command has a pure text.
-In such a case, exec() calls xalloc(), which, if the text was not already available, reads in a copy of the pure text from the file, and then ''always'' moves that (contiguous) copy out to the swap device. In both this case, and if the text was in use, but not already in main memory, it ''also'' swaps the rest of the process out, because, as the code explains:
+In such a case, exec() calls xalloc(), which, if the text was not already available (either in main memory, or swapped out), reads in a copy of the pure text from the file, and then ''always'' moves that (contiguous) copy out to the swap device. In both this case, and if the text was in use, but not already in main memory, it ''also'' swaps the rest of the process out, because, as the code explains:
 <pre>
    if the calling process
@@ Line 58: / Line 58: @@
 * swapping the 'user' area back in
-The last two are performed by the so-called 'swapping' process (process 0), which runs in a permanent loop in the kernel, in sched(); its job is to find processes that need to be swapped in, and do so (often after swapping others out, to make room).
+The last two are performed by the so-called 'swapping' process (process 0), which runs in a permanent loop in the kernel, in sched(); its job is to find processes that need to be swapped in, and do so (perhaps after swapping others out, to make room).
 Note that at that point, after the two swaps in, the process still does not have its data and stack segments; therefore, the call to expand(), after the return from xalloc(), to allocate the memory for them, may ''also'' result in a swap out/in cycle.