On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:

>
>> * Is dynamic memory allocation a requirement of D, or a library feature?
> We should agree whether we are making only yet another C compiler or do we want the D compiler. The ability to use object oriented features was the reason I started with D. I think we do npot need full gc but I want to create objects at least at start. they will live trough the program so I have no need to delete then.
> I think it is possible to have the memory and object management things as set of files that may optionally compiled in or left out.  There must be better and smaller malloc programs than the one I use now.

I'm totally with you on this.  I don't want a "better C" or a "worse D".  I hope that programming in D on these microcontrollers looks very much like the idomatic D in other domains.  I want dyanamic memory allocation to be available for sure, but I don't want it to be a prerequisite like the garbage collector currently is.  IMO it should be opt in.

Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).  That looks small and tight, but should be written in D :-)

Mike

On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:
> On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
>
> IMO it should be opt in.

Agree. :)

The problem I've seen with most C-solutions, is that once someone uses printf, the binary suddenly grows out of proportions. (It may be because the programmer included a line for debugging only, and that causes the otherwise 1K program to be huge and almost not fit the MCU).

> Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
>  That looks small and tight, but should be written in D :-)

It looks small and quite quick, but I think it would choke if allocating 256 blocks of 1 byte each and then freeing the first 255 of them. But I absolutely like the simplicity.

I wrote a (much larger) MiniMalloc (also C), which can take any number of blocks and any size.
The block address is guaranteed to be on a 4-byte boundary.
Allocating a block of size 0 will always return the same address; this can never be freed.
The good part is that you can use it with fairly small microcontrollers up to the entire 32-bit address range and no maximum number of blocks/maximum block size, so you can easily allocate a couple of buffers for your 24-bit TFT display.
The drawback: If you make a 'buffer-overflow', eg write past your block's memory, you will corrupt the header of the next block, because I placed the header in front of each block.
Thus my malloc/calloc/realloc/free is very old-fashioned, but it does join neighbouring blocks when they're released. I've stress-tested it for more than 24 hours, and even though it was fairly fragmented, there were no signs of other problems. It's been tested with 0xdeadbeef fills, 0x00000000 fills and unfilled.

Is it possible to write the malloc so it's "garbage collector-friendly" ?
-Eg. would certain algorithms be better than others; would a few 'accessor' or 'query' functions be helpful; would it be useful for the garbage collector to be able to store a couple of flags ?

On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:

>
> I think we should omit moduleinfo totally and so we can not have module constructors. I think pointers to static constructors are available in a certain section that I have not in my link script. Adding this section should make them available.

Whats wrong with module constructors?  Why would C-like constructors be preferred?

Am Sat, 02 May 2015 06:40:06 +0000
schrieb "Mike" <none@none.com>:

> On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
> 
> >
> > I think we should omit moduleinfo totally and so we can not have module constructors. I think pointers to static constructors are available in a certain section that I have not in my link script. Adding this section should make them available.
> 
> Whats wrong with module constructors?  Why would C-like constructors be preferred?

Module constructors guarantee cycle detection at runtime. This requires most of ModuleInfo data (imported modules) and quite some runtime code. Of course we could ignore that requirement but I think the same code should not behave differently on microcontroller D/normal D.

Bonus point: You can have more than one C-like ctor per module.

On Saturday, 2 May 2015 at 02:08:40 UTC, Mike wrote:

> I'm totally with you on this.  I don't want a "better C" or a "worse D".  I hope that programming in D on these microcontrollers looks very much like the idomatic D in other domains.  I want dyanamic memory allocation to be available for sure, but I don't want it to be a prerequisite like the garbage collector currently is.  IMO it should be opt in.

We should make a list of D features that we can have with and without malloc. Then a test program that use all these feqatures.
An object file is not picked from the library if it is not used. Options are not needed when compiling the library.

>
> Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
>  That looks small and tight, but should be written in D :-)
>
It is ok for me and it is used in our production code that does not yet use D. I am still open for other solutions.
These functions should be at least extern C because library code written in C may use them.

On Friday, 1 May 2015 at 06:57:08 UTC, Timo Sintonen wrote:
>> * Is dynamic memory allocation a requirement of D, or a library feature?
> We should agree whether we are making only yet another C compiler or do we want the D compiler. The ability to use object oriented features was the reason I started with D. I think we do npot need full gc but I want to create objects at least at start. they will live trough the program so I have no need to delete then.

You can use malloc+emplace, scoped!Class, or put the instance in the data segment.

On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
>>
> The problem I've seen with most C-solutions, is that once someone uses printf, the binary suddenly grows out of proportions. (It may be because the programmer included a line for debugging only, and that causes the otherwise 1K program to be huge and almost not fit the MCU).
>
Std.format, as suggested, would be too big. I tis easty to copy the printf formatter from libc sources. Or just write an own. It does not have to support all the features. It is a matter of taste if it is a c like printf function or a formatter class. Or both if we like. Only the used ones are picked from the library.
.
>> Also, aren't you using this malloc (https://bitbucket.org/timosi/minlibd/src/15e88941c534a19e753fa0eebcd053b17392b7ad/tools/main/malloc.c?at=default).
>> That looks small and tight, but should be written in D :-)
>
> It looks small and quite quick, but I think it would choke if allocating 256 blocks of 1 byte each and then freeing the first 255 of them. But I absolutely like the simplicity.
>
Every solution has its sides. This would perform poorly in a solution that allocates and frees big amounts of small blocks. But it is good when resources are allocated at the beginning and then used trough the whole lifetime of the program.

On Saturday, 2 May 2015 at 08:33:34 UTC, Timo Sintonen wrote:
> It is ok for me and it is used in our production code that does not yet use D. I am still open for other solutions.
> These functions should be at least extern C because library code written in C may use them.

Newlib already comes with a malloc implementation, you just need to implement _sbrk_r.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=8d6ca5ce05a89853e40f80b583f0680a77bd4b67

On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
> Std.format, as suggested, would be too big. I tis easty to copy the printf formatter from libc sources. Or just write an own.

No need to rewrite libc, just link against it and use whatever is needed.

> It is a matter of taste if it is a c like printf function or a formatter class. Or both if we like. Only the used ones are picked from the library.

You could implement more high level application code like a formatting library as dub package.

On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
> The problem I've seen with most C-solutions, is that once someone uses printf, the binary suddenly grows out of proportions. (It may be because the programmer included a line for debugging only, and that causes the otherwise 1K program to be huge and almost not fit the MCU).

Granted printf isn't small, but it's not that large either, sure you're not including %f float formatting?
https://launchpadlibrarian.net/200699979/readme.txt