Just can't get enough of that Moose!

[Dennis Marer]

Hi everyone!

	I have had an idea about memory allocation which may prove to be
somewhat entertaining - so far the kernel is able to only allocate large
blocks of memory.  In fact, I've modified the 'interface' (I use that term
very loosely so far, nothing is set in stone yet) so that the memory block
'size' parameter specifies the number of kilobytes instead of the number of
bytes.  (What's the point of specifying bytes if the system is going to
round up to kilobytes anyway?)  Working in larger chunks makes the kernel
more efficient any.

	So you've got a large chunk of memory at address X that you've
allocated - how to break this into smaller pieces?  Create an object which
manages this memory for you.  The object's address is *also* X, and it is
entirely in charge of allocating memory from that block - doing the malloc()
and free(), if you will.  Also, the object would automatically resize the
block of memory when necessary (by calling MemoryReallocate).  Here's the
interface I propose (forgive the C++ code, it's only being used for clarity):

	class memory_manager {
	public:
	    memory_manager(size,attributes);	// Same as MemoryAllocate
	    ~memory_manager();			// Destructor, of course
	    void *Allocate(size);		// Size in bytes this time
	    void *Reallocate(size,address);	// Returns a new pointer
	    void Free(address);			// Free allocated memory
	};

	Then (check this out!) a C implementation of malloc(), realloc(), and
free() could be implemented like this:

memory_manager *taskMemory = new memory_manager(10,MEM_VIRTUAL); // 10k heap

#define malloc(size)		(taskMemory->Allocate(size))
#define realloc(size,address)	(taskMemory->Reallocate(size,address))
#define free(address)		(taskMemory->Free(address))

	The heap would automatically grow and shrink as necessary to meet
the needs of the program.  Oh, and calloc() would be a real function call,
implemented in a C library.

	To make myself clear: this would *not* be part of the kernel!  This
would be part of an operating system library which programs could link to.
This object enhances the functionality of the kernel but is not necessary
for its operation.  This is where the kernel stops and the operating system
begins!

	Any feedback?

> An app should allocate memory in physical mem as long as there are physical
> mem available. The algorithms in the memory management device decides whether
> or not, disk should be swapped.
> I can see that some systems require fast response, and therefore will want to
> have much data in mem, but if the response time is crucial, they will probably
> already have a fast harddisk and a large amount of mem anyway. Considering
> this, it might not be a need for the MEM_PHYSICAL flag in PL 3.

I guess what it comes down to is whether we want a system capable of lightning
speed response at the expense of multiple tasks and users, or one capable of
average speed while allowing many multiple users and tasks to coexist.

Lightning speed: Keep MEM_PHYSICAL, put a few restrictions on it.
Average speed:   Restrict MEM_PHYSICAL to more privileged software.

> Maybe you shouldn't pay to much attention to my ideas about Memory Management
> since this is my first OS project, and MM has never been my biggest interrest
> :-), but my "common sense" says this could work pretty well.

No kidding - this is my first OS project too!  :-)  I'm torn - it would be
nice to give all users equal access to all resources, but it seems the 'first-
come-first-served' approach is going to work better for the PC.  Maybe the
rules for restricting physical memory usage could be flexible, to be configured
when a system is set up?  I'm thinking of a multi-user environment, but it's
also got to be flexible for a single-user system...


> It would be nice if all apps could support Unicode, instead of
> having to remap the character table twice a day.

I think Unicode is a reasonable standard to agree on - ASCII is definitely
not the 'ideal' choice for a new operating system...  Let's support our
friends in Europe and give 'em those oomlauts!

> BTW, now when I have said this, will an integer correspond to 4 bytes or
> will it correspond to 2, as it does under uglybuggly dos.

Hmmm...every machine I could think of that I'd want to use has at least a 
32-bit word size.  Just a hint though - the Penitum has a 64-bit data bus!
(This is public info, I'm not divulging any Intel secrets... :-)  I think the
best approach is to define the interface in terms of 'at least': say, for
example, this value is *at least* 32-bits in size.  This means if you write
an application that counts on the value being larger than 32-bits, you are
in trouble when you try to port it... :-(

	byte:		always 8 bits.
	char:		always 16 bits (remember Unicode?)
	short word:	at least 16 bits.
	word:		at least 32 bits.
	long word:	at least 64 bits.

Any comments on that?

Got to run....work to be done!


			Dennis