CS224 -- Spring 2012
Project #1: Assembly Language Programming
Complete Design Report
Due Date & Place: Wednesday March 21st, between 13:05 and 13:55, to be submitted into the box in the Computer Engineering Department headquarters (4th floor of EA building). No early submissions (before 13:05) will be accepted. Late submissions (after 13:55) will be penalized quite heavily, so make every effort to get your report in on time, by the deadline! [Note: the person submitting the reports can be a friend, it doesn’t have to be a group member—no one should miss their class because of turning in the Complete Design Report.]
Late penalty: Reports submitted after the deadline, but the same day, will have 15 points deducted from the score. After that, a deduction of 20 additional points for each day will apply . Groups which do not submit the report will receive a ZERO!
Submission Rule: Each group should prepare and submit only one Complete Design Report. Of course, they should keep a copy for themselves, in order to be able to continue work on the project. The box for submission will be located on the table near the mail slots, marked “CS224 Project #1 Complete Design Reports”. There should be no talking or congregating in the office. Don't talk to the secretary, just submit your report and leave quietly.
Contents: The Complete Design Report will consist of a cover page, followed by a table of contents page, followed by the main body of the report, with each part beginning on a new page:
Cover/title page, with course number, semester name and year, name of the document, group #, name/ID/phone/email/section listed for each group member, along with the signature in blue or black ink of each person to the Honor Pledge (signatures in pencil are invalid and unacceptable), a listing of the resources used (write "None" next to the category if not used), and the submission date. Each group should use the cover page template given here, personalized for your group of course. Note: Reports with missing signatures, or pencil signatures, will not be accepted.
Table of contents page, listing each section and subsection of the main report body, with the page number that the section and subsection begins on.
The main body of the report containing 6 sections, each explaining one of the 6 data structure utilitie. The order should be as follows: build, check, sort2list, . Each section should begin on a new page. For each section, there should be 3 parts, describing the utility in English, then at a high level (in HLL or high-level pseudocode), and then in intermediate-level pseudocode. For each of the 6 sections, there should be 5 subsections, each subsection beginning on a new page. The subsections are as follows, to be given in this order:
a) the updated newest version of the verbal explanation of the utility (including what it does and how it does it) in clear understandable English, along with any figures needed to explain the concepts. The figures should be clear, and add to the reader’s understanding of how the utility does its work on the data structure. To help your English explanation, you should use pictures and figures. All the figures in this section should have a figure number, and a caption (e.g. "Figure 2: The cell-wall structure showing the energy transport openings") and should be referred to in the text at an appropriate point, by its figure number. Figures always come after their reference in the text, not before. If at all possible, a figure should be on the same page as the first text reference to it.
b) a list of changes that have been made to the high-level code (or high-level pseudocode) or to the intermediate level pseudocode (and possibly to the English explantion) that came from the desgin review. For each item that has changed, tell whether the idea to change it came from Being Reviewed, from Doing the Reviews, or from Both, or from Other. For each change item in your list, tell in words what the old code did, and what the new code does now. If it is not impossible or impractical (for example, too many lines of code), show the change by giving the old and new lines of code (or old and new English sentences, if the English explanation changed).
c) the updated newest version of the high-level code (written in C, C++, Java or high-level pseudocode) which describes the algorithm of the utility. The 6 utility routines should be written in well-structured self-documenting high-level language code (or high-level pseudocode). You should not include a “main” program, just the 6 callable subroutines, plus the headers described below. There should be lots of line-commenting in your high-level code, to make it easy to understand. The line comments should be formatted in proper alignment. Each of the 6 procedures must be preceded by an explanatory header, which contains a description of the algorithm and lists and explains all the variables and data structures used in the procedure. In summary, the high-level code should be self-documenting, meaning that it is understandable to others because of the procedure headers, code comments (found throughout the code), well-chosen names (for variables, functions, etc), and spacing and alignment for readability.
d) the updated newest version of the “explanation” of the utility in intermediate-level pseudocode. In other words, there should be a pseudocode implementation of the utility, which includes an explanatory header and comments. As with any code, the pseudocode should be self-documenting, which means it contains an explanatory header, lots of comments next to the instructions, and use of meaningful symbols and variable names. The pseudocode should make clear the algorithm used, i.e. how the utility will be realized. The semantic level of the pseudocode should be intermediate-level, between the HLL and assembly language, so that it can serve as a transition step before writing the assembly code. You should follow the given syntax guide for pseudocode; this will help to standardize the pseudocodes. The pseudocode should use white space and formatting to enhance readability and understandability. The intermediate-level pseudocode is not real code from MIPS or any other language—it is described with examples in the Pseudocode Guide.
e) the current implementation of the utility in MIPS code, which has been translated from the intermediate-level pseudocode. Like the high-level and the intermediate level code, your MIPS code should be completely self-documenting, which means it contains an explanatory header (which explains the algorithm used, lists all the registers and gives their usage in the routine), lots of comments next to the instructions (nearly all lines should be commented, with the comments all in alignment), meaningful label names, and good use of white space and alignment/formatting to enhance readability and understandability. You may use MIPS pseudoinstructions in your code. The code for the utility routine may call subroutines as necessary to help it accomplish its function.
Summary: The format of the Complete Design Report is somewhat similar to the Preliminary Design Report. But for each of the 6 utility routines, there are 2 new subsections: a subsection listing and explaining any changes to your design that came from the design review process, and a subsection giving the self-documenting MIPS code (including an explanatory header and much line commenting, etc). So the report will contain a cover page, a table of contents, and for each utility, the English explanation, the list of changes made in the design review process and information about those changes, the high-level code (or pseudocode), the intermediate-level pseudocode, and the MIPS code.
Format: The report should be typed, and printed out on a high quality printer. Its appearance should be professional, clean and neat throughout. It should be stapled in the upper left-hand corner, with the sections arranged in the order given (above) and submitted without a folder. Each of the subsections in the body of the report should begin at the top of a new page, and should have a section number which is consistent, and a heading or title.
Grading: The score for your Complete Design Report will be based on the following criteria:
Your report has the correct cover page (use the form given above) with all the information on it, and a table of contents as specified above.
For each of the 6 routines, your group has integrated the feedbacks from the design reviews, and has improved/revised/corrected the high-level code and intermediate-level pseudocode.
For each of the 6 routines, your report contains English explanation, list of changes, high-level code, intermediate-level pseudocode, and MIPS assembly language code.
For each of the 6 routines, your MIPS code is translated from your intermediate-level pseudocode.
For each of the 6 routines, your MIPS code is complete, no parts are missing.
For each of the 6 routines, your MIPS code contains a good explanatory header.
For each of the 6 routines, nearly 100% of lines in your MIPS code have line-comments.