On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
> Is it possible to write the malloc so it's "garbage collector-friendly" ?

Garbage collection on microcontrollers doesn't make sense, because the memory consumption will always be significantly higher than with deterministic memory management.

On Friday, 1 May 2015 at 07:34:04 UTC, Johannes Pfau wrote:

>
> TLDR: I'd prefer using @cctor extern(C) void foo() {} instead of normal
> d module ctors.
>
> Bonus points: You can have more than one @cctor per module.

How do you propose defining calling order with this feature?

On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:
> 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.
>
I have assumed we are going the way that libc is not a requirement. If libc is required we must build a full multilib set and possibly include them in binary releases.
This is a question that we can discuss.


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

A separate package is a good idea for advanced things.

On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
> On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer 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. 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.

I like this solution. Very, very few people use %1$08x, but instead they add the argument twice, for instance. Also very few people set a length on %s.
Most of the time, it's just %s, %d and %x, which is used (where %d and %x might have a length like %3d or %08x).

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

Yes. I think that if I had both, I would sometimes pick the one and sometimes the other, depending on my needs. If instantiating classes at startup, it's definitely great for small devices.
I think it's possible to extend it slightly, so when two or three neighbouring blocks are free, they can be combined into one free block; the remaining of the array just have to be moved towards the first entry.

On Saturday, 2 May 2015 at 09:17:57 UTC, Martin Nowak wrote:
> On Saturday, 2 May 2015 at 04:53:51 UTC, Jens Bauer wrote:
>> Is it possible to write the malloc so it's "garbage collector-friendly" ?
>
> Garbage collection on microcontrollers doesn't make sense, because the memory consumption will always be significantly higher than with deterministic memory management.

Will it be possible to have associative arrays without garbage collection ?
What about dynamic strings and dynamic arrays, don't they need GC ?

On Saturday, 2 May 2015 at 10:38:51 UTC, Timo Sintonen wrote:
> On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:
>> On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
>>
>> No need to rewrite libc, just link against it and use whatever is needed.
>>
> I have assumed we are going the way that libc is not a requirement. If libc is required we must build a full multilib set and possibly include them in binary releases.
> This is a question that we can discuss.

Personally, I'd like my distribution package to be the 'full package', which provides:
C, C++ and D.
The reason for providing C and C++, is that most vendors write their driver libraries in C, and I do not think they're going to rewrite their entire driver library, because there's a new language in town. ;)
Perhaps some vendors would provide additional D compatible files, but it's little likely that they would write a library in D without autogenerating it using a script; even that is little likely.
Anoher reason is 'the transition phase'. Many users already know C, and will be doing certain things in C, until they've learned D. They also have sources they've already written, which they might want to use, in order to get up and running quickly.

>>> 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.
>
> A separate package is a good idea for advanced things.

I think it's good to split it up. Also development-wise.
Think of it like we need to take small steps as well; we can't start testing printf support, before we can build a minimum binary for instance.

Am Sat, 02 May 2015 09:45:56 +0000
schrieb "Mike" <none@none.com>:

> On Friday, 1 May 2015 at 07:34:04 UTC, Johannes Pfau wrote:
> 
> >
> > TLDR: I'd prefer using @cctor extern(C) void foo() {} instead
> > of normal
> > d module ctors.
> >
> > Bonus points: You can have more than one @cctor per module.
> 
> How do you propose defining calling order with this feature?

Not at all? C constructors don't really have a defined calling order. You can optionally specify a 'priority' integer but this only works well if you control all constructor priorities.

On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:
> Will it be possible to have associative arrays without garbage collection ?

You can write an AA container. A RefCounted AA implementation might allow unsafe escaping though.

> What about dynamic strings and dynamic arrays, don't they need GC ?

Same here array slices require a GC to be safe, but one could implement them like std::vector.

While built-in arrays and AAs are nice to have it's trivial to replace them with other containers, no need for GC.

I never even needed dynamic memory allocation on a microcontroller.

On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:

>
> I never even needed dynamic memory allocation on a microcontroller.

For many typical uses of microcontrollers this is absolutely true.  However, the 32-bit microcontrollers from ARM are much more powerful than the likes of AVR 8-bit microcontrollers in, for example, the Arduino Uno. Not all uses of microcontrollers are hard real-time, and these 32-bit ARM chips have processing power to spare.

I currently use them to build HMIs (Human Machine Interface, e.g. a GUI).  If I'm just doing machine control, I have absolutely no need for dynamic memory allocation, but if I'm building a user interface that involves images, TrueType fonts, vector graphics, etc..., dynamic memory allocation is quite useful, if not essential.

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.

Mike

On Saturday, 2 May 2015 at 21:53:42 UTC, Martin Nowak wrote:
> On Saturday, 2 May 2015 at 15:15:50 UTC, Jens Bauer wrote:
>> Will it be possible to have associative arrays without garbage collection ?
>
> You can write an AA container. A RefCounted AA implementation might allow unsafe escaping though.

I think RefCount would do nicely for my own use. (I'm very much used to RefCount from ObjC; never grew up to use the GC there).

>> What about dynamic strings and dynamic arrays, don't they need GC ?
>
> Same here array slices require a GC to be safe, but one could implement them like std::vector.
>
> While built-in arrays and AAs are nice to have it's trivial to replace them with other containers, no need for GC.

Sounds good. :)

> I never even needed dynamic memory allocation on a microcontroller.

Me neither, but I don't know if that would change.
I'm especially thinking about making a small database on a Cortex-M, which would be connected via Ethernet. Thus it would be small, diskless, but respond quickly.
Since the STM32F429 Discovery board comes with an on-board 64Mbit SDRAM, it's very tempting to have optional support for large memory.

After trying AA on Javascript, I got quite interested in them (especially for database-use with Bloom filters).

AA would very likely allocate a lot of small blocks. I once wrote a very quick malloc, which had clusters of fixed size blocks for block sizes less than 32 bytes. It sped up our product so much that my boss (who worked on a different platform) came and asked how I did it. :)