Hi Daniweb,
I'm new to Assembly level programming and have been given an assignment in MIPS. Having started to plan the assignment, I have come to a rather open ended question that I want your opinion on: given that one has only so many registers to work with on Assembly level, how does one use these efficiently? For example, my assignment requires 4 registers to hold numbers, 4 more registers to hold addresses to arrays, and will probably need more later. And this is just my assignment, I'm sure many assembly programmers have faced a situation in which they have far too many variables to keep track off, and too few registers to work with. So what is best strategy for utilizing registers in MIPS? And in MASM I believe it would be even tricker, given that a lot of the registers have to be used as parameters for Interrupt functions.
Please discuss this,

This is something of a difficult question to give a fixed answer for, as the efficiency of 'register painting' (as it is called by compiler writers) depends largely on the context of the program. One thing I will mention is that MIPS makes it a lot easier in general, simply because of the number of general registers (32, though some are reserved for the assembler and the kernel). With only 12 general registers even in long mode (rax, rbx, rcx, rdx, and r8-r15) and several register-specific operations even with those, the register space on the x86-64 is still quite cramped compared to most other modern architectures. It is virtually impossible to write a significant function in x86 assembly without 'spilling' some data into memory.

While this won't answer your question, you might want to read this post, as it may help put the issue into perspective. One important point from that to repeat is that RISC systems were designed to make compiled code more efficient; ironically, this also made writing assembly code easier for novices. The x86, a CISC design, is actually much harder to program effectively in general, both in assembly language and in high-level languages.

This article has been dead for over six months. Start a new discussion instead.