Update docs.

diff --git a/doc/Makefile b/doc/Makefile
index cfb7cbfbf9e6a4611a07539c36568805b98e9a03..b2e8a4387656dd82e094daf33249b7e7c0a97fcc 100644 (file)
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -1,5 +1,6 @@
 TEXIS = projects.texi intro.texi threads.texi mlfqs.texi userprog.texi \
-filesys.texi vm.texi standards.texi doc.texi devel.texi debug.texi
+vm.texi filesys.texi references.texi standards.texi doc.texi devel.texi        \
+debug.texi
 
 all: projects.html projects.info
 

diff --git a/doc/filesys.texi b/doc/filesys.texi
index c854ff3b8ba5f83c87e36a39f16e00207196e982..c20ac8a5ca2351267f7585f33e7d63f95ddb1e09 100644 (file)
--- a/doc/filesys.texi
+++ b/doc/filesys.texi
@@ -1,4 +1,4 @@
-@node Project 4--File Systems, Multilevel Feedback Scheduling, Project 3--Virtual Memory, Top
+@node Project 4--File Systems, References, Project 3--Virtual Memory, Top
 @chapter Project 4: File Systems
 
 In the previous two assignments, you made extensive use of a

diff --git a/doc/mlfqs.texi b/doc/mlfqs.texi
index cb64dc448481ddefc6a8dbfc69a932ad208dfcd0..253f91b7226ccefd47241e6198548414c0198fae 100644 (file)
--- a/doc/mlfqs.texi
+++ b/doc/mlfqs.texi
@@ -1,4 +1,4 @@
-@node Multilevel Feedback Scheduling, Coding Standards, Project 4--File Systems, Top
+@node Multilevel Feedback Scheduling, Coding Standards, References, Top
 @appendix Multilevel Feedback Scheduling
 
 This section gives a brief overview of the behavior of the Solaris 2.6

diff --git a/doc/projects.texi b/doc/projects.texi
index f803ac07a8fd99dba5cc9451347e3b26f872c8d0..3437dcc265d21393216ba9ae1f8d4b3d3cba56a5 100644 (file)
--- a/doc/projects.texi
+++ b/doc/projects.texi
@@ -4,6 +4,30 @@
 @settitle Pintos Projects
 @c %**end of header
 
+@c @bibref{} macro
+@iftex
+@macro bibref{cite}
+[\cite\]
+@end macro
+@end iftex
+@ifinfo
+@ifnotplaintext
+@macro bibref{cite}
+@ref{\cite\}
+@end macro
+@end ifnotplaintext
+@ifplaintext
+@macro bibref{cite}
+[\cite\]
+@end macro
+@end ifplaintext
+@end ifinfo
+@ifhtml
+@macro bibref{cite}
+[@ref{\cite\}]
+@end macro
+@end ifhtml
+
 @titlepage
 @title Pintos Projects
 @end titlepage
@@ -21,6 +45,7 @@
 * Project 2--User Programs::    
 * Project 3--Virtual Memory::   
 * Project 4--File Systems::     
+* References::
 * Multilevel Feedback Scheduling::  
 * Coding Standards::            
 * Project Documentation::       
@@ -32,6 +57,7 @@
 @include userprog.texi
 @include vm.texi
 @include filesys.texi
+@include references.texi
 @include mlfqs.texi
 @include standards.texi
 @include doc.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index d353f2212ed12ad5e64af51e830329ef572d8b9e..62e8a3e3b5d755a8b9f192c2bd9da782e1cd2e70 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -79,7 +79,7 @@ why the @code{switch_threads()} that gets called is different from the
 @strong{Warning}: In Pintos, each thread is assigned a small,
 fixed-size execution stack just under @w{4 kB} in size.  The kernel
 does try to detect stack overflow, but it cannot always succeed.  You
-ma cause bizarre problems, such as mysterious kernel panics, if you
+may cause bizarre problems, such as mysterious kernel panics, if you
 declare large data structures as non-static local variables,
 e.g. @samp{int buf[1000];}.  Alternatives to stack allocation include
 the page allocator in @file{threads/palloc.c} and the block allocator
@@ -282,10 +282,7 @@ program twice and have it do exactly the same thing.  On second and
 later runs, you can make new observations without having to discard or
 verify your old observations.  This property is called
 ``reproducibility.''  The simulator we use, Bochs, can be set up for
-reproducibility.  If you use the Bochs configuration files we provide,
-which specify @samp{ips: @var{n}} where @var{n} is a number of
-simulated instructions per second, your simulations can be
-reproducible.
+reproducibility, and that's the way that @command{pintos} invokes it.
 
 Of course, a simulation can only be reproducible from one run to the
 next if its input is the same each time.  For simulating an entire
@@ -586,7 +583,7 @@ the function isn't actually used by other @file{.c} files, make it
 
 @menu
 * Problem 1-1 Alarm Clock FAQ::  
-* Problem 1-2 Join FAQ::       
+* Problem 1-2 Join FAQ::        
 * Problem 1-3 Priority Scheduling FAQ::  
 * Problem 1-4 Advanced Scheduler FAQ::  
 @end menu

diff --git a/doc/userprog.texi b/doc/userprog.texi
index 36012330b79bfbb47f84137b97e3f1a5ba6c06ff..5c0ee7224830eb5ae8df2179dcb414e1b1e0ae15 100644 (file)
--- a/doc/userprog.texi
+++ b/doc/userprog.texi
@@ -654,7 +654,7 @@ calling convention.  Some of the basics should be familiar from CS
 have seen even more of it.  I've omitted some of the complexity, since
 this isn't a class in how function calls work, so don't expect this to
 be exactly correct in full, gory detail.  If you do want all the
-details, you can refer to @cite{[SysV-i386]}.
+details, you can refer to @bibref{SysV-i386}.
 
 Whenever a function call happens, you need to put the arguments on the
 call stack for that function, before the code for that function

diff --git a/doc/vm.texi b/doc/vm.texi
index b7f766ea2a50fdef73c7a958fd3440a70a4bd1b2..8ff592207d3b49dba0fb02e8486ed1ee6a870c92 100644 (file)
--- a/doc/vm.texi
+++ b/doc/vm.texi
@@ -112,20 +112,20 @@ can effectively ignore this CPU feature.}
 
 @enumerate 1
 @item
-The top 10 bits of the virtual address (bits 22:31) are used to index
+The top 10 bits of the virtual address (bits 22:32) are used to index
 into the page directory.  If the PDE is marked ``present,'' the
 physical address of a page table is read from the PDE thus obtained.
 If the PDE is marked ``not present'' then a page fault occurs.
 
 @item
-The next 10 bits of the virtual address (bits 12:21) are used to index
+The next 10 bits of the virtual address (bits 12:22) are used to index
 into the page table.  If the PTE is marked ``present,'' the physical
 address of a data page is read from the PTE thus obtained.  If the PTE
 is marked ``not present'' then a page fault occurs.
 
 
 @item
-The bottom 12 bits of the virtual address (bits 0:11) are added to the
+The bottom 12 bits of the virtual address (bits 0:12) are added to the
 data page's physical base address, producing the final physical
 address.
 @end enumerate