Replacing C's memcpy with a D implementation

Johannes Pfau nospam at example.com
Mon Jun 11 18:34:58 UTC 2018


Am Mon, 11 Jun 2018 10:54:23 +0000 schrieb Mike Franklin:

> On Monday, 11 June 2018 at 10:38:30 UTC, Mike Franklin wrote:
>> On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:
>>
>>>> I think there might also be optimization opportunities using
>>>> templates, metaprogramming, and type introspection, that are not
>>>> currently possible with the current design.
>>>
>>> Just making it a template doesn't automatically enable any of this.
>>
>> I think it does, because I can then generate specific code based on the
>> type information at compile-time.
> 
> Also, before you do any more nay-saying, you might want to revisit this
> talk https://www.youtube.com/watch?v=endKC3fDxqs which demonstrates
> precisely the kind of benefits that can be achieved with these kinds of
> changes to the compiler/runtime interface.
> 
> Mike

I guess for most D runtime hooks, using templates is a good idea to 
enable inlining and further optimizations.

I understand that you actually need to reimplement memcpy, as in your 
microcontroller usecase you don't want to have any C runtime. So you'll 
basically have to rewrite the C runtime parts D depends on.

However, I think for memcpy and similar functions you're probably better 
off keeping the C interface. This directly provides the benefit of 
compiler intrinsics/optimizations. And marking memcpy as nothrow/pure/
system/nogc is simple* either way. For the D implementation, the compiler 
will verify this for you, for the C implementation, you have to mark the 
function depending on the C implementation. But that's mostly trivial.

On a related note, I agree that the compiler sometimes cheats by ignoring 
attributes, especially when calling TypeInfo related functions, and this 
is a huge problem. Runtime TypeInfo is not descriptive enough to fully 
represent the types and whenever the compiler the casts without properly 
checking first, there's the possibility of a problem.

-- 
Johannes


More information about the Digitalmars-d mailing list