Rules for Assembly Language Programming
Scott D. Anderson

This handout was made up based on actual errors done by students. Now that you have been warned about them, I expect that you will never again make these errors. There will be big deductions if you do, so use this as a checklist, to ensure that your programs are properly written.

The purpose of theses rules is to make your programs clearer, better organized, and more efficient. They aren't just arbitrary rules that I made up to make your lives more difficult. I have tried to justify the rules, but if you're puzzled about why a rule exists, please ask.

Many of these forbidden situations will never arise if you code your program from a proper outline, such as a flowchart or C++ code.

Things Forbidden by Modularity

The following taboo things are ruled out by proper modularity. See the handout on modularity.

• Instructions that jump or branch should stay within the subroutine that contains the instruction. In other words, never branch or jump to a label that is not part of your subroutine. You should be able to draw a box around any subroutine and no branches or jumps should cross the boundary. See the other handout on modularity.
• Subroutines are entered using the ``Jump and Link'' instruction--always and only. Never jump or branch to a subroutine. If you jump or branch to something, it's not a subroutine.
• Subroutines must finish and return to their caller using the ``Jump Register'' instruction (jr $ra). Never jump or branch to any instruction outside the subroutine. (See rules above).
• Subroutines must never exit the program. This rule is a variation of rules you learned in C++ and when we discussed modularity. Subroutines should always return to their caller, and only main should exit the program, by returning to its caller (the operating system).
• Use A0 for the first argument, A1 for the second argument, and so forth. This will sometimes be annoying and awkward. You'll think it'll be easier to use A1 and A2 or T0 and T1, but you may not. The reason for this rule is because MIPS has an established convention for how subroutines are called. If someone else wants to call your subroutine, he or she will put the arguments in A0, A1 and so forth. If your subroutine uses different ones, it won't work.
• Use V0 for the first value and V1 for the second value. Again, this is part of the MIPS calling convention, which we will all abide by.
• Subroutines should be entered at the first instruction. If the subroutine is named GCD, the first instruction should be labeled ``GCD'' and the caller should call the subroutine with jal GCD.
• The lines of a subroutine should be contiguous, meaning that no other subroutine can intervene. If we draw a box around the instructions of our subroutines, those boxes must not overlap or contain each other. For this purpose, main is just another subroutine.

Other Forbidden Things

The following lists things that your program should never do under any circumstance.

• Never jump to the next instruction. For example, consider the following:

          syscall
          j label
  label:  move $a0 $v0
  

  The processor will execute the first instruction (the syscall), then execute second instruction (the jump), then execute the third instruction (the move). Imagine if that jump instruction weren't there:

          syscall
  label:  move $a0 $v0
  

  The processor executes the syscall and then the move instruction. In other words, you get exactly the same results. So, the jump instruction is just a waste of time. It's also confusing, because the reader expects to go someplace else.
• Never label an instruction if there is no jump or branch to it. For example, if we remove the jump instruction above, there may be nothing else in the program that jumps or branches to ``label,'' in which case the label should be removed. This is because the reader expects that any labeled instruction will be jumped/branched to, and it's confusing when it isn't.
• Push or pop the correct number of values onto or from the stack. If you're pushing one thing, don't decrement the stack by 8, since that is enough space for two things. If you don't allow enough space, your program may fail. If you allow too much space, you're being wasteful. Either way, you're showing that you don't understand how to use the stack.
• Don't included unreachable code. Code gets executed either by being jumped or branched to or by being the next instruction after a non-branching instruction, so that the program ``falls through'' to the given instruction. However, consider the following code:

         j somewhere
         move $a0 $a1
  

  How is that move instruction ever going to get executed? In fact, it can never be executed, because it can't be jumped to, and the previous instruction will always jump away. The result is code that can never run, which is a waste.
• Never test for something and its negation. For example, the following C++ code is silly:

     if( x == y )
        <something>
     else if ( x != y )
        <something else>
     ...
  

  If x isn't equal to y, so that the <something> doesn't get executed, then it's pointless and wasteful to check if they are not equal-they must be! Never do that in your C++ code; never, ever.

  Similarly, in MIPS assembly language, consider the following code:

       beq  $a0 $a1 then
       bneq $a0 $a1 else
       move $v0 $v1
  

  Under what circumstances could the program not branch on both instructions, thereby getting to the move instruction? It can't. One or the other of those branch instructions must be true. In other words, the above code is equivalent to the following:

       beq  $a0 $a1 then
       j else
       move $v0 $v1
  

  Now we see that the move instruction is unreachable. The code needs more rewriting before it makes sense.
• All registers must be initialized before they are used, except RA (which is initialized by the jal instruction) or register zero, which is always zero. Your code should never assume a register has any particular value unless earlier code created those conditions.
• Never jump to a jump instruction. For example:

       j end
       ...
  end: j loop
  

  Just jump to the next piece of working code. Can you imagine looking up ``foo'' in a dictionary, and it says ``see `bar''' and when you look up ``bar,'' it says ``see `quux.''' You'd be pretty peeved about bouncing around the dictionary like that. Similarly, the reader of your code will be unhappy. It's also a waste of execution time: executing two jump instructions when one will do.
• Use pseudo-instructions consistently. For example, the move pseudo-instruction expands into an instruction that adds zero to the source register and stores the result in the destination. So, what's going on with the following code?

       move $t0 $a0
       add $a0 $a1 $zero
       move $a1 $t0
  

  This code was actually submitted by a student. Presumably, she knew about the move instruction on the first line, forgot about it on the second, and remembered it on the third. In other words, the above code is evidence of either temporary amnesia or temporary insanity. In other cases, a student uses move in one part of the program, but not in another. The pseudo-instructions are clearer and easier to understand, so use them

Things to Avoid

• An slt instruction should be followed by the beq or bne that references it. For example, don't do the following:

         slt $t0 $a0 $a1
         move $v0 $v1
         beq $t0 $0 foo
  

  Why not just do it like this:

         move $v0 $v1
         slt $t0 $a0 $a1
         beq $t0 $0 foo
  

  The only reason I can think of for wanting to do this is if the value needs to be stored, calculated with, or something else before the comparison is made. It's hard to thing of a good example, so avoid this.
• Omit commented out code unless there's a really good reason (documented) for leaving it in. I don't want to wade through your mistakes and misteps.