I'm trying to port the D Runtime to a bare metal platform.  In the short time I've been doing bare metal work, I've come to rely on two very fundamental methods: memcpy and memset.  In my D runtime, however, I'm not using the C standard library; I'm doing it all in D.

It seems the D Runtime and Phobos also often make use of memcpy and memset, but they do so through core.stdc which doesn't appear to be part of the D Runtime.  Was this just a matter of convenience or thoughtful design?  I'm guessing the former based on the fact that core.stdc is not in the official language reference.

So, I would like to know what the design philosophy is for fundamental memory utilities like memcpy, memset, memcmp etc..., because I need them and would like to implement harmony with D's design.

* Were these methods intentionally omitted from the D Runtime, or just taken for granted since they were so conveniently available in the C standard library?

* Should they be added to core.memory or some other module and exposed as official, supported, methods of the D Runtime (hopefully changing their names)?

Please advise.

Thanks,
Mike

On Mon, 07 Apr 2014 07:51:38 -0400, Mike <none@none.com> wrote:

> * Were these methods intentionally omitted from the D Runtime, or just taken for granted since they were so conveniently available in the C standard library?

I don't think it's convenience so much as being very experienced and tuned functions.

> * Should they be added to core.memory or some other module and exposed as official, supported, methods of the D Runtime (hopefully changing their names)?

I think using using D's safer syntax of

a[] = b[]

and

a[] = 0;

Is much preferable to using memcpy/memset directly.

They should do the "Right Thing", including calling memcpy/memset when correct.

-Steve

On Monday, 7 April 2014 at 12:38:55 UTC, Steven Schveighoffer wrote:
>
> I think using using D's safer syntax of
>
> a[] = b[]
>
> and
>
> a[] = 0;
>
> Is much preferable to using memcpy/memset directly.
>
> They should do the "Right Thing", including calling memcpy/memset when correct.
>

Oh! that is SO much better.  I should have known.  Thank you.

I know that with DMD at least, memcpy, memset, and memcmp are all intrinsics, meaning the compiler emits their implementations directly, thus why there isn't a body for them in druntime.

On 4/7/14, Mike <none@none.com> wrote:
> On Monday, 7 April 2014 at 12:38:55 UTC, Steven Schveighoffer wrote:
>>
>> I think using using D's safer syntax of
>>
>> a[] = b[]
>>
>> and
>>
>> a[] = 0;
>>
>> Is much preferable to using memcpy/memset directly.
>>
>> They should do the "Right Thing", including calling memcpy/memset when correct.
>>
>
> Oh! that is SO much better.  I should have known.  Thank you.
>

On Monday, 7 April 2014 at 13:17:37 UTC, Orvid King wrote:
> I know that with DMD at least, memcpy, memset, and memcmp are all
> intrinsics, meaning the compiler emits their implementations directly,
> thus why there isn't a body for them in druntime.
>
> On 4/7/14, Mike <none@none.com> wrote:
>> On Monday, 7 April 2014 at 12:38:55 UTC, Steven Schveighoffer
>> wrote:
>>>
>>> I think using using D's safer syntax of
>>>
>>> a[] = b[]
>>>
>>> and
>>>
>>> a[] = 0;
>>>
>>> Is much preferable to using memcpy/memset directly.
>>>
>>> They should do the "Right Thing", including calling
>>> memcpy/memset when correct.
>>>
>>
>> Oh! that is SO much better.  I should have known.  Thank you.

What's this for then? https://github.com/D-Programming-Language/druntime/blob/master/src/rt/memset.d

On Monday, 7 April 2014 at 14:05:38 UTC, John Colvin wrote:
>
> What's this for then? https://github.com/D-Programming-Language/druntime/blob/master/src/rt/memset.d

Those appear to be the implementations of the a[] = x syntax as compiler builtins and provide even more of a reason to it.  They are internal to the runtime.  I was wondering why such methods aren't part of the runtime's interface and I believe I received the answer.

I'm still wondering if the usage of memcpy in phobos could be replaced with something more 'D'. a[] = b[] could always be translated to a call to memcpy in the platform's runtime port.  Maybe I'll do some tests and submit a pull request.

On Monday, 7 April 2014 at 22:42:54 UTC, Mike wrote:
> On Monday, 7 April 2014 at 14:05:38 UTC, John Colvin wrote:
>>
>> What's this for then? https://github.com/D-Programming-Language/druntime/blob/master/src/rt/memset.d
>
> Those appear to be the implementations of the a[] = x syntax as compiler builtins and provide even more of a reason to it.  They are internal to the runtime.  I was wondering why such methods aren't part of the runtime's interface and I believe I received the answer.
>
> I'm still wondering if the usage of memcpy in phobos could be replaced with something more 'D'. a[] = b[] could always be translated to a call to memcpy in the platform's runtime port.  Maybe I'll do some tests and submit a pull request.

Apologies, John.  I see now you were responding to Orvid, not me.

On Monday, 7 April 2014 at 12:38:55 UTC, Steven Schveighoffer wrote:
> I think using using D's safer syntax of
>
> a[] = b[]
>
> and
>
> a[] = 0;
>
> Is much preferable to using memcpy/memset directly.
>
> They should do the "Right Thing", including calling memcpy/memset when correct.
>
> -Steve

I received a very informative answer on D.learn (http://forum.dlang.org/post/xdnbfbdvruevjgqvbhfb@forum.dlang.org) that describes why a function that copies memory still may be needed:

"Depending on the type being copied, "a[] = b[]" is not straight
up "memory copy" it's the actual full assignment, with postblit
and all. That's why the call we want is *really* memcpy."

So, my question remains:  If I'm porting D to a platform that has no C library, shouldn't a public, supported function that copies memory be added in the D Runtime?

"Mike"  wrote in message news:iflykgpsrmdbfhuwzqtp@forum.dlang.org...

> So, my question remains:  If I'm porting D to a platform that has no C library, shouldn't a public, supported function that copies memory be added in the D Runtime?

What platform doesn't have a C library?  And you can always cast arrays to ubyte[] before assigning to avoid postblit. 

On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message news:iflykgpsrmdbfhuwzqtp@forum.dlang.org...
>
>> So, my question remains:  If I'm porting D to a platform that has no C library, shouldn't a public, supported function that copies memory be added in the D Runtime?
>
> What platform doesn't have a C library?  And you can always cast arrays to ubyte[] before assigning to avoid postblit.

My custom, bare-metal, D-only platform has no C library, nor will it ever.  And, Yes, I know I can cast, but should I?

memcpy is used quite often in Phobos.  Here's a small sample from std.array:

void trustedMemcopy(T[] dest, T[] src) @trusted
{
    assert(src.length == dest.length);
    if (!__ctfe)
        memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
    else
    {
        dest[] = src[];
    }
}

You could ask the same question there, "Why isn't a cast used instead?" and remove the dependency on the C library.

So far, it seems D has only been used on one subset of computer systems that happen to have a C library, but some of us our trying to break some new ground with D.  I'm challenging the "D is only useful on PCs with a C library" bias and looking to see if D has the will to stand on its own two feet instead of leaning on C.