Machine Problem 7, due at the end of Nov 17

Top Level Specification: Do MP6. Actually make it work. There is no change in specification. Performance on MP6 was so bad that everyone is being given a chance to improve. In order to give fast feedback, we only glanced at code in grading MP6. Our focus was on testing.

There will be no weekly quiz this week so you can devote that time to MP6.

R3 are locally available between calls to functions.

Grading:

See MP6.

Submission: To submit your work, it must be in a file named mp7.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 mp7.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.

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

Nov. 14, 3:00 PM

Common problems seen on MP6:

• Violation of the standard Hawk calling conventions. Please reread the section on Calling Sequences in Chapter 6. Particularly, note this quotation:

  If the calling routine has anything of value in R3 to R7, it should save it before the call and restore it after return. The caller may use these registers with impunity. It is up to the called routine to return with R8 to R15 unchanged, so if these registers are needed by a subroutine, they should be saved before use and restored afterward. Any time a subroutine needs to save and restore the value in some register, it will need a local variable for this.

  Our test script checks that you conform to these rules.

• Incorrect thresholds for detecting overflow (returning #80000000) and underflow (returning 0). The value 2.0E9 should convert to 2000000000 exactly, and not an overflow. Actually, you can go higher, but 3.0E9 is an overflow. 1.0E0 should convert to 1!

• Several students omitted the INT FTOINT label or included that but failed to define the label FTOINT. Do not make that mistake, it makes your code untestable.

• Several students left debug output in their code, things like calls to PUTDEC. Please clean these out! They make output from any test main program very hard to interpret.

• A few students were distracted by the MYFLOAT floating-point format in Chapter 11. The concepts demonstrated there are relevant, but the code given there is irrelevant, and attempting to use it is not constructive.

• Many students obviously made no effor to test their code! Just because a test program is not part of the submission does not mean you are exempt from writing one. We have covered Chapter 10, you can easily follow that to make a separate main program that you can linked to your code to test it.

• There is no excuse for turning in code with assembly errors. By this point, you have had ample opportunity to learn how to write code that assembles correctly.

• There are still students attempting collaborative programming efforts. These efforts have been destructive, producing non-functional code, and as was discussed on the first day of class, you are required to do your own work. The rule suggested then was "please talk to and learn from each other, but do not take notes from collaborative study sessions to use in preparing your solutions."

• A few students have had remarkable experiences with Chat GPT. The most noteworthy thing I've seen is evidence of Chat GPT hallucinations. Google the term, it's a real thing, and these hallucinations really destroy its ability to produce useful code. Basically, what Chat GPT does is invent plausible instructions that would solve some problem if they were there. This is a very natual consequence of the way Chat GPT works.