Dynamic Memory Allocation in Real Mode Operating System

Question

I am building a real mode OS as a hobby project. As my first OS project I wanted to begin at the beginning and so the choice to build a Real Mode Operating System. Having said that, I am not following any OS in particular, but have ideas from many sources. I think more Real Mode as a scratch pad sort of mode where given the hardware, software can be anything with very little intervention by the processor.

Coming to the problem, I am building a alloc() like system call which the user programs can call when they want more memory. I understand a brk() like system call would be more simple to implement but then there would anyways be a malloc() anyways.

A user program in this OS would be a simple COM file, with no header and with statically allocated data and code together. However the dynamically allocated memory will reside after the Code and Stack Segments.

The A, AE, B, BE, C, CE are addresses in the memory model. Note that such an memory arrangement is needed to conform with the SMALL memory model (because most compilers assume such a model).

Now that there is some context, I plan to implement the dynamic memory allocation via a table of the sort below.

The 'Offset' column is the start of allotted memory after the 'C' address. When more memory is requested OS will allocate memory by either

• Find one or more consecutive large enough block from the table which is currently free or
• Allocate more memory at location 'Offset + Size' of the last entry in the table.

Consequently, a free() system call will free one or more a blocks when done.

My question is:

1. Is such a model of dynamic memory allocation is feasible? And why such a model is not used?
2. Should such system calls alloc and free are better to of in a library rather than as a system call?

Answer 1

Is such a model of dynamic memory allocation is feasible? And why such a model is not used?

Who is to say whether such a memory model is not used? A BASIC programming language that I have created uses something similar for referring to strings and arrays. The rows in your table correspond to StringDescriptors in my BASIC.

Should such system calls alloc and free are better to of in a library rather than as a system call?

A matter of taste, but since memory allocation is so fundamental it think it belongs most to the kernel. Then perhaps a system call using the int instruction...

Offset, Size, State, and Blocks.

These are the things that you've chosen to put in your allocation table. Everything you put in, also needs to get updated. That's a lot of extra work when there's redundant information. You can remove the Size info because you can derive it from subtracting two adjacent pointers.
You can also do without the Blocks info because it will always be 1 if free() immediately consolidates when FREE blocks come together.

CE+0,   USED     ; Size is 7 == (CE+7) - (CE+0)
CE+7,   USED     ; Size is 10 == (CE+17) - (CE+7)
CE+17,  FREE     ; Size is 110 == (CE+127) - (CE+17)
CE+127, USED     ; Size is 40 == (CE+167) - (CE+127)
CE+167, EOL      ; TotalRowsCount = 5

New allocation of 105 bytes:

CE+0,   USED     ; Size is 7 == (CE+7) - (CE+0)
CE+7,   USED     ; Size is 10 == (CE+17) - (CE+7)
CE+17,  USED     ; Size is 105 == (CE+122) - (CE+17)
CE+122, FREE     ; Size is 5 == (CE+127) - (CE+122)
CE+127, USED     ; Size is 40 == (CE+167) - (CE+127)
CE+167, EOL      ; TotalRowsCount = 6

Free the 40 bytes allocation:

CE+0,   USED     ; Size is 7 == (CE+7) - (CE+0)
CE+7,   USED     ; Size is 10 == (CE+17) - (CE+7)
CE+17,  USED     ; Size is 105 == (CE+122) - (CE+17)
CE+122, FREE     ; Size is 45 == (CE+167) - (CE+122)
CE+167, EOL      ; TotalRowsCount = 5