ok, the time has come.
Hardware devices usually need to know some memory addresses, for example, in this case, the network device I'm implementing (AMD Lance, works on vmware) needs to know a pointer to a "configuartion block" which in turns has a pointer to a "receive ring" and a "transmit ring", which have pointers to several receive and transmit buffers.
Problem:
If we use, lets say, ByteArrays for buffers, and a garbage collect moves the buffer to a different memory position, the hardware may try to incorrectly access it in the old memory address.
Ideas (3): . Use some kind of "Object Locking" to mark unmovable objects, so the garbage collector doesn't move our buffers around. Is this possible? How will this affect the performance of the garbage collector? what special care should we have if we do this?
. Create a a map of the external memory (including, for example, where the Interrupt Descriptor Table and the Global Descriptor Table are located, what memory is available (mapped), where's the video memory, where in memory is loaded the interpreter (kernel), and where starts the .image). Then create the ExternalMemoryManager class in Squeak and use it to administer this external memory)
. Probably the most interesting idea, collaborated by [uhm... shit, forgot your name and can't find your emails, I'll fill this space asap] Create a second ObjectMemory to take care of the biggest block of external memory available. I like this idea, however we either need to be able to lock some objects in this externalObjectMemory, or we seldom (never?) do a garbage collect in it. How do we do this? Craig? :-)
What do you think? this is what has me stoped right now. I have all the information needed (and more) to implement simple networking (ethernet) support (for a single NIC now). If too long passes without solving this (1 week), I will implement it anyway, and latter see how we solve this. But we seriously need to solve it.
all ideas are more than welcome! thanks! gera
Ideas (3):
Ideas (4) [just got the easiest]: . We've done the most stupid implementation of calloc() and free() in order to build the VM without any changes [code at the end]. This simple implementation has a 1MB buffer, and always returns from the end (free just calls exit()). We could map this calloc() to be accesible from Squeak, and use it for this external buffers. This is not a solution to the problem, as the memory will quite likely get consumed pretty soon, but it will let us continue coding, until somebody comes with a nice solution :-)
I'm happy, I can go on! anyway, don't forget about this, we need to solve it.
gera
PS: Code for calloc() and free() as reference.
#define HEAP_SIZE 1024*1024 void *calloc(unsigned int count, unsigned int size) { static char heap[HEAP_SIZE]; static char *heap_end = &heap[HEAP_SIZE]; static char *heap_new=heap;
unsigned long long total; total = count * size;
if (heap_new + total < heap_end) { char *answer = heap_new; heap_new += total; return answer; } printf("calloc(%d, %d)\n", count, size); }
void free(void *p) { printf("free(%x)\n",p); ioExit(); }
. We've done the most stupid implementation of calloc() and free() in order to build the VM without any changes [code at the end].
I just compiled SqueakNOS with FFI support, mainly to support the standard Squeak way of accessing external memory. On the bottom, there's still this ugly hackish malloc() implementation we have, but we hopefully fix it latter. Know ExternalObject and friends work. As should ExternalFunction. Of course there is no support for dynamic libraries, however, internally compiled plugins should be accesible as if they were dynamic libraries (ExternalLibrary and ExternalLibraryFunction, as well as named primitives, of course).
With this, I'll try to move forward on implementing the Ethernet support that I was working on when all this was fired.
gera
squeaknos@lists.squeakfoundation.org