utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
slavo5150 at yahoo.com
Sat May 11 00:23:31 UTC 2019
On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote:
> On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote:
>> I'm not 100% sure it's a good idea to implement memcpy in D
>> just to prove that it can be done / just to say that we're
>> independent of libc. Libc implementations of fundamental
>> operations, esp. memcpy, are usually optimized to next week
>> and back for the target architecture, taking advantage of the
>> target arch's quirks to maximize performance. Not to mention
>> that advanced compiler backends recognize calls to memcpy and
>> can optimize it in ways they can't optimize a generic D
>> function they fail to recognize as being equivalent to memcpy.
>> I highly doubt a generic D implementation could hope to beat
>> that, and it's a little unrealistic, given our current
>> manpower situation, for us to be able to optimize it for each
>> target arch ourselves.
> I understand that point of view. Indeed we have to demonstrate
> benefit. One benefit is to not have to obtain a C toolchain
> when building D programs. That is actually quite an
> inconvenient barrier to entry when cross-compiling (e.g. for
> developing microcontroller firmware on a PC).
> I'm also hoping that a D implementation would be easier to
> comprehend than something like this:
> https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly.
> For compilers that already do something special with memcpy and
> don't require a C standard library, there's no reason to do
> anything. My initial exploration into this has shown that DMD
> is not one of those compilers.
Also, take a look at this data:
Why is DMD making 48,000 runtime calls to memcpy to copy 8 bytes
of data? Many of those calls should be inlined. I see
opportunity for improvement there.
More information about the Digitalmars-d-announce