On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:
On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:
{snip} these 32-bit ARM chips have processing power to spare.
Definitely. Even though they might only be running between 100
and 200 MHz, they're much more powerful than the computers we had
in the 80's.
{snip} if I'm building a user interface that involves images,
TrueType fonts, vector graphics, etc..., dynamic memory
allocation is quite useful, if not essential.
TTF. That sounds pretty amazing! :)
I suggest refraining from requiring or preventing any feature,
including garbage collection and exceptions. Rather, we can
gradually make each feature available as the need arises, and
the user can opt in and make their own tradeoffs.
Agree. I'm hoping to find some good places where we can slice the
cake, so we don't have to eat it all at once. ;)
I'll not be working much on a malloc, but I will be thinking a
little about a size-optimized / well-performing malloc could be
written (approximately).
Perhaps I could combine my MiniMalloc with clusters of small
blocks.
Maybe I could make an 'opt-in' on small blocks.
(In my first implementation of small-block clusters, I had blocks
of sizes 1 ... 32 bytes, and each cluster contained 128 blocks.
Each block had a bit in a 128-bit field, which marked it as
used/free). It was fairly quick to find the cluster a block
belonged to, and the overhead per block was only a single bit +
the malloc header. If running out of free blocks in a cluster,
another cluster was allocated.
This might be suitable for MCUs, but clusters should probably be
in 16 blocks or 32 blocks, in order to avoid wasting too much
space. Block sizes might only need to be 1, 2, 4, 8, 16 and 32
bytes (perhaps depending on the RAM available).
