Machine Problem 3, due at the end of Oct 9

Framework: Your program must begin as follows:

	TITLE	"mp3.a by YOUR NAME HERE"
	USE	"hawk.h"
	USE	"stdio.h"

Top Level Specification: Your program should output the first 15 numbers in the tribonacci sequence, using a recursive function. This means that you will need to write a main program that calls your function 15 times.

In addition to outputting the values of the numbers, you should output the number of additions required by your recursive function to compute the numbers. Omit additions that are not part of the computing the tribonacci value. So, additions involved in loop control, stack manipulation etc are not involved.

Ouput the number of additions required for each number after each number, separated from that number by a colon. Commas should separate each result from the next. So, the sequence will begin:

0:0,0:0,1:0,1:2

The first three numbers are 0, 0, 1, and it takes no additions to compute these because they are part of the basis for the recursion. The 4^th tribonacci number took 2 additions to add the three preceeding numbers.

Your program must be written in SMAL Hawk assembly language, and it it must be formatted so that it does not trigger warnings when you run

   [HawkID@fastx?? ~]$ ~dwjones/format mp3.a

Brief commentary: There is an example of recursive code to compute Fibonacci numbers in Chapter 6, and that example is clearly relevant, but it doesn't count how many additions it does, and it is missing a main program. If you start with that code, expect to make several significant changes!

There are at least two ways to count the additions. One is to make each function call return both a tribonacci number (perhaps in R3) and an addition count (perhaps in R4). The other is to use a global variable to count the additions. Zero that variable before each call to the tribonacci routine from the main program then output the value after the call.

Again, solving this problem in a higher level language like C is a good idea before trying to do it in assembly language.

Grading: 5 points. Correct output is worth 2.5 points. The remaining credit will be offered only for those who have reasonably correct output.

Code that does not assemble will not earn any credit.

Stylistically clean code is important; that is why half the credit is reserved for style, but only if the code works. Bad indenting will be penalized up to 1 point from the 2.5 style points. Excessive or inadequate white space within and between lines will be penalized, again, up to 1 point. Excessive or inadequate comments will be judged similarly.

Note: Comments should not repeat the assignment. Assume that the reader of your code has read the assignment. Assume that the reader knows how to program. Using C code as commentary on assembly code is quite appropriate, so long as additional comments are added where the C code needs comments.

Submission: To submit your work, it must be in a file named mp3.a in your current directory on the CLAS Linux system, and you must know your section number. In the following, what you type is shown in bold face. Begin at the linux command-line prompt:

   [HawkID@fastx?? ~]$ ~dwjones/submit 0A0X mp3.a

Note: The ~dwjones must be verbatim, do not substitute another name. Also, use your section number (one of 0A01 to 0A05).

The submission script will copy your code and, after the copy is made, it will output a message saying "successful submission." You may resubmit as many times as you want; each time you resubmit, your previous submission of that file will be replaced, so we will only see your final submission. The completed dialogue on your screen will look like this when you are done:

In the event of insurmountable trouble, do not delete or edit files you have submitted until the graded work is returned. The operating system record of the last edit time and date and the backups maintained by the operating system are proof of what you did and when, and they allow us to investigate what happened. until your graded work is returned. This way, the time stamp marking the time of last edit is a trustworthy indicator of whether you did the work on time.

Discussion

Oct. 9, 3:15 AM

Numerous people showed me their code (or fragments of their code) during office hours. I saw the following issues over and over again.

• Badly commented code. People said things like: "I'll write comments later, after I get the code to work."

  That doesn't work. If I see uncommented code, I can't tell what the programmer thought they were doing. Furthermore, the effort to try to make well structured comments can force programmers to see their mistakes, and it can force rewrites of the code to make the structure clearer.

• Blending of the main program and the tribonacci function.

  If you were writing Java or Python or C code, you wouldn't blend your different methods, functions or subroutines. Those languages force each routine to be clearly distinct. Assembly languages don't do that, you really can blend your routines, so some bit of code serves some purpose in both the main program and some other function. Just because you can do this doesn't mean you should. Such blending should be considered an advanced optimization technique.

• Forgetting return sequences.

  I've seen numerous examples of code where the return sequence was left off of the main program, so after the program ended, control fell through into the tibonacci function. Or, if the tribonacci function came first, it fell through into the main program when it was done instead of returning.

  It is worth following this simple rule: Every function should have just one entry point, with a receiving sequence, and one exit point, with a return sequence. Yes, languages like C let you have multiple returns from a function, but at the assembly language level, debuggin is easier if all paths from each receiving sequence lead to the same return sequence.

• Mixing up addresses and values

  If you get a value like 65627 when you expected 5, suspect that you are printing out the address of a variable and not its value.

Oct. 9, 4:36 AM

Would you know how so many redundant spaces are printed?