I thought this might be a good topic to continue. http://forum.6502.org/viewtopic.php?f=12&t=4465&start=120#p52213
Changing times affects approaches to software.
For a "beginner" approach to memory management I'd suggest just statically allocating things.

I have to agree with this.

Tiny BASIC works quite well with statically allocated buffers.

Dynamic buffering can get to be quite complex software especially in a small system. If you've ever chased down what happen's for a malloc() for instance, including going through the OS code it's a big of a nightmare. It can burn up a lot of cycles affecting performance as well. For the system's I've setup using a 6502 like processor I use almost exclusively statically allocated buffers. That includes buffers for the tasks, stacks, video, I/O, etc. It is more bookwork to setup statically allocated buffers, but it sure makes the software simpler to code.

With the amounts of memory available today, it is possible to simply reserve a maximum amount that might be required for each task. (eg. 1k stack for 256 tasks is only 256k of memory). In many cases the maximum amounts required for tasks is not very much compared to memory capacities. Dynamic allocation became popular I think on system where memory limitations required minimal footprints and virtualization of memory.

_________________
http://www.finitron.ca

Tiny BASIC doesn't have strings or arrays, so it can be argued that it doesn't "work well".


In most of my embedded projects, I have my own malloc/free code, in about 200 lines of C. Complexity is fairly low, it keeps all free blocks in a linked list, and does a best fit algorithm to pick a block. I use it mostly for allocating network buffers. Using dynamic memory allows the best use of limited memory.

However, a realistic BASIC interpreter has to be able to dynamically allocate and deallocate memory as variables are created, modified and destroyed. Garbage collection also gets into the picture in the case of string management, which in itself could be complicated.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It occurs to me not to be confused in the definitions between dynamic memory allocation and heap based allocations. Dynamic memory allocations are typically heap based. Dynamic as in at run time could also mean allocated from static storage.

I have found static allocation to be extremely useful when trying to bootstrap a processor and OS. The problem with dynamic (heap)memory allocation is that so much of the system has to be already working in order for it to work.

Sure this doesnt' seem like much, but it's still greater than none. That C code would typically have to be written in assembler for the '02. For a small app not having to worry about dynamically allocated stuff can be a boon.

Most data with the exception of blobs have fixed sizes. Fixed sized data records can be defined in most cases.
Dynamically allocated memory does have its uses just like recursion can be a useful tool sometimes. But it gets overused sometimes and can impact performance. In the typical 6502 app it seems to me that statically allocating memory might be preferred.

Whether memory is allocated dynamically (on heap) or not, can be hidden by the function call to allocate memory, so that the app program doesn't actually have to know.
An object pointer is returned from an object factory. How that factory allocates memory for the object can be up to the factory.


Dynamic as in at run time - true, but not necessarily heap based.
Allocating and deallocating memory for variables does not necessarily have to be done with dynamic (heap) allocations. A statically allocated pool of variables available to be assigned works quite well. One megabyte could be reserved to hold a lot of 32 bit integer variables with names and handles for implementing lists. Note that having larger amounts of memory available makes this practical. One approach to strings would be to use 256 byte max length string vars. 1000 strings * 256 bytes is only 256k of memory. However, If the system is limited to 8kB of memory then some form of dynamic sizing of variable areas is probably required.

_________________
http://www.finitron.ca

Most microcontrollers have much more flash memory than SRAM. A bit of extra flash code to make better use of SRAM is often worth it. On a system I'm working on right now, I have 1 MB of flash, 128 kB of SRAM, and the malloc/free code takes 400 bytes. I think that's a worthwhile effort.

Well, you could leave out free(), and replace malloc() with some simple code to return old heap pointer, while updating pointer with size of object. That only takes a handful of instructions, even on a 6502. When you've got the rest of the system working, you can come back and improve it.