辅导Name Systems、讲解Python, C/C++程序设计、辅导Networks留学生

Assessed Coursework

Course Name Systems and Networks

Coursework Number 1

Deadline Time: 4:30pm Date: 23rd Nov 2018

% Contribution to final

course mark

20 This should take this

many hours:

<10

Solo or Group Solo Group

Submission Instructions

See “What to Hand in” on Page 4.

Who Will Mark This Lecturer Tutor Other

Feedback Type Written Oral Both

Individual or Generic Generic Individual Both

Other Feedback Notes

Discussion in Class Yes No ?

Please Note: This Coursework cannot be Re-Done

Code of Assessment Rules for Coursework Submission

Deadlines for the submission of coursework which is to be formally assessed will be published in course documentation, and work which is submitted later than

the deadline will be subject to penalty as set out below. The primary grade and secondary band awarded for coursework which is submitted after the published

deadline will be calculated as follows:

(i) in respect of work submitted not more than five working days after the deadline

a. the work will be assessed in the usual way;

b. the primary grade and secondary band so determined will then be reduced by two secondary bands for each working day (or part of a

working day) the work was submitted late.

(ii) work submitted more than five working days after the deadline will be awarded Grade H.

Penalties for late submission of coursework will not be imposed if good cause is established for the late submission. You should submit documents supporting

good cause via MyCampus.

Penalty for non-adherence to Submission Instructions is 2 bands

You must complete an “Own Work” form via

https://webapps.dcs.gla.ac.uk/ETHICS for all coursework

UNLESS submitted via Moodle

Marking Criteria

The exercise is worth 20%

Marks will be awarded for:

commenting;

correct code;

efficient code;

accurate status report;

accurate assessment of limitations.

Marks will be lost for:

inadequate or inaccurate commenting;

commenting that does not add value (see below);

code errors;

code inefficiency (unnecessary instructions, clumsy program flow etc.);

inaccurate or missing status report;

inaccurate or missing assessment of limitations (as part of status report);

code that is badly laid out (e.g. lines overflowing page width).

Commenting should include:

a title and brief description in words;

a high-level description of your algorithm (e.g. in Java or pseudo-code);

a register assignment table (what will each register be used for?);

an introductory comment for each logical block of code;

a comment on most lines.

Note that comments on lines should relate the code back to the high-level and not just

describe the instruction. E.g.

ADD R1,R2,R3 ; R1 = R2 + R3

is a poor value comment, whereas

ADD R1,R2,R3 ; z = x + y

is much better.

Assessed Exercise: Sigma 16 Assembly Language Programming

Handout: 5th November 2018

Introduction

This exercise will give you some experience in developing and testing an assembly language program. You

will begin by writing an algorithm in a high-level language to solve the problem; then you will translate the

algorithm to Sigma16 assembly language and test it using the Sigma16-0.1.7 assembler and emulator.

The problem

Suppose there is an array of integers in memory. The array is named x, and the elements are defined by a

sequence of data statements. There is an integer variable n, also defined by a data statement, and the array X

contains n elements X[0], X[1], ..., X[n-1]. There are three other variables named possum, negcount and

oddcount. Write a program that will:

Calculate the sum of all the elements of x that are nonnegative (>=0) and store this sum in the

variable possum, and

Count the number of elements of X that are negative and store this count in the variable negcount.

Count the number of positive elements of X that are odd numbers and store this count in the variable

oddcount. Note that an odd number is one that does not divide exactly by 2 and so has a least

significant bit of 1.

As an “acceptance test” use DATA statements to give n the initial value 12, and define the following values

for x: 3, -6, 27, 101, 50, 0, -20, -21, 19, 6, 4, -10. Thus, the final value of possum should be 3 + 27 + 101 +

50 + 0 + 19 + 6 + 4 = 210 ($00d2), the final value of negcount should be 4 and the final value of oddcount

should also be 4.

Now test your program out with other arrays and explore any limitations it may have. Summarise your

findings in the Status Report (see What to hand in, Item 2)

How to proceed

See Moodle for instructions on how to launch the software. Before entering your own program, start by

working through an example program (e.g. File: Open, click examples, then open Add.asm.txt.) Develop

your program using the approach illustrated in lectures:

(1) write the algorithm in high level notation (using assignments, ifs, for loops etc.),

(2) check that your high-level algorithm is correct,

(3) translate your algorithm to assembly language,

(4) enter the assembly language into a file, and

(5) test it with the assembler and emulator.

You should use your high-level algorithm as comments at the beginning of the program, and each line of

assembly language code should have a comment explaining what the instruction does in the context of the

program. Look at the examples given to see what comments should look like.

What to hand in

Hand in a report 2-3 pages in length, printed on paper, at the IT Systems & Networks pigeonhole outside the

Teaching Office. Please staple the pages in the upper left-hand corner, and don’t put the report in a

folder of any kind.

1. Title (on first page). State that this is Systems & Networks 2018 Assessed Exercise, give your name

and matriculation number, and the date.

2. A short status report (on first page). This is not documentation about your program; it is merely a

statement of the status of your hand-in. Did you finish the assignment? If not, which parts did you

do? Does your program work correctly? If so, what evidence do you have that it works? What are

your program’s limitations and why? Does it work for all arrays and all numbers?

Are there known bugs in the program? If so, what is the evidence for these bugs, and do you have

any ideas about how to fix them? Just as in the “real world”, it is better to say that you have a bug in

a program than to claim falsely that it works correctly.

Note that a bug is different from a limitation. A limitation is a planned out-of-range scenario where

your program will never produce correct answers (e.g. due to code limitations, overflows etc); a bug

is an unplanned scenario where your program should work but does not (i.e. a coding error).

The status report should be no more than a half page long. The last part of the first page should be

left blank for feedback.

3. On second (and third page if necessary) The assembly language source file with acceptance test data

(the DATA statements describing the array mentioned above) included.

Do not use inter-line spacing (e.g. 1.5× or 2× spacing) on consecutive lines of code.

Do use blank lines and full-line comments to separate sections of code.

Format code for readability: use a smaller font if necessary to prevent lines overflowing the

page width.

4. In addition, email your source file (item 3 above) as a plaintext attachment that can be assembled

by the Sigma16 system to Lewis.Mackenzie@glasgow.ac.uk. This should not be a Word or PDF

file. The Subject field of your email should read “Systems and Networks 2018 Assessed Exercise”.

This will allow your program to be tested to verify that it works. You must do this before the

exercise deadline.

5. Please adhere to submission guidelines exactly as outlined above. Bands will be lost for failing to

do so