Question

I read in MIPS tutorial, that only reginsters $s0-$s7 are preserved across procedure calls.
But I think (maby I am wrong?) that it is not elegant to create procedures that have side effects – I think procedures should change only $v0, $v1 reginsters and stack if it is needed (am I right?).
So in my opinion inside my procedure I can use only $t0-$t9 reginsters.
But when I call some prodedures in my procedure it can change $t0-$t9 reginsters. So I have to store temporary reginsters and restore it after procedure call in my procedure. But when my procedure looks like following:

call procedure1
compute something on temporary reginsters

call procedure2
compute something on temporary reginsters

call procedure3
compute something on temporary reginsters

...

my procedure needs a lot of memory accesses.
So my idea is to use:

Store at the begining of my procedure reginsters $s0-$s7.
Use reginsters $s0-$s7 in my procedure.
Restore old values of reginsters $s0-$s7.

Is it elegant and has it any bad consequences?

Answer 1

I read in MIPS tutorial, that only reginsters $s0-$s7 are preserved across procedure calls.

Nothing magical happens to $s0–$s7 across a call (e.g. jal some_routine just sticks the return address in $ra and jumps to some_routine; nothing else happens).

The preservation of these registers across a call is just a convention: it’s part of the standard “Application Binary Interface” (ABI), which is a set of conventions covering register usage, stack usage, data formats etc. — different bits of code (applications, libraries, etc.) which conform to the same ABI will interoperate with each other.

If you want your code to be callable from elsewhere, your code needs to conform to the ABI expected by the caller. e.g. if you’re writing some assembly routine that needs to be called from C code, you’ll need to conform to the ABI used by the code that the C compiler generates.

For the usual MIPS ABI, this means that the code which calls your routine will assume that whatever values it has put in $s0 – $s7 before the call will still be there after the call returns, but it will not assume that the contents of $t0 – $t9 are still the same. (Similarly, if your code calls out to library routines (for example), it can make the same assumptions: after the call returns, anything that was in $s0 – $s7 has been preserved, but $t0 – $t9 may contain anything.)

That means your code must save any of $s0 – $s7 before changing them, and restore them before returning. What it does between saving and restoring them doesn’t matter — all that matters is that the caller does not see any change.

So, yes, your idea is correct (and indeed the sensible thing to do here).

(Note that your sub-procedures (procedure1, prodcedure2 etc.) do not necessarily have to conform to this standard ABI, if they are only ever called from your main procedure, and don’t call out to external routines — because, in that case, they only need to interoperate with your main procedure, not with any other code. But it is a good idea to follow the ABI anyway, unless there is a very good reason not to; it makes it easier to read the code, easier to make one of the internal procedures more public later on if necessary, easier to add calls to other code, etc.)