How to write a MIPS recursion program in descending and then ascending order - recursion

Question

I am trying to write a MIPS program that takes in user input (integer n) and then prints all the descending numbers until 1 and then all the ascending numbers up to n.
Basically if I input 3, the output would be : 3 2 1 1 2 3
In C#, the code would be:
using System;
public static class LearnRecursion
{
public static void Main()
{
int n;
Console.Write("Enter an integer: ");
n = Convert.ToInt32(Console.ReadLine());
RDemo(n);
}
public static void RDemo(int n)
{
if (n < 1)
{
return;
}
else
{
Console.Write("{0} ", n);
RDemo(n - 1);
Console.Write("{0} ", n);
return;
}
}
}
I have tried implementing the MIPS program like this:
.data
### Declare appropriate strings and the space character for I/O prompts ###
input: .asciiz "Enter an integer : "
space: .asciiz " "
newline: .asciiz "\n"
.text
main:
### call procedure for printing the user prompt ###
li $v0, 4
la $a0, input
syscall
#read input from user
li $v0, 5
syscall
move $s0, $v0 #store the user input into saved register
move $a0, $s0 #move saved user input integer as argument for RDemo
jal RDemo
j exit
# recursive RDemo method
# excpects integer argument (from user input) in $a0
#returns when n<1
RDemo:
#make space for 4 registers on the stack
addi $sp, $sp, -12
sw $ra, 0($sp) #return adress
sw $s0, 4($sp) #saved register (original n)
sw $a0, 8($sp) #argument (user parsed n)
#base case: n < 1 return
blez $a0, RDemoReturn
#print n
li $v0, 1
move $a0, $a0
syscall
la $a0, space
li $v0, 4
syscall
#call RDemo with n-1
addi $a0, $a0, -1
jal RDemo
li $v0, 1
move $a0, $s0 #$s0 or $a0 ?
syscall
la $a0, space
li $v0, 4
syscall
RDemoReturn:
lw $ra, 0($sp)
lw $s0, 4($sp)
lw $a0, 8($sp)
addi $sp, $sp, 12
jr $ra
exit:
li $v0, 10
syscall
It ends up printing an endless loop, with only the original integer n, and then a bunch of numbers that look like adresses i.e 24567 etc.
Does anyone know what is wrong with my program?

Answer 1

That code is making several calling convention related mistakes.  In particular, it goes to who owns what register and when.
During single step debugging, you'll notice these mistakes as bad values in registers, but perhaps don't understand what the right way should be.
The function prologue saves away $s0, $a0 and $ra.  One of $s0 and $a0 is unnecessary, but neither is being used properly.
public static void RDemo(int n)
{
...
syscall to print n;
syscall to print space
RDemo(n - 1);
syscall to print n;
syscall to print space
}
Let's analyze n, which comes to the top of RDemo in $a0 as per the calling convention.  That register is ok to use for the first syscall to print number n, however, as #Jim points out above, printing the space repurposes $a0 as pointer to text to print, and in doing so wipes out $a0, and so the value of n is ~lost, at least from $a0.
It is necessary for n to survive the printing of the space — and let's note that the function prologue did store n (from $a0) into the stack, which will have survived the syscall to print the space.  So the simplest thing is to reload it from that stack location, after the printing of the space, and before computing n-1 for the recursive call.
lw $a0, 8($sp)
You'll find that the recursive call also clobbers $a0, by passing n-1 in $a0, so you'll need this lw before using n again after the recursive call.  (It might be tempting to add 1 to $a0 to restore its original value, but that would require the callee to preserve its argument register, and that isn't part of the calling convention, i.e. it is a violation of the calling convention.)
In this scenario, $s0, is wholly unnecessary and goes unused, so no need to save and restore it in prologue/epilogue.
Also, while it is necessary to save $a0 in prologue, it is unnecessary to restore it in epilogue: that, $a0, is RDemo's parameter, which, by definition of the calling convention, belongs to this invocation/activation of RDemo and not its caller — restoring upon exit is a benefit to the caller, but not in the case of parameters as these are given to the callee to do with as they please, and callers (should) have no expectation of receiving back the value they provided — this meets the definition the scratch register set, aka call clobbered (and sometimes poorly labeled as caller saves).
As an alternative scenario, we can use the call-preserved register, e.g. $s0 to hold n live across syscalls and other calls.  In this case, n found in $a0 upon function entry, should be copied into $s0, as part of function prologue (but after saving $s0 to the stack so $s0's original value can be restored upon exit).
From there on, whenever the code needs n, it can be found in $s0 (because you put it there).  So, if/when you want it back in $a0, for example, then use move $a0, $s0.
The prologue in this scenario should save the incoming $s0, and restore it in epilogue, but there's no need to save (or restore) $a0.
I'd like to point out that everything of the above discussion applies whether a call is recursive or simply calling an alternate routine, say RDemo calls RDemo2, which calls RDemo3...  Recursion may be hard to follow, but we use the same rules (the rules of the calling convention) just as with any function calling, in other words, recursion adds no additional rules.
Of course, when writing small toy programs we can always invent our own calling convention.  Compilers will sometimes do this when they know internal details of callers and callees.  However, if you're goal is to learn about (1) a standard calling convention, (2) the difference between call preserved and call clobbered registers, then follow the logic and analysis above.
The analysis we need to properly allocate variables and temporaries to the right kind of registers (call-clobbered vs. call-preserved) is a form of live-variable analysis.
In particular, we're looking to see if a variable is live across a function call.  More technically, this analysis looks to match definitions of variables (assignments to that variable) with uses of that variable (consulting the value of the variable) and if some usage is after a call when a reaching definition is before a call, then that variable is live across a (function) call.
When a variable is not live across a function call then we can freely use the scratch/call-clobbered registers, and they are preferred for such variables since they have less prologue and epilogue overhead than call-preserved registers.
However, if a variable is live across a call, then it has special requirements, namely that its value needs to be in function-call-preserved storage, which is either in a call-preserved register, or local stack memory.  Making a good choice between a call-preserved register and local stack memory has to do with the actual usage of that variable.
A call-preserved register adds overhead both prologue and epilogue since its original value must be returned to the caller; however, using local stack space has, at minimum the overhead of initialization.
Often when a variable is used within looping statements that involve function calls, a call-preserved register is better choice than stack, and vice versa: when the variable is not used within looping statements local stack memory is better.
Complete analysis depends though circumstances that do vary based on the actual code involved and of a particular dynamic workload, so we can count instruction and stalls (static and/or dynamic approximation) to compare the two approaches for a given variable.  Compilers do this type of analysis to make their storage choices.