/*
* HOME(PROJECTS) || RESUME || LINKS || ABOUT
*/

|Newest| . . . |<<Newer| . . . . . . |Older >>| . . . |Oldest|
(view all as one document)

Retrochallenge 2018/09, 2019/03


XRAM Mini-Malloc

March 17, 2019

I copy/pasted my mminit and mmdump functions to work with external ram instead of using sram. I was able to initialize, and dump the blocks of the memory headers. Getting xalloc and xfree working should also be just as easy. I even did a quick test where I inited the VRAM section as the heap, and saw the memory arena paint on the screen.

The next thing to implement after that is halloc, haddref and hfree. What do those do? Those access memory thru handles. For now, the HANDLE will actually by the xram address. This does not have to be the case in the future; just will be for the moment because it is convenient, and makes it so I don't need to implement a handle table.

This is some basic pseudocode to grab and release items by handle. The idea is that a structure, such as linked list, will use handles instead of pointers.


 handle_t halloc(uint16 bytes) {

	xptr xp = xalloc(bytes);   //allocate external memory

	return xp;		  //return external pointer AS handle

 }

void* hgrab(handle_t h){

	void* p = findInHeap(h);  //see if item already in heap
	
	if (p)
		return mmaddref(p); //attempt to increase heap's copy ref count, and return it

	//not in heap?

	size = getObjectSize(h)
	p = mmalloc(size); //try to allocate memory in heap for object

	if (p){
		memcpyx2i(p, h, size); //copy to internal memory
	}

	return p;  //return object OR null
}

void hrelease(handle_t h) {
	void* p = findInHeap(h);

	assert (p not null) ; //releasing something we don't have?

	if (mmrefcount(p) == 1) { //if this is last reference to it
		memcpyi2x(h, p, getObjectSize(h)); //copy back to xram
	}

	mmfree(p); //decrement ref count, free from heap if gone

}


example usage: (ignoring error conditions)

struct listnode{
	handle_t string;
	handle_t next;
}

printStringList(handle_t list){

	while(list){

		listnode* plist = hgrab(list);   //get listnode struct
		handle_t next = list->next;      //next next handle
		char* str = hgrab(list->string); //get string
		prints(str);                     //print it
		hrelease(list->string);          //release string
		hrelease(list);                  //release list
		list=next;                       //continue at next handle
	}

}


While it seems cumbersome in C, I want to make it so when a programming is running in the virtual machine interpreter, this is all taken automatically. All objects will be referenced by handle instead of pointers. Since the interpreter runs out of SRAM, and not XRAM, it will even be necessary to split the program code into multiple handles and jump or call instructions will need to grab and release code handles. When it works how I imagine it to, the running program in the VM will behave like it has a full 64K of RAM. I don't want to get too far ahead in my thinking, but there is no reason why, if a handle table is implemented (instead of using the physical XRAM addresses) handles can't be swapped to and from disk or even requested over the network. Currently all handles will be xram word addresses, and take the form of 32768-65535. (Words 0 to 32767 make up the video ram). Handle space 0-32767 could be trapped to a callback were requesting a handle's contents are fulfilled by any function. I'm not sure what to use it for, but it seems like it could be powerful.

|Newest| . . . |<<Newer| . . . . . . |Older >>| . . . |Oldest|
(view all as one document)