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

On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:
> {snip} the overhead per block was only a single bit + the malloc header.

Correction: The overhead was a single bit + 1/128 of the malloc header, because we had 128 blocks per cluster.
Thus if having a cluster of 32 blocks, the overhead would be 2 bits per block.
A cluster of 16 blocks would have an overhead of 3 bits per block, because my header size is 32 bits and always 4-byte aligned.

On Sunday, 3 May 2015 at 01:57:45 UTC, Jens Bauer wrote:
> 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.

Newlib already ships with a size optimized malloc.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=8d6ca5ce05a89853e40f80b583f0680a77bd4b67

On Sunday, 3 May 2015 at 00:59:07 UTC, Mike wrote:
> 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.

Yes exactly

On Monday, 27 April 2015 at 17:25:50 UTC, Johannes Pfau wrote:
> Since 2.066 the binaries on gdcproject.org are built with crosstool-NG
> (and an additional D script) in a docker container.

That's interesting, do the Windows binaries have some binary dependency on MinGW?
It currently seems that we'd to build ddmd with GDC or LDC to get a fast enough compiler. Maybe that would allow us to cross-compile release as well.
Currently I'm using virtual box with 5 different OSes to build a release.

Am Sun, 03 May 2015 15:18:40 +0000
schrieb "Martin Nowak" <code@dawg.eu>:

> On Monday, 27 April 2015 at 17:25:50 UTC, Johannes Pfau wrote:
> > Since 2.066 the binaries on gdcproject.org are built with
> > crosstool-NG
> > (and an additional D script) in a docker container.
> 
> That's interesting, do the Windows binaries have some binary dependency on MinGW?

AFAIK no. It only uses standard windows dlls.

> It currently seems that we'd to build ddmd with GDC or LDC to get a fast enough compiler. Maybe that would allow us to cross-compile release as well.

That should work. However, we only have very basic MinGW support in GDC. I don't think it can compile a working ddmd but we'll have to make it work for the windows->arm cross compilers anyway.

> Currently I'm using virtual box with 5 different OSes to build a release.

I used one VM and that was already kinda annoying. Docker is really
useful for such build-tasks. (easy to use((not need to setup ssh etc)
reproducible, redistributable, fast & parallelizable)