With the MARS simulator (yes, I know "simulator" is redundant and I'll fix it as soon as people stop referring to ATM machines and PIN numbers), .align 4
will set the alignment to a multiple of sixteen (24
). For example, it will ensure that Table
will be on a sixteen-byte boundary like 0000
, 4110
, or fff0
. Alignment is usually because some CPUs work faster if n
-byte data elements are aligned on an n
-byte boundary (some will even raise a hardware exception if alignment is violated) but I'm not sure that's the case here since an alignment of sixteen is pretty "wide".
.space 24
simply allocates twenty-four bytes of space, in this case to hold the Table
data structure.
It appears that your initial loop (inputting the data) has a limit of six entries, based on the interaction between $s0
and $t0
.
The instruction sequence:
slt $t1,$s0,$t0
beq $t1,$zero,in
will branch back to in
as long as $s0
(= 5
) is less than $t0
, so $t0
iterates from 0
to 5
inclusive (six items).
That limit is how you would decide how much space to allocate (six 32-bit values would be twenty-four bytes).
And that loop will work. You state that:
bge $t0,$t1,loop1
: This is NEVER going to be true unless$t0
is incremented?
but, in fact, that's not quite right, it could also become true if you decrement $t1
and, lo and behold, there it is on the third code (non-':'
) line below:
loop2:
bge $t0,$t1,loop1 #j < = i
:
addi $t1,$t1,-1 #j--
:
j loop2
Thinking in terms of pseudo-code, it's the same as these two loops (in terms of how many iterations are done):
limit = 10, value = 0 limit = 10, value = 0
while value < limit: while value < limit:
value = value + 1 limit = limit - 1