My office phone number is 496-6246 (8am-5pm), and my home phone number is 643-9644 (6pm-10pm). Please do not call me after 10pm, or before 10am on weekends.
By far the best way to reach me (or anyone on the course staff) is via email. My email address is ellard@deas. The email address of the course account is lib50@fas.
email is also the easiest way for me to get information to you. Please check your mail at once a day or so.
Professor Kernighan has made several remarks about how unpleasant assembly programming can be, and in the general case he is right- it's not something that you want to do forever. However, it can be an interesting thing to do, and a lot of fun in the short run (sort of like camping is something that people enjoy doing on the weekends, but not many people want to live their lives in a tent).
For this assignment, we give you the precise algorithms for the code you need to write, so this shouldn't be a problem. You may find it useful to modify these algorithms slightly, in order to express them in ANT, but make sure that you have the basic ideas totally nailed down before diving into the code.
If you can't precisely specify what it is that your algorithm is supposed to do and how to do it, then there's little chance you'll get it right be tinkering with it in assembly language. Since the beginning of the semester, you have been learning how to express algorithms precisely by writing them in C. Use this experience!
Note that the most appropriate or elegant algorithms in C may not be the most appropriate or elegant algorithms in ANT. Think about what's going to be easiest to express in ANT; it may change your algorithm.
If you don't know how to express yourself in ANT, then even the best algorithm is doomed to failure.
Eventually, each piece of the algorithm should start to look like something that you can easily convert into a sequence of ANT instructions and/or data declarations.
Do this before you write any code, and once you start to write code be very reluctant to change the register allocations without good reason! If you change the meaning of a register in one part of your code, you may need to change many other parts of your code in order to avoid clobbering something else.
Write small pieces that you can check and test carefully. An example of this in included later in this handout.
Make use of the ANT debugger (ad) to test your code. You can execute your code line by line, checking to make sure that what is in the registers and data memory is what you expect after each step.
ANT comes with a decent debugger. Learn your way around it! You will not be able to debug your programs by staring at them- most people find the debugger invaluable (the rest find ANT programming impossible, because they can't find their bugs without using the debugger).
The debugger takes five minutes to learn and can save you hours.
Make sure you keep track of what each scratch file is used for (i.e. what idea you were experimenting with in it) so you can pick out the good stuff later. There's no reason why the programs you need to write for this assignment should be the only ANT programs you ever write!
/* Address calculation in assembler: */ /* NOTE: this is different from address */ /* calculation in C! */ &A [x] == &A  + (x * sizeof (each element of A));
In ANT, this all greatly simplified by the fact that the size of each element (at least for arrays of bytes, which are all you need to worry about for this assignment) is exactly one. Therefore, this reduces to the following more C-like expression:
&A [x] == &A  + x; /* or just */ &A [x] == A + x;
So, let's imagine that you need to get at the nth element of A, where the address of the first element of A is stored in r2 and n is stored in r3, and put it into r4.
lc r2, $A # r2 = &A ; ld r4, r2, r3 # r4 = A [x];
There are a few examples of strolling through arrays in the code we offer as examples: reverse.asm is pretty clear, and of course there is always the silly bigadd.asm.
Some guidelines that you might find useful:
This will familiarize you with how the machine works, and should give you ideas of how to proceed. Once you are familiar with using the instructions, when it comes time to implement the same instructions yourself, you'll already know what they're supposed to do.
I can't stress this enough.
Read the assignment, then ant_design.txt and ant.txt cover to cover. We've provided a lot of code for you, and also a lot of documentation. The amount of code that you have to write for this assignment is actually relatively small- but if you don't understand what you're supposed to do and what we've done for you, it could seem like mountains of code.
Read the documentation early, so that if you are confused by some part of it, you can ask questions early (long before the assignment is due) and get a clear understanding of things before you go on to the next step.
The design should be simple. Don't "over-engineer" the design; just do something simple that works. I promise you that there are a variety of approaches, all simple (and of course some difficult ones as well). Simple is always better.
Don't leave the design questions until after you have finished coding! Looking at them first might give you ideas about how to do the coding- and doing the coding with them in mind will help you to find answers to them.
This is more of a general rule than a guideline specific to this assignment, but it is especially easy to do here. After you implement each instruction, write a tiny program (or use one of the ones we supply) to test whether it works.
If you start with the sys instruction (and particularly the dump syscall), that will make this even easier.
We've provided a test facility called test-ant that does a decent test to see whether your ant matches the spec. It's not a perfect test (and can't test every tiny detail) but if your ant passes all the tests, it's not bad.
The test is constantly being refined; keep your eyes peeled for improvements.
Dan Ellard - (firstname.lastname@example.org)