Comments on CIS 211 Labs 2 and 3, Spring 2000

General Comments

Coding Conventions, Styles, and Software Engineering Tips

Comments Specific to Labs 4 and 5

General Comments

• It looks as though some of you got access to solutions to this lab from last year. What you apparently did not notice is that this lab is not exactly the same as last year's, and so copying last years' solutions gives you wrong answers for this year's lab.

  What to learn from this mistake is this:

  1. You can get in a lot of trouble for passing someone else's work as your own. The penalties here can be anything from getting 0 on the assignment to getting expelled from the University. (Anyone who thinks I'm exaggerating should look at the cheating policy statement on the CIS 314 web page.) We are talking to those students that we suspect of having cheated on this assignment.
  2. Just because you find a solution that looks like it has to do with your problem, don't assume that you can use it. You will make some big mistakes if you do. Research is useful, but don't let it keep you from thinking.

• Many of you killed a lot of trees for this assignment. Try not to waste paper by putting one six-line class definition on each of 16 pages. (Besides, I don't want to carry that much paper around. :))

  Coding Conventions, Styles, and Software Engineering Tips

• Good indentation in code is like correct spelling and punctuation in writing. You can get along without it, and people may still be able to understand you...but it makes comprehension much more difficult, and makes errors much more likely. Two tips:
  • Don't use word processors (such as Word) to write code. It's not what they're designed for, and they're not good at formatting it properly. Text editors that "understand" a computer language will actually automatically properly indent a file that has been identified as a source file for that language. They will also often do syntax highlighting (so the keywords and special symbols are easily seen). I recommend emacs (on Unix machines), TextPad, and the editor in the integrated development environments of many commercial compilers.
  • Don't use proportionally-spaced fonts. Good fonts to use are Courier and Lucida Sans. In any event, don't use spaces to indent your code.

• DOCUMENT YOUR CODE. Many people made mistakes because they did not carefully read the textbook to see what the instructions should do. Your documentation should be explaining the effect on the state of the machine of executing these instructions to someone who does not have the book. The process of writing good documentation should alert you to any misunderstandings that you have.

  On a related note: the order of operands for operations like subtraction and comparison is important. Your documentation should specify whether the first operand is being subtracted from the second or vice versa, and so on.

• This may seem kind of obvious, but...if we ask you to write a test driver or method, it needs to test all the components of the system. Many people lost points on the selfTest() method of Lab 4 because it simply did not test all the methods you'd written; some people left entire components out of the tester!

• Reminder: error messages and test output should be descriptive. You should not have to have access to the source code in order to interpret the output of the program.

  Comments Specific to Labs 4 and 5

  Lab 4

• The most common mistake on Lab 4 was to fail to allow the person using your Machine class to specify the size of memory or the input and output streams. This is nothing new. You need to think about what the constructors should be doing, and what parameters they should be able to take.

• Another popular mistake for Lab 4: failing to set up the PrintWriter such that it would automatically flush the buffer whenever it saw a newline character. (Take a look at the API documentation.) This is how you would generally expect the output stream to work.

• The get() functions for the registers should not create a new PC/ACC/IR register every time they are called. The registers should be created once, in the Processor constructor, and initialized to some documented value at that time.

  Lab 5

• The single most common mistake on Lab 5 was to allocate storage for the Instruction's operand inside the definition for Instruction. Remember that Instruction is a subclass of Word, and Word has the storage that you need. Allocating space for another Word (Address) inside Instruction--or inside the subclasses of Instruction--is a waste of space. You can easily write a getAddress() function that returns the value stored in the Word superclass.

• You were asked to write the execute method for these instructions. Some of you were modifying the program counter (PC) and so forth, when these are properly part of the "instruction fetch" and "decode" cycles of the processing of an assembly language instruction. You should review the discussion on the machine architecture in the textbook.

• On a related note, don't put operations in these instructions that don't belong there. The conditional JUMP instructions (JUMPEQ, JUMPGT, etc.) check the condition codes set by a previous comparison. They do not execute a comparison themselves. Read the documentation!

• Contrariwise, don't do your own arithmetic for ADD, SUB, INC, and DEC. You have a perfectly good ALU--use its functions. Since you're trying to simulate a real machine, that's all you really can use.

• The JUMP instructions modify the program counter, (PC) not the instruction register (IR). Make sure that you understand the difference between the address of the current instruction, and the instruction itself.

• Something I've said before.

• In the IN instruction, you should have caught any ioE exceptions that were thrown as a result calling the io.readData() method. Please note that these methods threw MachineE. (And modifying the specifications so that they also throw HaltE was a good way to lose a lot of points.)