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
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,
Things you @emph{don't} need: an explanation of the pre-existing
Pintos code, an explanation of the project spec, justification for the
-project (e.g.@: we don't need you to explain to us why filesystems are
+project (e.g.@: we don't need you to explain to us why file systems are
important to an operating system), a play-by-play of every change you
made to the system, any other pontificating. (You may laugh at some
of the things listed above, but we've gotten all of them in the past.)
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
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
+example, in testing @func{thread_join} you would have specified that
+you test @func{thread_join} when it is called multiple times on the
same child thread.
@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()},
+have done a great job with the testing of @func{thread_join},
creating very succinct short tests. We like that.
@item
@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