ARM Cortex-M Microcontroller startup files

[Jens Bauer via Digitalmars-d]

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).