Thread overview | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 07, 2014 memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
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 |
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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.
|
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | 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.
>
|
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Orvid King | 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 |
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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.
|
April 07, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | 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.
|
April 09, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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? |
April 09, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | "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. |
April 09, 2014 Re: memcpy, memset, memcmp and friends in the D Runtime | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | 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.
|
Copyright © 1999-2021 by the D Language Foundation