utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries

[Mike Franklin]

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:  
https://forum.dlang.org/post/jdfiqpronazgglrkmwfq@forum.dlang.org 
  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.

Mike