mips memory management
how do you manually manage the heap in mips assembly, specifically the SPIM simulator?
the heap, i've found begins at 0x10040000 when using the sbrk syscall, e.g.
li $t0, 1
li $s0, 9
syscall
sw $t0, ($s0) # 1 located at 0x10040000
so, does a call to sbrk NOT guarantee that you will get back the next free memory slot? for instance, if i called sbrk for a single 4 byte space, SPIM might allocate addresses: 0x10040000-0x10040003. however, a second call for another 4 byte space might be unrelated to the prior 4 byte allocation? thus, a data structure is required to keep track of which memory slots have been allocated? finally, do memory managers try to reduce the number of calls to sbrk by determining free space that lies between the addresses that are tracked by the particular data structure?
Answer
On real systems, sbrk returns page-granularity allocations. I'm not sure if the SPIM simulator does (the meagre online docs imply it will return any byte-oriented granularity).
Generally, the sbrk system call just sets the "end-of-heap" pointer. All the underlying OS knows is the beginning of the heap (where sbrk started at the beginning of the program), and the current end-of-heap pointer. All the memory in that bound is considered (from the OS point of view) heap memory in use by the program.
(Note, in your case I believe the SPIM simulator takes an integer to bump the pointer by, so implicitly all the memory is contiguous and I think the break is always increasing?)
The "malloc" API that is generally built on sbrk provides more than a simple contiguous, growing memory region. A good malloc library generally lets you mark a region of memory as "free" (so it can be used to satisfy a subsequent malloc call). Note that OS generally doesn't know about this "free". Malloc keeps track of the memory that is free or not. In general malloc cannot return this arbitrary region of the heap to the OS, because the heap is a single contiguous region from the OS point of view.
Real malloc implementations have to deal with the mis-match between allocation requests and page-size (normal sbrk only returns multiples of page-aligned, page-sized allocations). Your simulator case doesn't have this problem because sbrk is fine-grained.
Note that tracking which memory is in use or not requires memory, so malloc has some overhead. Some implementations are designed to store most of this bookkeeping in the "free" memory (reducing the apparent cost to the client). There are lots of other strategies for matching malloc to sbrk.... (In your case mapping malloc to sbrk, and making free a no-op will 'work' as long as you don't allocate too much memory ...)
Here's an overview of how malloc and sbrk relate that draws some ASCII art I don't have the patience to transcribe: http://web.eecs.utk.edu/~huangj/cs360/360/notes/Malloc1/lecture.html