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

Mike Franklin slavo5150 at yahoo.com
Sat May 11 00:09:08 UTC 2019


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.

>> On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote:
> [...]
>> > Whereby I should say that tanya‘s range definitions differ 
>> > from Phobos.
> [..]
>
> I'm a bit uncomfortable with having multiple, incompatible 
> range definitions.  While the Phobos definition can be argued 
> whether it's the best, shouldn't we instead be focusing on 
> improving the *standard* definition of ranges, rather than 
> balkanizing the situation by introducing multiple, incompatible 
> definitions just because?  It's one thing for Andrei to propose 
> a std.v2 that, ostensibly, might have a new, hopefully 
> improved, range API, deprecating the current definition; it's 
> another thing to have multiple alternative, competing 
> definitions in libraries that user code can choose from.  That 
> would be essentially inviting the Lisp Curse.

Agreed.  We should decide on one consistent definition.  I don't 
know what that looks like right now.  I'm more focused on 
low-level details right now.  I do, however, like the idea of 
delegating the memory management (allocation/deallocation) 
outside of the library.  If that's not feasible for some reason, 
then I would suggest it not be included in utiliD.  I don't want 
dynamic memory allocation in utiliD; that should go into a 
higher-level library that may import utiliD.

Mike




More information about the Digitalmars-d-announce mailing list