proc[]
array from an array of struct proc
to an array of pointers to struct proc
, which means 1) process structures are allocated when they are needed, 2) it takes a lot less static memory.Each
proc
structure took up 902 bytes—though I'm trying to trim that down—and NPROC
was set to 150 (this is the number of proc
structures in the system), so the whole proc[]
array took up 135,300 bytes of memory. This doesn't seem like a whole lot, but out of only 262,144 bytes of RAM that the TI-92+ has, it's over half of the total system memory! With all the other global variables, there were only about 74 kilobytes of available RAM. By changing it to an array of dynamically-allocated structures, and with NPROC set to 64 (a more realistic value than 150 on this size of machine), the array now takes up a measly 256 bytes.There are other static arrays that are good candidates for also becoming dynamically-allocated like the
proc[]
array, but they are all less than 10K each, so I'll hold off on changing those for now.In addition to the memory allocator and the immense space savings, I added some simple diagnostic tests in the heap init routine that sorted and listed the global variables and their relative sizes (as percentages of the total size of all global variables):
As you can see, the
inode[]
, buffers[]
, file[]
arrays are the biggest, and I'll probably change those to dynamically-allocated arrays next. The heaplist[]
is used for managing the heap itself, so it cannot be dynamically-allocated like the other arrays (though its size can be reduced as it currently contains 1024 heap entries, which is probably excessive).Last, you may have noticed in that screenshot that I changed the font yet again, at least temporarily. :) I'm still playing with various glyph sets, and I'm kind of leaning toward one that has smaller lowercase letters. If you have any opinions on this (I need feedback!), please share them in the comments.