Chapter 1 Introduction to the Course
- Table of Contents
- 1.1 Machine Problems
- 1.2 WWW Page
Welcome to ECE 291, Computer Engineering II. This chapter will acquaint you with the various aspects of this course, from details on grading to instructions on how to demo machine problems.
1.1 Machine Problems
1.1.1 Requirements and Grading Procedures
1.1.1.1 Point Totals
Your machine problems will be graded according to the following formula:
1.1.1.1.1 Functionality Points
You are expected to provide an original, fully functional solution to all machine problems. Due to the complexity of MP2 and later machine problems, you will occasionally be supplied with additional library subroutines which implement all or some portion of the assignment. These subroutines are to assist you in writing and debugging your code, but are not intended to be handed in as part of your solution. If your solution requires the use of one or more library subroutines, you will be penalized accordingly for using them. The penalty for each library subroutine will be indicated in the assignment. There is no penalty for the use of the subroutines kbdin, kbdine, dspout, dspmsg, dosxit, ascbin, and binasc (all present in LIB291). We may announce additions to this list of free subroutines.
1.1.1.1.2 Score Modifiers
Points may be subtracted from the functionality score based on your submitted source code. The graders look for the following items in the source code:
-
Comments
-
Technique and Style
-
I/O Specifications
-
Modularity
1.1.1.1.3 Penalty/Bonus
Bonus points are awarded for turning in a machine problem early. As the lab contains far fewer machines than there are students in the class, long waits to use a computer or demo a machine problem can be avoided by starting and finishing assigned machine problems early. To encourage this, extra points are awarded for each working day (Mon-Fri) the assignment is early. The amount of extra points awarded will be shown on the online grading sheet. Likewise, penalty points are subtracted for every working day an assignment is late.
1.1.1.2 Comments
There are two main kinds of comments we are looking for, line comments and procedure comments. Good line comments supply additional information or context for a given assembler instruction. They explain something that might not be obvious, rather than merely echoing the instruction itself.
Procedure comments, also known as header comments, are required for each and every procedure in your program. Foremost, they describe what the procedure is supposed to do. They should also describe which registers and/or memory locations hold the procedure's input values, which registers and/or memory locations hold the output values when the procedure exits, and which registers are changed as part of the normal execution of the procedure. Excellent examples of proper commenting style are available in your laboratory notebook. Take advantage of them.
1.1.1.3 Style
Good style implies a number of practices have been followed in your program: (a) code is not repeated, (b) commonly used sequences are separated into independent subroutines, and (c) the execution path of your program does not look like "spaghetti."
Generally, if you have a significant series of instructions repeated in your program, you probably need to rethink how you approached the problem. Look for a way to consolidate the instructions so that you don't have to repeat them; this almost always reveals a solution that is easier to implement and debug.
If you just can not consolidate the instructions, consider making them a separate, independent subroutine. Then you just call the subroutine from multiple places in your program.
Finally, any procedure (this includes main) should probably resemble the flowchart of the same task. Execution starts at the top, and flows generally downward. If you have lots of branches every which way, you might want to make it easier for human readers and graders (hint!). Some advanced microprocessors rely on certain code patterns for optimum performance, and if you follow good programming style, your programs will be more efficient (employers like this!).
1.1.1.4 I/O Specifications
You will be given specifications for some of the procedures you write for later machine problems. You must follow these specifications, even though you will write the entire program by yourself. These specifications will include which registers pass values into the procedure, which registers hold values on exit from the procedure, and which registers must remain unmodified.
1.1.1.5 Modularity
Modularity and style are closely related. A modular program will use subroutines in the obvious places; see above. A modular program will also use loops instead of in-line code, and tables instead of a long series of compare and branch instructions. All these practices will make your program much easier to write and debug, and will make your life simpler if you ever need to modify your program. A modular program rarely encounters the problem of a branch-out-of-range; a modular procedure usually fits on the screen, and certainly fits completely on a printed page. If your procedures are longer than one page, think carefully about what you wrote.
1.1.2 Demonstration
When you hand in machine problems, you are responsible for meeting the following conditions:
-
You must demonstrate your correctly working program to a TA or instructor in the lab, and be able to answer reasonable questions about how you did it.
-
You must provide an electronic listing of the .ASM file for your program.
-
The TA or instructor must be able to copy your .ASM file to the official Web-based hand-in, assemble and link them with our copies of NASM and TLINK, and get the same program.
The lab computers have Intel Pentium III processors running at 1 Ghz. If you own or have access to other PC compatible computers, you will probably be able to do a lot of the lab work outside of the lab. However, your program must eventually be demonstrated in the lab, and there are often subtle differences between PC compatible computer models. If you do your work outside of the lab, make sure you allow yourself enough time to test and modify your program so it runs in the lab. Also remember that the staff will be unable to answer questions about computers outside the lab.
The same warning applies to your choice of editor, debugging tools, and so forth. You may use whatever PC tools you feel most comfortable with, but your program has to run in the lab using our hardware and software. Please note there may be questions on the homework and/or exams which refer to the tools in the lab; you will be expected to be somewhat familiar with them, even if you choose other tools for most of your work.
1.1.3 The Big Picture
Creation of an assembly language program requires several steps, from the initial ideas to the finished executable. The following flow chart illustrates the development of an assembly-language program.
