Log In

Dynamic Memory Allocation Mips Code

Verbal Description of the Project (Dynamic Memory Allocation)

Most modern programming such as C, C++, and Java have a facility to request memory of any size (sufficient for storing the data of a structure or object) from the operating system dynamically at execution time using system calls e.g., malloc or new. The Operating System allocates the requested amount memory from a pool, and restores it back to the pool, when the user program returns the earlier requested memory using system calls e.g. dealloc or free. You may note that this type of memory allocation is different from static allocation at compile time for different fixed size data structures such as arrays.

In this project, you need to write MIPS code for dynamic allocation of memory. In other words, you need to write a main program that keeps on waiting in a loop for user’s request through console for allocation/deallocation of memory of a size for a variable with a name, and calls an allocation or a deallocation procedure accordingly. The allocation procedure allocates an available chunk (that is, a chunk not allocated to another variable) of memory, and updates it table to indicate which portions of its memory are allocated to which variables, and which portions of memory are still available. When the main program requests the deallocation procedure to free a portion of memory allocated to a variable, the procedure will mark those portions of the memory earlier allocated this variable as free. The allocation and deallocation requests may come from the user in any order, and a possible complication your project needs to handle is the situation where there may not be enough contiguous memory to handle an allocation request through the total free memory areas total up to a value higher than the requested amount. For easier design and test of your project, you may make the following simplifying assumptions:

  1. The pool of memory is very limited, say 2048 bytes.
  2. The pool is partitioned into small chunks of equal size (say, 32 bytes each so that in a pool of 2048 bytes there will 64 chunks).
  3. Though memory requests could come for any size, allocation is always done in the integral number of chunks. That is, if a request for 100 bytes comes, 128 bytes (or 4 chunks) are allocated.

Ideas for Design: You need to have a symbol table or a mapping of memory variables and the range of the numbers of the chunks allocated. You also need a free/available table or a Boolean array of the size of the total chunks in your dynamic memory; allocated chunks needs to be ticked (marked with 1), and the free slots need to be marked as zero. Initially, all slots are marked as zero.

After a series of “allocate” and “deallocate” requests, the free areas may not be contiguous in the sense that they may have memory area currently being used in between thereby preventing coalescing of the free areas into a single larger block. Hence, in order to meet the request for a memory of a particular size, a search for a contiguous memory area of the requested size is required to be made on the free/available list. In case, no free block is available, the program should print the error message indicating unavailability of large enough memory block to satisfy the request. In case of availability of large enough free blocks, there are two possible design policies: i) First-Fit: allocate the first available large enough free block on the list, and ii) Best Fit: Search the whole list and allocate the free area closer in size to the requested amount. Both have their own advantages, and disadvantages; you need to discuss these, and explain why you made this choice.

× How can I help?