Skip Navigation CECS Home | ANU Home | Search ANU

COMP2300

Semester 1, 2009: Assignment 2

Deadline: 12:00 (noon) on Friday 08 May 2007

(Please report any errors, mistakes and ambiguities to the course lecturer)

Any changes to the document from its release date will be marked in blue.

---

This assignment is worth 10% of your total course mark. It will be marked out of 40 as indicated below.

---

The estimated time we expect you to spend on this assignment is around 10 hours in total (1 hour per 4 assignment marks).

Submission

This assignment must be submitted electronically. This can be done using the submit comp2300 ass2 ... command (or the submit comp6300 ass1 ... command, if you have a COMP6300 enrollment).

You should submit a separate file for each part of the assignment you are required to complete. The file names which you should use (and the only ones that will be accepted by the submit command) are:

    forum.mli
    shuffle.ass
As an example of what you should do

    submit comp2300 ass2 forum.mli shuffle.ass

All files submitted must include, at the beginning, a completed preamble. The proforma for this can be found in the file:

      /dept/dcs/comp2300/public/standard_preamble.mli

You have to copy the preamble from this file into the top of each file you intend to submit, and then complete your details. By submitting a file containing a completed preamble, you are making a declaration about the work you have submitted (see the text of the declaration in the preamble files. If you need to modify the text, e.g. you did in fact receive substantial assistance from another student, you should modify the text to say so.

Any file submitted without a completed preamble will be rejected without being marked.

Note you can submit any file multiple times, including after the deadline has expired. Note that if you submit any file after the deadline your entire submission will be considered as late and will attract a late penalty.

The correctness of programs submitted is determined only by their behavior when run using the PeANUt software on the CS (Linux) student system. A final testing of all programs should be performed on this system.

Extensions

See http://cs.anu.edu.au/student/comp2300/assessment.php.

Late Penalties

Late penalties are as follows

How Late	Penalty from 40 Marks
less than 1 hour	-1
between 1 and 6 hour	-2
between 6 and 24 hours (1 day)	-4
between 24 and 48 hours (2 days)	-8
between 48 and 72 hours (3 days)	-16
between 72 and 96 hours (4 days)	-32
more than 96 hours (4 days)	-40 (forget it!)

Note: late penalties apply even if you submit just one file after the deadline.

Plagiarism

See http://cs.anu.edu.au/student/comp2300/assessment.php.

---

Part 1 - Machine Language Programming [8 marks]

Write a PeANUt machine language program forum.mli that reads in a line of text and prints out the line with each tab character converted into a space, all multiple spaces (including converted tabs) converted into a single space and the line truncated from the occurrence of the first < character. Note that in all cases, the line of output must be terminated by a (single) EOL character. For example, given the input (there is a tab between the parentheses):

 Show   a  tab (	) in html?   If n<k, its all   over!

Your program should produce the output:

 Show a tab ( ) in html? If n

Style:

• In this assignment you have to write a machine language program (do NOT submit an assembly language program).
• Your program should be set out with only one instruction per line.
• Each instruction should have accompanying comments which explain the effect of the instruction (as done in the example programs in the lectures). The first part of each comment should be the address of the instruction in octal, for example aXY, like shown in the lectures and labs. The rest should be a meaningful comment on what the instruction does.

Hints:

• For a single line of input, your program should produce identical output as does the Unix command:
  tr '\t' ' ' | tr -s ' ' | sed -e 's/<.*$//'
  See man tr and info sed for details. You can use this to verify the correctness of your code. Note that when you enter input for the above command, you will need to type Ctrl-D (after Return) before you will see any output.
• Do not store the complete input line in memory, rather process the input characters one by one.
• You should use the program echoline.mli, as presented in the lectures, as the starting point of your program.
• Make sure you have the preamble standard_preamble.mli at the beginning of your file filled out with your details. If you don't have the preamble in your file or if you have not filled in your details you will NOT get any marks!

Marking:

• Four (4) marks are awarded for correctness.
• Two (2) marks are awarded for a good, logical program structure.
• Two (2) marks are awarded if you have commented your program as explained above.

---

Part 2 - PeANUt Assembly Programming [32 marks]

Translate your C program shuffle.c from Assignment 1, Part 2 (as specified in there) into an equivalent PeANUt assembly program shuffle.ass. Alternately, you may use as a starting point the sample solution shuffle.c, in which case an attribution in the C code to the original author must be made!

For full marks, your program should contain a function to print the array (ideally, with any local variables should also be implemented on the stack). Your program should use the InOut function WriteInt() to print numbers in decimal, and WriteString() to print strings. It should also use the InOut function ReadCard() to read k etc. You will need to use the external directive in your code in order to do this.

Style:

In this part of the assignment you have to write a PeANUt assembly language program. This program should be set out with only one instruction (or macro call) per line and using your C code, plus additional comments as necessary (similar to the comments given in the examples in lectures and labs). All functions should be commented; non-trivial variable declarations should also be accompanied by a short comment.

You have to follow the procedure call convention as discussed in lectures and labs. Make sure you have the correct offsets (defined as concise macros) for input parameters and local variables. Quantities used to define data structure limits should be defined as a constant (concise macro) for both C and assembler programs.

Hints:

You may modify shuffle.c (as submitted for Assignment 1); in particular, it should be simplified if necessary (probably will need to be), and then debugged before translation. The latter might involve removal of any of the C library functions that do not have a PeANUt equivalent in InOut, and possibly removal of excessive internal functions. You might want to introduce temporary variables as well. You might also want to consider shortening long identifiers (see below).

Move all variable declarations to the top of main(). You may also want to explicitly translate for loops to while loops beforehand (see lecture C2, p7) - although rather verbose, this will make translation clearer. It may also be helpful to put opening and closing braces within control structures with a single line statement within (e.g. write `if (x < 0) x = -x;' as `if (x < 0) { x = -x; }'). A two-space indentation is recommended for the C code, as otherwise you will run out of room! It is advised to put the print vector function at the bottom of the program, as otherwise concise macro definitions might clash with address labels, e.g. n. Comparing or copying elements of 2 different array elements is a little tricky; copying one element to a temporary variable first will make it easier. In this case, the C program should be tested again before you translate it into assembler. The final C code should then be used to document the assembler.

The InOut.rel relocatable file is in /dept/dcs/comp2300/lib (see also lecture P8). Assemble and link your program using:

assemble shuffle.ass ; join shuffle.rel InOut.rel

Note that on the CS student system, you do not actually need to copy it to your working directory, as the join command will find it using the $PeANUtLib environment variable (which should point to /dept/dcs/comp2300/lib).

In your assembler code, don't omit the # when using immediate mode constants (e.g. use cmp #'\n', not cmp '\n'). Comparing the code displayed in the PeANUt tool with your original assembler may be useful when checking that the correct addressing mode was used, as well as macros have expanded properly. Keep your identifiers (including branch targets) reasonably short (only the first 7 characters are significant, and underscores are not allowed). When evaluating conditions, check that the correct branch instruction is used. If you suspect you have an infinite loop, commenting out backward branches/jumps may help in identifying which loop.

Strings need to be defined using the data directive (lecture P5, p10). The sensible use of macros is encouraged. In particular, defining a macro to call WriteStr, as this operation needs to be done a number of times. If you do a number of remainder calculations, this also could be expressed in a macro. When debugging other parts of your code, commenting out all calls to WriteStr may be helpful - and if this is done by a macro, you will only need to do this in one place! Note that lectures P6, P7 and P8 cover most aspects of arrays and functions that you will need.

Note that the PeANUt software does not handle Windows line termination conventions, so source files prepared on Windows may cause strange syntax errors when assembled. A remedy is to cut-and-paste the text into another file on a Linux system.

I suggest that you start implementing, testing and debugging shuffle.ass one step at a time. When you get to step 6, it may be easier at first not to implement the code in a separate procedure; if later making this into a procedure proves too problematic, it is better to leave it in the main program and repeat the section of code for printing the array.

When completed, shuffle.ass should give exactly the same output as (the reference version of) shuffle.c. Note that you should compare the programs' output on the command line as the Peanut tool can obscure some formatting errors, i.e.:

/dept/dcs/comp2300/public/ass1/shuffle
execute shuffle.img | cat -v

A pitfall that may be exposed at this stage is that a stray trap #3 instruction could be printing an `invisible' character such as a NUL (ASCII value of 0) that will not be evident when normally displayed on a terminal. Hence, in the above, piping the program's output to cat -v will indicate this. In any case, stray trap #3 instructions should not be in your code in the first place!

A stronger test is to redirect the output of each program into files, and compare those files using the sdiff command, as specified in Assignment 1. The previewAutoMark ass2 ... command will be made available for final testing.

Marking:

Your program will be marked for correctness / completeness. Marks will be deducted for poor style. To be more precise, 14 marks will be allocated for automated testing, 6 marks for the algorithm used (more precisely, the reflection of the algorithm used in the assembler code) and 12 marks for programming style.

---

Copyright | Disclaimer | Privacy | Contact ANU