Assessed Exercise: Sigma 16 Assembly Language Programming
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 two’s complement integers in memory. The array is named X, and the elements are defined by a sequence of data statements. There is a two’s complement integer variable n, also defined by a data statement, which sets the size of the array. Thus X contains n elements X[0], X[1], …, X[n-1]. There are three other two’s complement variables, named possum, negcount, oddcount , and a single Boolean variable, overflow. These 4 variables should all be initialised to 0 in their DATA statements.
Write a program that will achieve as many of the following 4 aims as you can.
• Calculate the sum of all the elements of x that are positive (>0) and store this sum in the variable possum;
• Count the number of elements of X that are negative (<0) 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
• Detect if possum has overflowed and set overflow to 1 if it has (0 otherwise). In this case the value of possum will be incorrect but your program should continue, even if this is detected, to allow oddcount and negcount to be computed. Note that on adding 2 positive two's complement numbers, an overflow occurs if and only if the sum becomes negative. Also note that oddcount and negcount cannot overflow given the constraints on array size.
Note that since n is a 16-bit integer, the maximum size of the array is 32767 entries.
As a “developer 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.
Here, the final value of possum should be 3 + 27 + 101 + 50 + 0 + 19 + 6 + 4 = 210 ($00d2), the final value of negcount is 4 and the final value of oddcount also 4.
When you hand your program in it will be tested against some unseen arrays (customer acceptance tests) and its success in processing these will contribute to your grade.
A final (auxiliary) aim for your program is to occupy the minimum possible number of machine code locations.
How to proceed
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. (Tip: In the emulator, use single-step to track down any bugs.)
You should use your high-level algorithm as comments at the beginning of the program. You should also include a register use table in the comments at the beginning 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 in class (esp. Chapter 7) to see what comments should look like.
What to hand in
A fully commented assembly language source file in plaintext (.txt suffix) with the acceptance test data (DATA statements describing the developer test 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.
Do not submit your source file in anything other than plaintext. Do not, for example, submit it as a Word or PDF file.
How your exercise will be assessed.
Your program will get credit for each of the following.
Is the solution a reasonable attempt at the problem, e.g. does it have a suitable HLL description, an accurate register assignment table, a plausible structure and good commenting? You will get credit for these elements, even if your program does not assemble (or run).
Does it assemble? Note that the textfile you supply must assemble or no further testing will be attempted and your mark will be capped. You will always get some extra credit for ironing out syntax errors to the point of successful assembly, even if your program fails the developer acceptance test.
Does it run the developer acceptance test (note that this test does not require overflow to be correct so you will get full credit here even if you have not implemented this aim)?
Does it run the unseen acceptance tests? These tests will check for other issues, including overflow, loop correctness and so on?
Additional credit will be awarded on the basis of all of the above plus a close-to-optimal memory footprint (number of words of machine code used). Take your time to enhance code using your knowledge of Sigma 16 instructions but without compromising the functionality of your program. Passing the customer acceptance tests (where any array compatible with the specifications above could be used) is more important than minimising the code size. Typically passing the tests will earn you extra grades, whereas a really economical footprint will earn you a band or two within a grade (especially at A).