Allocating memory block about prog8 HOT 8 CLOSED

Great question.

I ran into the same issue while programming the imageviewer in prog8. For instance the color palette needs a 256*3 bytes memory segment. At first I did it the same as in your question above but that is indeed problematic as the compiler doesn't guarantee the blocks to be serially placed in memory.

It would be cool if arrays could be made larger in prog8 but they're limited to 256 bytes at all times (or 128 words, or 51 floats) because of the indexing and this is very hard to change and would make all array operations a lot slower.

So I came up with a new solution: the memory() built-in function that:

• just tells the assembler to "allocate" a chunk of memory of the given size somewhere
• doesn't create a byte array type but simply returns a memory address, the start of the block

It's a bit more convoluted to work with via just an address: you'll have to use @(...) pointer syntax a lot instead of array indexing. But it works. You can see one example of it here https://github.com/irmen/prog8/blob/master/examples/cx16/imageviewer/iff_module.p8#L34

memory() is part of the upcoming 6.0 release of prog8 that contains a pile of other changes and improvements. I'm still working on that so if you want to try it out now you'll have to build prog8 from master yourself. I would appreciate it a lot if you did though and let me know what you think of it.

If you're stuck with prog8 5.4 though. you could try the progend() function that simply returns the first address of the free memory after the end of the program. If you need multiple different buffer though, it will be difficult. I'm using that as well in the image reader source code to just have a large block of memory where the image bitmap data can be loaded into

hope this helps

from prog8.

I've decided not to introduce a new datatype, that is a mountain of work for something that is essentially just an uword.
So for now I stick with a memory() built in function. I've reworded the documentation of it though to make it more clear what it is doing. It's not a malloc like function, it's more of a lookup request to the compiler asking it for the address of a memory block by name.

from prog8.

By the way there is no concept of "allocating" and "freeing" memory like in C for instance. All memory in prog8 is statically allocated

from prog8.

Thanks Irmen, I didn't know about progend() function, it is a sufficient solution for me as for now.

memory() function sounds interesting - however, did you consider it as a %directive instead of function?

from prog8.

Hm, how would you suggest that to work?
You need the memory address of the buffer don't you? A directive is just a meta thing controlling the compiler it doesn't interact with the code otherwise

from prog8.

Sth like that: %memblock <fromaddress>,<toaddress> :)

However, a directive maybe is not the best idea though, nor a function.

For me, it's very uncommon to use a function as a data type declaration. And, in the same time, reserving static memory is for me more like data declaration: "here it declares memory block, it has X bytes size and start at address Y".

Yes, C++ has a function malloc(). But as you said, all memory in prog8 is statically allocated, so it is not a malloc() like function, it is clearly a data declaration (like an array or a struct). Maybe a new data type should be used?

from prog8.

that's a vaild point, I'll think about it
(but adding a new datatype is a heck of a lot more work than adding a new builtin function...)

from prog8.

I am working on an implementation of both malloc and farmalloc in prog8 as well as a library that implements structs and farstructs. I'll post a link when it's ready for prime time. For malloc you create an array of bytes and call the "addblock" method to add it to the heap. For farmalloc you create far pointers (really 3 byte arrays) that point to the banked memory. For example $01:a000, $02:a000. This forms the far heap. Depending on how much you add you can allocate up to 2GB, but the blocks can be no bigger than 10 bytes smaller than 8k.

from prog8.