On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:

>> Also what about other implementations like memset or memcmp. Have they been implemented or require work from scratch?
>
> These functions are still mostly implemented in asm, so I'm not sure there is an "idiomatic D" way. I would only wrap them into a function working with slices and checking the length. Mike?

It is also not only the implementation that's "idiomatic D", but also the interface.  For example, I find `void copy(T)(const ref T from, ref T to)` to be much more "idiomatic D" than `void* memcpy(void* to, const void* from, size_t size)`.

Mike

On Sunday, 12 August 2018 at 06:44:37 UTC, Aruna Maurya wrote:

> Also what about other implementations like memset or memcmp. Have they been implemented or require work from scratch?

I don't know of any D implementations of these other than the trivial and naive.  I think it's a lot of work for one person to re-implement all of the software building blocks in D, so I envisioned the Autumn of Code participant choosing one or two to focus on.

Mike

On Sunday, 12 August 2018 at 08:34:46 UTC, Mike Franklin wrote:
> On Sunday, 12 August 2018 at 07:00:30 UTC, Eugene Wissner wrote:
>
>> [...]
>
> Inline ASM is a feature of D, so "idiomatic D" includes assembly implementations.  Where D shines here is with it's metaprogramming capabilities and the ability to select an implementation at compile-time or compose implementations.  See https://github.com/JinShil/memcpyD/blob/master/memcpyd.d  There you will that the compiler selects an implementation based on size in powers of 2.  Sizes that aren't powers of 2 can be composed of the powers of 2 implementations.  For example a 6 byte implementation would be comprised of a 4-byte implementation plus a the 2 byte implementation.
>
> [...]

So I'll be taking Eugene's code as reference to try and implement malloc free and realloc in dlang.

On Sunday, 12 August 2018 at 11:23:55 UTC, Aruna Maurya wrote:

>
> So I'll be taking Eugene's code as reference to try and implement malloc free and realloc in dlang.

Be sure to send your proposal in by August 15!

On Sunday, 12 August 2018 at 11:37:54 UTC, Mike Parker wrote:
> On Sunday, 12 August 2018 at 11:23:55 UTC, Aruna Maurya wrote:
>
>>
>> So I'll be taking Eugene's code as reference to try and implement malloc free and realloc in dlang.
>
> Be sure to send your proposal in by August 15!

Yes. Definitely!I'll do my best!

On Sunday, 12 August 2018 at 06:35:17 UTC, Eugene Wissner wrote:

> P.S. In the last weeks I had thoughts to split low-level stuff from tanya and put it into a separate library, kind of native, gc-free x86-64 (and maybe aarch64) Linux runtime for D. Probably I should go for it :)

In recent months, I've been thinking about something like that as well.

As I work to improve implementations in DMD and DRuntime, I'm always running into situations where I need utility functions or other convenience implementations that currently exists in Phobos, but I can't use Phobos in DMD or DRuntime.  I'd like to have a small dependency-less library that has implementations that don't require much of a runtime implementation (just depending on the language itself), so it can actually be used to create the DRuntime implementations.  These include things type conversion, formatted IO, compile-time type information like that found in std.traits and std.meta, and generally useful algorithms like those in std.algorithm.  It might even be quite nice to have some features from `std.experimental.allocator` available for implementing memory allocation in Druntime.

I started explore this idea with https://github.com/JinShil/utiliD, but found that the Phobos implementations are so interconnected, it's quite a burden to decouple them.  That, and I began encountering chicken-and-egg issues with DRuntime implementations.  There was a discussion recently about refactoring out the compiler dependencies from the platform dependencies in DRuntime (https://forum.dlang.org/post/pjqepc$2sfv$1@digitalmars.com), and I think that will have to be done first before continuing with the idea.

Mike

On Monday, 13 August 2018 at 01:49:35 UTC, Mike Franklin wrote:
> On Sunday, 12 August 2018 at 06:35:17 UTC, Eugene Wissner wrote:
>
>> P.S. In the last weeks I had thoughts to split low-level stuff from tanya and put it into a separate library, kind of native, gc-free x86-64 (and maybe aarch64) Linux runtime for D. Probably I should go for it :)
>
> In recent months, I've been thinking about something like that as well.

I think it's a very promising idea. Why not start with DasBetterC and build a Phobos like library from there?