X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fdoc.texi;h=44f6e7dfa3a7407e0ee8244f7b7ef6fc24ec7f4a;hb=ab5803357924a8682a25dab18fbedbc965e32d86;hp=55a80f508ca9d7cbcac5c967b8580c109152e7e9;hpb=699944803572c46c550a39027c0ebd935b0d61bc;p=pintos-anon

diff --git a/doc/doc.texi b/doc/doc.texi
index 55a80f5..44f6e7d 100644
--- a/doc/doc.texi
+++ b/doc/doc.texi
@@ -10,12 +10,14 @@ Your submission should have exactly one of each file, in the
 appropriate directory (e.g.@: for Assignment 1, place the files in the
 @file{threads} directory).  These files must be written in plain text
 format (not Microsoft Word, not PDF).  We recommend a text width of 65
-characters per line, with a hard limit of 80.
+characters per line, with a hard limit of 80.  If you use tab characters
+in your document files, be sure that your text editor's tab width is set
+to 8.
 
 @menu
 * README::                      
-* DESIGNDOC 	::              
-* TESTCASE 	::              
+* DESIGNDOC::                   
+* TESTCASE::                    
 @end menu
 
 @node README
@@ -30,7 +32,7 @@ dependencies, and so on.
 If you added extra credit features to your project, explain them
 concisely in the @file{README}.  Otherwise, we're likely to miss them.
 
-@node DESIGNDOC 	
+@node DESIGNDOC
 @section @file{DESIGNDOC}
 
 This file is our primary tool for assessing your design.  Therefore,
@@ -65,7 +67,7 @@ Finally, please keep your @file{DESIGNDOC} as short as you can,
 without sacrificing key design decisions.  You should be brief, yet
 complete.  We don't want to read novels.
 
-@node TESTCASE 	
+@node TESTCASE
 @section @file{TESTCASE}
 
 The @file{TESTCASE} file should contain all the information about how
@@ -82,9 +84,7 @@ required, you should explain why you feel so.  For each test that you
 write, explain how we can use them, and show some sample output from a
 run.
 
-Specifically, here are some pointers for writing @file{TESTCASE} files
-which will make them more succinct and us more likely to understand the
-tests you write:
+Here are some pointers for writing @file{TESTCASE} files:
 
 @itemize @bullet
 @item
@@ -93,15 +93,10 @@ Show us that you tested each part of your assignment.
 @item
 Clearly state in your @file{TESTCASE} file what each test is supposed
 to test.  You should be testing not only the common case, but testing
-corner cases.  Specify what criteria or issue is being tested.  For
-example, in testing @code{thread_join()} you would have specified that
-you test @code{thread_join()} when it is called multiple times on the
-same child thread.
+corner cases.  Specify what criteria or issue is being tested.
 
 @item
-Make your tests as succinct as possible.  Most students in the past
-have done a great job with the testing of @code{thread_join()},
-creating very succinct short tests.  We like that.
+Make your tests as succinct as possible.
 
 @item
 Your test cases should be placed in a subdirectory called
@@ -110,13 +105,28 @@ should be in @file{pintos/src/threads/testcases}.
 
 @item
 Think about what may actually crash your code.
+
+@item
+Think about what the compiler might do to your code.  Suppose you write
+the following to test your virtual memory implementation's ability to
+expand the stack:
+@example
+int main (void) @{
+  int array[4096];
+  array[123] = 234;
+  return 0;
+@}
+@end example
+@noindent The compiler is quite likely to notice that the value that you
+write to the array is never used again and thereby decide not to write
+it at all.  The result is that your test does not test anything at all.
 @end itemize
 
 Your @file{TESTCASE} file is also where you can show us the
 improvements that your code makes to the performance of the system.
 You should be able to show us ``before'' and ``after'' performance
 data, and explain how the data shows the improvement.  For example,
-for Problem 1-4, you should show us in the @file{TESTCASE} printouts
+for Problem 1-3, you should show us in the @file{TESTCASE} printouts
 from a workload for the non-Solaris scheduler and the Solaris
 scheduler and explain why the Solaris scheduler is better.