-Added IRQ to PCI

[pintos-anon] / doc / doc.texi

diff --git a/doc/doc.texi b/doc/doc.texi
index 55a80f508ca9d7cbcac5c967b8580c109152e7e9..44f6e7dfa3a7407e0ee8244f7b7ef6fc24ec7f4a 100644 (file)
--- 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
 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::                      
 
 @menu
 * README::                      

-* DESIGNDOC    ::              
-* TESTCASE     ::              
+* DESIGNDOC::                   
+* TESTCASE::                    

 @end menu
 
 @node README
 @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.
 
 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,
 @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.
 
 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
 @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.
 
 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
 
 @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
 @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
 
 @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
 
 @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 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,
 @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.
 
 from a workload for the non-Solaris scheduler and the Solaris
 scheduler and explain why the Solaris scheduler is better.